License compatibility of MS-PL and MS-CL (Was: (RE: Groklaw's OSI item (was: When will CPAL actually be _used_?))

Michael R. Bernstein michael at fandomhome.com
Thu Aug 23 06:10:33 UTC 2007


On Wed, 2007-08-22 at 17:10 -0400, Mike Milinkovich wrote:
> I agree that it is important to the credibility of the OSI that it apply the
> OSD to the Microsoft request in a completely rational manner, and that it
> either certify the licenses or document where they are deficient. No special
> treatment, either positively or negatively.
> 
> Proliferation and compatibility (GPL or otherwise) are red herrings. Despite
> the conversations on proliferation last year, new licenses have been
> approved by the OSI, so clearly it remains in the license certification
> business. And compatibility is not part of the OSD, as the existence of the
> GPL, MPL, CPL, EPL and others demonstrate. (E.g. not even all of the
> existing "tier one" licenses are compatible.)

Speaking for myself, I am not so much concerned with any particular
incompatibility arising from different sets of permissions or
requirements (although those can be unfortunate). It is generally fine
with me that the submitted licenses are incompatible with the GPL or any
other individual license.

What bugs me is that these licenses are incompatible with *every* other
approved license, even the BSD license. That took special effort.

No, let me amend that: It bothers me that these licenses are
incompatible with the entire universe of all other theoretically
possible licenses, including future ones, regardless of their terms.
IANAL, but it seems to me they are even incompatible with licenses that
are word-for-word identical except for a name change. 

Is this true of any other OSI-approved license?

It also bothers me that this incompatibility extends not just to code
mixing and sublicensing, but also to multiple licensing. Multiple
licensing, like forking, is an unfortunate and infrequent necessity that
I don't think should be given up lightly.

I think we need to add OSD #11 to disallow this kind of gratuitous and
discriminatory license incompatibility. Call it the principle of
licensing neutrality: no provision of a license should explicitly
disallow combination with code under other licenses if the license terms
are otherwise compatible.

Or perhaps this: A license may not discriminate against other licenses
or groups of licenses.

Just to re-iterate: In my opinion incompatibility with other individual
licenses is NOT objectionable in and of itself. I do not think that
incompatibility per-se is non-neutral or discriminatory.

- Michael R. Bernstein
  michaelbernstein.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070822/b16b0481/attachment.sig>


More information about the License-discuss mailing list