For Approval: Microsoft Public License

[B Galliart]

Russ Nelson wrote:

> There's been a huge amount of discussion of this license, some of it
> prompted by the name.  Now that that has been changed, if there are
> any remaining objections, please post them under this thread.

In terms of follow the letter of the law of the Open Source
definition, it seems to me that Microsoft has done a wonder job of
compromising in an attempt to become a member of the community.  In
terms of following the spirit of honoring the Open Source definition,
I think Microsoft still has a long way to go and granting them a OSI
rubber stamp to claim anything covered by these licenses are compliant
with the Open Source definition would be a mistake.

Actions that I think should be taken into consideration is:

* How Microsoft is already using (or abusing) the term "Open Source"
* How other MS EULAs/licenses impact existing MS works covered under
MS-PL or MS-CL

Bill Hilf wrote:

> If the license-discuss community feels that having the MS-CL and
> MS-PL posted separately from our other Shared Source licenses,
> I'm happy to consider doing that, if that's important to the broader
> community.  One of the reasons we continued to call it the
> "Shared Source" program was to acknowledge that these licenses
> had not been approved by the OSI, and some of our Shared Source
>  licenses will not be submitted to the OSI.  But I'm open to make
> this more distinguishable on where/how we post the MS-CL and
> MS-PL on the Web site if it's important to the community.

To me this suggests that he is claiming that the term Shared Source
exists because Microsoft is making a distinction between non-OSI
approved licenses and OSI approved licenses.  This does seems like a
worth while reason to create another term and for Bill Hilf's part he
does appear to keep such a distinction in his own posts.  But for the
most part, Microsoft seems to use Shared Source and Open Source as
interchangeable terms such that the advantage is lost and we have just
another confusing term to dilute the concept of the Open Source
definition.

Around the same time that BH offered to move the MS-CL and MS-PL to a
separate web page, Microsoft was already referring on the
microsoft.com/opensource website that the Sharepoint Learning Kit
(covered by the MS-CL) is "an open source application from Microsoft."
 If MS is honoring BH's explanation then shouldn't they refrain from
calling it open source until MS-CL is approved by the OSI?  Why isn't
it currently referred to as Shared Source?

The MS OSS Lab's Port 25 blog goes even a step further in eliminating
any distinction between "Shared Source" and "Open Source" terms.  Not
only are MS-CL and MS-PL covered works referred to as Open Source, but
works covered under licenses that haven't even been submitted for OSI
approval are also equally referred to as Open Source.  Is there even
plans to ever submit either the MS-dCPL or MSR-LA for OSI approval?
Why are projects covered by these licenses not referred only as Shared
Source projects instead of as "Open Source Projects on Windows" by MS
Port 25?

I'm not stating this to single out Microsoft.  The OSI currently has
on it's main web page a statement about QNX not opening their source.
It seems when dealing with other companies that making a distinction
is important.  I believe that MS' method of exchangeable terms with no
true distinction between them will find it's way into the popular
press.  As such, I feel this behavior goes against the charter of the
OSI to promote "Open Source" in a way that is consistent with the Open
Source definition.

Next, I feel the OSI needs to make a clear distinction between
approving the MS-PL and MS-CL from approving all projects that are
covered from them.  The application of the licenses are not done in a
vacuum and I believe there exists a problem that I would like to dub
the "Kosher Cheeseburger issue."

Dag-Erling Smørgrav previously posted to the mailing list a well
written explaination of how the application of two licenses only
provides the union of permissions:

> if a piece of software is composed partly of code released under
> license A, which grants you  permissions X and Y, and partly of
> code released under license B, which grants you permissions
> Y and Z, the effect as regards the combined work is to grant you
> *only* permission Y.  License A's grant of permission X does not
> extend to the code that is covered by license B; neither does
> license B's grant of permission Y extend to the code that is
>  covered by license A.

How this effects the Open Source definition can be compared with
religious dietary requirements.  Take for example a fast food
restaurant owner that wants to expand to new customers.  He notices
one group that seems to avoid his business and asked them why.  After
being told it is because none of his products are kosher, he switches
beef distributors and starts advertising having "Kosher
Cheeseburgers."  Of course, the act of adding cheese already violates
the definition of being "kosher." Yet, the owner still only talks
about how he has compromised and it is up to the targeted community to
accept this offer.

There are Codeplex projects that, while covered by MS-PL or MS-CL, do
not honor the true spirit of Open Source definition.  For example,
PowerToys for Visual Studio is one of the first Shared Source projects
promoted by Port 25.  However, modifying the project requires first
downloading, installing and using the Visual Studio SDK.  After
accepting the SDK's license, there are limits placed on modification
and redistribution of the project.   As pointed out by Smørgrav, just
because license A grants permissions X and Y, when another license
comes into play you may loose permission X and be left only with
permission Y.  So, it might be that the immediate license for
PowerToys for Visual Studio could be considered to grant all the
permissions needed to be Open Source if it was applied in vacuum.
However the application of MS-PL + VS SDK licensing seems as
meaningful and useful a compromise as cheeseburgers made with kosher
beef.  Over the last year, I have only seen MS offer community input
on how the immediate licenses effect the Open Source definition, a
solution to the bottom line of how their SDK licenses can take those
same grants back for even their own projects and licenses still
remains unresolved.  Therefore, I feel allowing MS to rubber stamp
such a project as OSI approved would be damaging to the true spirit in
which the Open Source definition was written.