For Approval: Microsoft Permissive License
Chris Travers
chris at metatrontech.com
Sun Aug 19 22:43:41 UTC 2007
First the general points, then how they affect the MS-PL.
IANAL, TINLA, YMMV, etc.
Donoan Hawkins wrote:
>
> Excluding linking for a moment:
>
> If you only convey your derived work in source code form, with an
> optional dependency available via conditional compilation, I would
> agree with you. Your work compiles (without the optional component),
> but has bindings to allow someone to easily enable support for the
> optional component. I don't see a problem there.
>
> If you convey in executable form, then your "optional component" isn't
> optional anymore. You either compiled it in or you didn't, and the
> answer to that question determines whether you have to provide the
> component source under GPL or not.
So consider the following (why this is messy):
Libpq compiles optionally with OpenSSL (old-BSD licensed) and is under a
new-BSD license. It connects over a network socket to PostgreSQL. When
OpenSSL is available, SSL-encrypted network connections to the db server
are possible for any connecting application. Even if libpq is compiled
with OpenSSL support, unencrypted connections can still be used by the
library if they are not requested by the server. Hence the absence of
the library does not prevent most other applications from functioning
under the most common configurations.
FreeRadius is under the GPL. Suppose they ugprade to GPL v3.
Suppose there is an LGPL plugin to FreeRadius which uses libpq to
authenticate users against PostgreSQL.
Now, by your logic, if I am an Linux distributor, I cannot distribute
Libqp compiled with OpenSSL at the same time that I distribute the
FreeRadius plugin for PostgreSQL because the corresponding source would
include OpenSSL and the licenses are not compatible. This is not
hypothetical. Istr Debian refusing to distribute a similar plugin under
the same concern.
My analysis would be however that the Freeradius plugin under GPL v3
might be different because of the fact that the plugin does not fall
under the category of "dynamically linked subprograms that the work is
specifically designed to require." This would, in my mind, let a
distributor off the hook because it draws a line based on a "designed to
require" standard.
My reading of this is "if the program runs without it, you don't have to
provide the source under the terms of this license."
>
> Linking is another matter, and I'll defer to others on that since I
> think some people disagree with the FSF on that point.
>
Linking is not mentioned in the GPL v2 at all last time I checked.
Dynamic linking is specifically mentioned in the GPL v3 as a part of the
corresponding source, but only in cases of "dynamically linked
subprograms that the work is specifically designed to require." I
believe static linking is implied in other portions of the definition of
corresponding source.
>
>> Also "corresponding source" includes a number of loopholes which
>> could be used to exclude arbitrary components. For example, I
>> *could* make a Linux device which used closed source libraries as
>> part of an authentication system, create a GPL'd application for that
>> device which used those same libraries, and exclude them as "system
>> libraries" (because they interface with the authentication system
>> which is arguably a "Major Component"). If you want to use the
>> application on a different Linux device, you have to pay for the
>> required libraries.
>
> GPL v3 says:
>
> "A "Major Component", in this context, means a major essential
> component (kernel, window system, and so on) of the specific operating
> system (if any) on which the executable work runs, or a compiler used
> to produce the work, or an object code interpreter used to run it."
>
> So your authentication system is not a "Major Component"...it is not a
> component of the OS, nor is it a compiler or object code interpreter.
So PAM and NSSWITCH are not a part of the OS? That is news to me.
I would think that the authentication subsystem would be as much a major
component as, say, X.org.
>
> All this exception is saying is that you don't have to give people a
> copy of the source code to gcc and linux just because you use printf()
> and fork(). Or worse, give everyone a GPL-licensed copy of the source
> code to MS Visual C++ and MS Windows because you use CString and
> CreateFile().
>
But how do you define the OS? Certainly the device in question might
not include any GNU tools and hence not even be something RMS would call
"GNU/Linux" but does that make it less of a system component?
My definition of "Major Component" would be a component similar to the
kernel or windowing system which provides basic services to a
substantial class of application on the system. THis seems to me to
most closely approximate the wording of the GPL v3 since it doesn't seem
to define this very well.
I see no reason that X.org would be a major component and Oracle, or in
this case, some hypothetical PAM replacement, would not.
>
>> Does the MS-PL place any specific requirements on the code that the
>> GPL does not allow? If so, what are they exactly?
>
>> From MS-PL:
>
> "If you distribute any portion of the software in source code form,
> you may do so only under this license by including a complete copy of
> this license with your distribution."
>
>> From GPL v3 section 5c:
>
> "You must license the entire work, as a whole, under this License to
> anyone who comes into possession of a copy. This License will
> therefore apply, along with any applicable section 7 additional terms,
> to the whole of the work, and all its parts, regardless of how they
> are packaged."
So, are there cases where you cannot do both?
It seems to come back to the same question we have been arguing on
another thread.
Suppose I take BSDL code and include it as whole files into my GPL
application. Do those files as distributed in the application cease to
be under the BSD L? I would argue "no" if I don't own the copyrights to
the BSDL code in the first place (any modifications I make might be
another matter however). Does this prevent the work as a whole from
being licensed by me under the GPL including all components? Not by any
reasonable reading I can give.
Similarly, does the GPL work as a whole clause prevent me from using GPL
components, creating a work, releasing that work under a dual-license
model (standard GPL or at the option of the customer a standard EULA but
with the addition of warranty terms)? If the user always has the choice
to use the GPL terms, I would argue that the license has not been violated.
In short, is there anything in the MS-PL that precludes use of the code
from complying with all of the other terms set in the GPL v3? I don't
see any.
>
>
>>> Your interpretation of the word "by" seems to be equivalent to
>>> "which is accomplished by".
>> No actually I don't. I see it as requiring that MS-PL licensed areas
>> to the extent that they are identifiable must be licensed under the
>> terms of that license. This means including the license and
>> (probably, so as not to run amok with GPL code copyright owners)
>> identifying the portions of the code with reasonable legal notices
>> such as:
>>
>> /* The block of code including the below function is licensed under
>> the MS-PL license. Please see accompanying ms-pl.txt for details,
>> copyright (c) [yyyy] [author_name] */
>
> But is this licensed only under MS-PL, as required by MS-PL, or is it
> also licensed under GPL v3, as required by GPL v3?
>
Unfortunately by your reading, BSDL code would be incompatible to (new
or old) because under copyright law, you can only distribute it under of
the terms granted by the copyright holder anyway(!) but IANAL.
Does New BSDL == GPL? Does copying BSDL code into a GPL v3 app
automatically transfer permissions sufficient to solve this problem
(since you can only distribute *any* copyrighted work under permissions
set forth by the *copyright owner*)?
In that this clause of the MS-PL does nothing outside of summarize what
copyright law in general says (again IANAL), I fail to see how this is a
problem by itself.
Best Wishes,
Chris Travers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chris.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070819/2b241a80/attachment.vcf>
More information about the License-discuss
mailing list