[rick at linuxmafia.com: Re: compatibility and the OSD]

[Chris F Clark]

------- Start of forwarded message -------
Mailing-List: contact license-discuss-help at opensource.org; run by ezmlm
X-No-Archive: yes
Date: Thu, 23 Sep 2004 18:35:53 -0700
To: license-discuss at opensource.org
Subject: Re: compatibility and the OSD
Mail-Followup-To: license-discuss at opensource.org
Content-Disposition: inline
In-Reply-To: <200409232051.QAA1125215 at shell.TheWorld.com>
X-Mas: Bah humbug.
fFrom: Rick Moen <rick at linuxmafia.com>
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: rick at linuxmafia.com
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pcls2.std.com
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63

Quoting Chris F Clark (cfc at TheWorld.com):

> However, his desire is valid.  Especially, if he might be in the
> position to contribute a substantial block of code as open source. as
> an author of such substantial block of code, he might be legitimately
> concerned that someone (say from a competing company) might desire to
> leverage that block into an incompatible and competing product that
> might not be open source.

Rick graciously replied:

> The most obvious way to prevent that is to use a copyleft licence, and 
> accept for inclusion in one's code repository third-party contributions 
> only if accompanied by copyright assignment.  Then, your competitors
> cannot lawfully create competing proprietary forks of your codebase (let
> alone incompatible ones), whereas you can.

Actually, I mistated the problem.  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.  We all
know that this has happened in the past.  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).

A good example of that is OS proprietary calls.  Let's say an OS
implements the standard mechanism for doing some service, but does it
poorly (ie. it is slow or otherwise deficient for actual use), but
also implements some proprietary interface to the same service that
perfoms the same task well (quickly).  Now, the OS vendor can port the
"standard" software and tie the non-proprietary version to the OS
poorly implemented standard version of the service, but additionally
make a non-standard extension that calls the proprietary interface.
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.

It does not take a lot of thought to come up with implementations of
the POSIX standard where that is true, where OS vendors implement
POSIX in name only and in actuality, their software is only
minimimally compatible with POSIX systems and the default OS calls,
the ones that all real users of the software use, are not compatible
with the POSIX subset.

Now, if I were in the position to implement some new "standard" tool,
which I would hope would set a standard for portable use.  I would
want to make certain that all implementors of that tool made versions
that supported portable use.  As such, I would want to make certain
that all implementations could pass a certain conformance suite.  And,
if I were really good at it, I would put tests in the conformance
suite the would test interoperability with other important pieces of
software that the intended users could be expected to desire to use
the software with (for example, if the software enabled web browsing,
a test that the resulting software could display web pages from some
specific test sites in standard formats), lest some implementor skrimp
on those details.

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.

And before crafting such a license, I would certainly try to ascertain
what the limits were that I could go to to make such a license without
actaully submitting a license, so that whatever license I were to
eventually submit would go through with the minimum of negative
reaction.  Since, if the license were to receive a negative initial
reaction, the committee might take a more strict interpretation of the
OSD than it would if no negative comments were voiced.  To wit, even
Bob's straw proposal has raised issues that won't be quickly forgotten
in any new license submissions.

Now, I apologize for the long-winded-ness of this post, but I wanted
to lay out why I think Bob's issue is real, and why serious
consideration of allowing someone to create on open source license
that encourages test suite conformance specifically by certified
OSD-compatible licensing restrictions on non-confroming
forks. Unfortunately, I am not currently in the persission to submit a
serious, substantial license on said topic, as my current day-job
employer (Intel) would have the clout to submit such a license, but
unfortunately has no desire to release open source software in my
current area of employ (chip design software), and thus I cannot speak
on their behalf in this regards.

-Chris