Subject: Re: [ Re: compatibility and the OSD]
From: "Michael R. Bernstein" <>
Date: Fri, 24 Sep 2004 10:30:06 -0700

On Fri, 2004-09-24 at 08:12, Chris F Clark wrote:
> [snip] It's not so much that the
> competitor might release a non-open source version, but that they will
> release an incompatible forked open-source version, and not properly
> identify it as incompatible, misleading users into using the
> incompatible version as if it were the "standard" version.  [snip]
> Many vendors like to
> introduce "proprietary" enhancements that tie clients into dependence
> on those extensions.  (And by proprietary, I don't necessarily mean
> the extension itself isn't open source, but that it creates a
> dependence on some other facility outside of the work which is not
> open source).
> Unfortunately, naive users can easily be lulled into using the
> non-standard version and being tied into the OS vendors product.  The
> resulting user written software is not portable and they are trapped,
> and the OS vendor can claim standard conformance and yet in actuality
> tie users only to their proprietary on non-standard features.

The simple solution to this is to license the software under a copyleft
license, which ensures that the 'proprietary' version can always be
re-forked (or merged with the mainline version) as necessary to create a
version that makes the proprietary extensions optional, or othwerwise
provides some migration path for the users, for example by facilitating
the creation of an open-source implementation of the external

> Now, getting this back to the license.  I would specifically want all
> versions of the "standard" software to pass the standard test suite.
> And, I would make it as difficult as I could (within the OSD) for a
> competing vendor to take the software and make a fork that leveraged
> the code that I provided in my open source version to create an
> incompatible version that tied users into their competing OS.

The best bet (as has already been mentioned several times) is to license
the software under a copyleft license, and tie the conformance suite
just to use of a trademarked name and certification mark. Then you have
both carrot (certification) and stick (copyleft ensures users have an
exit migration path).

Michael R. Bernstein <>