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

[Rick Moen]

Quoting Michael R. Bernstein (michael at fandomhome.com):

> To me, this seems to go beyond incompatibility per-se into
> discrimination.

I'm perfectly glad to agree to disagree -- holding, as I do, that going
beyond "Derivatives must be compatible with this licence" to
"Derivatives must be under exactly this licence" is merely pigheaded and
self-defeating but not non-free / proprietary.  However, before we do,
just an attempt to explain and explore:

I see OSI's licence-certification mission as identifying licences that
can delimit software commonses, within which recipients are guaranteed 
rights to use for any purpose without fee, redistribute, and create and
distribute derivative works that perpetuate the same permissions.
However, it isn't certifying those as good licences, let alone vetting
them as being likely to create a _healthy_ or lasting or reasonable
commons.

If you examine the motley collection of OSI-approved licences to date,
you'll spot some fairly ridiculous practical problems that pretty much
doom most of those, ab initio, as the foundation of such a commons.
Most fizzled for reasons other than this degree of licensing
incompatility, but their commonses were and remain stillborn, all the
same.

The certified list isn't a licence "buyer's guide".  If people are
treating it that way, then _that_ is the problem to fix.

> In my opinion, even though arbitrary conflicts of terms and conditions
> with other licenses are acceptable (if unfortunate), arbitrarily
> refusing to allow code into or out of the commons where no actual
> conflict of terms and conditions exists is un-free. I suppose it is
> un-necessarily abridging the freedom to modify.

As a reminder, there are people who will argue, with no sense of irony,
that pretty much any or all of the existing OSI-approved licences
"un-necessarily abridge the freedom to modify" -- even new-BSD and
MIT/X11.

As a further thought, and enlarging on the "can of worms" comment, I
don't know if OSI wants to get into the business of deciding which
incompatibilities are gratuitous, and which are merely unfortunate
side-effects.


> True, but on this list we've occasionally discouraged sucky licenses
> from completing the approval process.

And I might support that, here -- though the better and more diplomatic
alternative might be to suggest an improvement after tactfully asking
what the licensors are aiming to achieve.