Subject: Re: For Approval: Microsoft Public License
From: Rick Moen <rick@linuxmafia.com>
Date: Tue, 9 Oct 2007 13:59:53 -0700

Quoting B Galliart (bgallia@gmail.com):

> 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?

B Galliart:  It would be good if you would provide specific pointers
(URLs or functional equivalent), when citing such examples.  Eventually,
I found your intended hyperlink reference,
http://www.microsoft.com/opensource/choice.mspx, which includes text:

  The Road to Open: SharePoint Learning Kit [link]

  Learn about SharePoint Learning Kit, an open source application from
  Microsoft, designed to help faculty and students collaborate and learn
  together more effectively. The Learning Kit is based on Microsoft
  SharePoint [link] technology, a Web-based solution for collaborative blog,
  wiki, and document management. Read the PDF [link] (244 KB)

The PDF, 
http://download.microsoft.com/download/D/4/4/D44F6287-41F5-48EB-A93A-23D251B2704E/RoadtoOpenSharePointLK.pdf
, is also linked from http://www.microsoft.com/opensource/downloads.mspx
with anchor text "Road to Open: SharePoint Learning Kit[link].  See how
the Microsoft SharePoint Learning Kit (SLK) provides value to a range of
businesses and institutions."

It is certainly very mildly vexing for Microsoft to use the term "open
source" in relation to a licence not yet OSI approved, and we on
license-discuss do ask firms and individuals to please not to do that.
However, (1) I call that a venial sin since MS-CL is, actually,
obviously OSD-compliant on its face, and (2) this question really has no
bearing on the merits of the licence, which is, as a reminder, what
we're discussing.

As an immediate measure, if Microsoft Corp. would be kind enough to 
alter http://www.microsoft.com/opensource/choice.mspx to footnote 
the phrase "open source" as "Microsoft believes SharePoint Learning
Kit's license to satisfy the OSI's Open Source Definition, and has
submitted it for OSI approval", that would appreciated.


> 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....

Well, they pretty much are.  We ask firms and individuals to please
apply the term only to OSI-vetted licences, but that's (I believe)
mainly on account of innumerable parties trying to pull fast ones, e.g., 
with tricky licence addenda encumbering usage.  These guys are _not_ 
attempting to abuse the term to slide by a non-OSD-compliant licence and
evade OSI scrutiny of that licence.  The two licences discussed are
obviously compliant.

> ...but works covered under licenses that haven't even been submitted
> for OSI approval are also equally referred to as Open Source.  

Well, that would be bad.  Again, you really should have pointed to
specific examples, rather than oblige readers to go hunt them down for
you.  


> 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. 

Huh?  When has OSI ever approved "projects"?  Sorry, I don't think OSI
is likely to delve into such matters.  (I do not speak for OSI.)  But I
see we'll have to discuss details:


[Snip introductory discussion of the dubious kashrut of cheeseburgers,
and of Dag-Erling's attempt to recap licence combinatorics.]

> 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.

I dispute your (underlined) assertion.  See below.

Again, you really _should_ have provided a link, to make sure other
people can be assured that they're seeing the same thing you're seeing,
and to avert their need to hunt for your referents.  I believe you're
speaking of
http://www.codeplex.com/PackInstaller/SourceControl/DownloadSourceCode.aspx?changeSetId=26657
, which is linked from
http://www.codeplex.com/PackInstaller/SourceControl/ListDownloadableCommits.aspx.

I believe you mean _building_ the project (if using current Microsoft
tools for that purpose) requires first downloading, installing, and
using Visual Studio SDK.  I downloaded that messy Zip archive, made a
scratch directory to unpack it into (Redmondians, would you _please_
learn to put top-level container directories in your compressed archives?
Finally?), ran unzip on it, looked around it with /usr/bin/less, 
verified that it was all under MS-PL, and fooled around with it just
fine using /usr/bin/vim.   ;->

But here we get to the bone of the contention you presumably _meant_ to
make:  The default toolkit -- and possibly, for all I know, the only
_currently pragmatically feasible toolkit_, for building that .Net/C#
codebase unmodifiedi[1] is not under MS-PL.  Guess what?  Neither is the
only operating system the codebase, unmodified, is likely to run on.

Is there some specific legal impediment that prevents creation of other,
open source .Net implementations sufficient to compile Power Toys for
Visual Studio aka Power Toys Pack Installer?  E.g., some specific patent
that blocks such a development effort, that is enforced so as to prevent
exercise of open source rights to that extent?  If such a legal
impediment turns up -- and I rather doubt it -- then the general rule
applies per usual:  If external factors such as legal encumbrances
prevent you from exercising open source licence rights in your
jurisdiction, then the codebase isn't open source even if the licence
otherwise qualifies.  E.g., OpenSSL wasn't open source in the USA until
the RSA patent expired, even though it was/is under a mixture of old and
new BSD licences.

Stating that a source codebase is under an open source licence has 
_never_ guaranteed that a fully or partially compatible open source
development/compilation toolkit will exist for your particular preferred
OS platform, let alone meet your needs.  E.g., I'm a Linux user:
PowerToys for Visual Studio doesn't do much for me, even if I were a fan
of Mono -- but I still recognise it as genuinely open source.

> As pointed out by Smørgrav, just because license A grants permissions
> X and Y, when another license comes into play you may lose permission
> X and be left only with permission Y.

Dag-Erling was talking about licence combinatorics _within_ a codebase, 
i.e., he was speaking of derivative-work legal encumbrances.  That is
not what you're speaking of here, at all.

Here's a whimsical example I just dreamed up:  Suppose a, say, 1978
source code release of the TECO editor had been put out under the old
BSD licence.  (This counterfactual is a bit farfetched, but we're
imagining a Harry Turtledove universe where such things are
conceivable.)  This particular fictional source codebase might have been
tailored for VMS running on the Digital PDP-10. 

I (the alternate-universe "I") point out that this release makes the
TECO editor open source.  You counter that -- au contraire -- it cannot
be so, because modifying the codebase requires first buying, installing,
and using the Digital development toolkit for VMS, which like VMS at
that time, was proprietary.  

But the point is that the TECO instance _would_ be open source even
though open source development tools for its native OS platform might
not exist -- in part they _could_ exist if people felt like writing
them, or because TECO might be (and was) portable to entirely different
OS platforms or development environments.


[1] I note in passing Novell's Mono / Monodevelop / XSP toolkit for
Linux/Solaris/OS X.  My point would be unchanged in its absence.

-- 
Cheers,                              Mia kusenveturilo estas plena da angiloj.
Rick Moen
rick@linuxmafia.com