For Approval: Microsoft Permissive License

[Chris Travers]

Donovan Hawkins wrote:
>
> So the only thing standing between these "permissive" licenses and
> compatiblity with GPL v3 is the flawed advertising clause from BSDL,
> something that is widely regarded as an impractical mistake. Whether
> you call these "non-permissive" or "permissive but flawed" is a minor
> point...I would choose "non-permissive" myself.
>
Hmmm.... First GPL v3 section 7b may provide compatibility with BSD-like
licenses with advertising clauses depending on how obtrusive they are
(the FSF's comments to this effect seems to indicate that they are
concerned about proliferation of such advertising notices, not the
original notices themselves). Thus compatibility with these licenses may
be case-by-case. IANAL and YMMV....

Back to the Microsoft license. After re-reading the GPL v3 (nominate
that license for the most complicated and incomprehensible submission to
OSI for approval to date), I have concluded that there are major license
compatibility problems if a GPL v3 application *requires* components
under these licenses. While I can imagine there might be ways around
these problems, they are not any less onerous than dealing with any
other license compatibility. Like many other aspects of the GPL v3, it
is hard to say whether optional dependencies would be a problem, and it
is harder to evaluate the MS-PL which may be compatible.

The basic issue is that the GPL v3 defines the "Corresponding Source" as:

'The “Corresponding Source” for a work in object code form means all the
source code needed to generate, install, and (for an executable work)
run the object code and to modify the work, including scripts to control
those activities. However, it does not include the work's System
Libraries, or general-purpose tools or generally available free programs
which are used unmodified in performing those activities but which are
not part of the work. For example, Corresponding Source includes
interface definition files associated with source files for the work,
and the source code for shared libraries and dynamically linked
subprograms that the work is specifically designed to require, such as
by intimate data communication or control flow between those subprograms
and other parts of the work.

The Corresponding Source need not include anything that users can
regenerate automatically from other parts of the Corresponding Source.

The Corresponding Source for a work in source code form is that same work.'

Section 6 (Conveying non-source forms) states:

'You may convey a covered work in object code form under the terms of
sections 4 and 5, provided that you also convey the machine-readable
Corresponding Source under the terms of this License, in one of these
ways...'

It seems clear to me that any component falling under the Corresponding
Source definition must be able to be distributed under terms of which
the GPL v3 must be either identical or a proper subset. Because the
MS-CL provides per-file restrictions, I don't see how this could be met.

The MS-PL is harder for me to evaluate. A lot of it depends on what 7b
additional terms allow under the GPL v3. The MS-PL could be read as
requiring the distribution of the license as a legal notice (seems
reasonable to me) and possibly noting which sections of code are
MS-PL-licensed. Again, this seems to be in line with the GPL v3 7b
options by my reading.

However, there is one further issue with the MS-PL which might or might
not preclude using them together:

The MS-PL ties the definition of derivative work to US law. I am not
sure if there could be cases where this could run you into trouble with
the GPL v3 which ties it to whatever court wants to hear the case but I
wouldn't think this would be a problem, but I do wonder if there might
be jurisdictions where there might be a conflict. For example, are there
places where things might be considered derivative works which might be
fair use by US standards? Would this use be precluded in such
jurisdictions under the MS-PL because it doesn't give you to prepare
such works? Might there be other conflicts?

Again, I don't think this is a problem, and as a developer probably
wouldn't worry about it. But I could see it being a question when people
look at trying to split hairs to their own substantial benefit.

Best Wishes,
Chris Travers


[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Donovan Hawkins]

On Sun, 19 Aug 2007, Chris Travers wrote:

> Hmmm.... First GPL v3 section 7b may provide compatibility with BSD-like
> licenses with advertising clauses depending on how obtrusive they are (the
> FSF's comments to this effect seems to indicate that they are concerned about
> proliferation of such advertising notices, not the original notices
> themselves). Thus compatibility with these licenses may be case-by-case.
> IANAL and YMMV....

7b allows "requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal Notices
displayed by works containing it."

The phrase "that material" refers to an earlier mention of the "material
you add to a covered work". So 7b allows attributions and notices in the
material you add to a covered work and in the notices displayed by the
covered work.

Advertising that someone else creates for their derived work is not the
material you added to the covered work, and it is not a notice displayed
by the covered work. IANAL, but that doesn't seem to cover the old BSDL
advertising clause.


> I have concluded that there are major license
> compatibility problems if a GPL v3 application *requires* components under
> these licenses.

GPL v3 doesn't appear to prevent anyone from releasing their code under
GPL v3 combined with code under an incompatible license. You just can't do
that with someone else's GPL v3 code, because that is not a right that GPL
v3 grants you.

Of course, it would rather pointless for you to do it with your own code
unless you never intend to have anyone create derivative works. They would
be forced to remove either your code or the code under the other license
in order to proceed.

I'd say you are correct in pointing out that GPL v3 creates "major license
compatibility problems", since it is intentionally incompatible with any
license that has weaker copyleft than GPL v3 (which includes many if not
most open source licenses).


> Like many other aspects of the GPL v3, it is hard to say
> whether optional dependencies would be a problem, and it is harder to
> evaluate the MS-PL which may be compatible.

I believe some have claimed that linking to GPL code is not as forbidden
as the FSF would like it to be, so optional dependencies can perhaps be
implemented in that way. I don't see why having something optional via,
say, conditional compilation in the code would be allowed by the GPL
though.

I also don't see how GPL v3 could be compatible with MS-PL, in the sense
of combining code from GPL v3 with code from MS-PL in a single program.

> It seems clear to me that any component falling under the Corresponding
> Source definition must be able to be distributed under terms of which the GPL
> v3 must be either identical or a proper subset. Because the MS-CL provides
> per-file restrictions, I don't see how this could be met.
>
> The MS-PL is harder for me to evaluate. A lot of it depends on what 7b
> additional terms allow under the GPL v3. The MS-PL could be read as requiring
> the distribution of the license as a legal notice (seems reasonable to me)
> and possibly noting which sections of code are MS-PL-licensed. Again, this
> seems to be in line with the GPL v3 7b options by my reading.

I imagine that maintaining a copy of the MS-PL as a legal notice could be
done under section 7b of GPL v3. Now the question comes down to your
reading of the MS-PL where it says:

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

Your interpretation of the word "by" seems to be equivalent to "which is
accomplished by". I'll let others address that, but I don't think I agree
with your reading. If you take the "by" as indicating that said licensing
is incomplete without including a copy, then there is no way to meet the
requirements of section 5c of GPL v3.


> Again, I don't think this is a problem, and as a developer probably wouldn't
> worry about it. But I could see it being a question when people look at
> trying to split hairs to their own substantial benefit.

Well, I wouldn't worry about it either...I would just assume I can't mix
GPL v3 code with MS-PL code in any useful way.

---------------------------------------------------------------------------
Donovan Hawkins, PhD                 "The study of physics will always be
Software Engineer                     safer than biology, for while the
hawkins@...                   hazards of physics drop off as 1/r^2,
http://www.cephira.com                biological ones grow exponentially."
---------------------------------------------------------------------------

[Chris Travers]

Donovan Hawkins wrote:

>
> 7b allows "requiring preservation of specified reasonable legal
> notices or author attributions in that material or in the Appropriate
> Legal Notices displayed by works containing it."
>
> The phrase "that material" refers to an earlier mention of the
> "material you add to a covered work". So 7b allows attributions and
> notices in the material you add to a covered work and in the notices
> displayed by the covered work.
>
> Advertising that someone else creates for their derived work is not
> the material you added to the covered work, and it is not a notice
> displayed by the covered work. IANAL, but that doesn't seem to cover
> the old BSDL advertising clause.

"This product contains code by .... " on a Help/About screen seems like

a reasonable requirement by section 7b standards if required in other
licenses.  "This product is in part based on code by ..." seems
seimilarly allowed.  Where would the line be drawn?

This doesn't seem to preclude the sort of advertising clauses that
Internet Explorer must display regarding code from Mosaic.  Or am I
missing something?  (this is getting off-topic for this thread though).
>
>
>> I have concluded that there are major license compatibility problems
>> if a GPL v3 application *requires* components under these licenses.
>
> GPL v3 doesn't appear to prevent anyone from releasing their code
> under GPL v3 combined with code under an incompatible license. You
> just can't do that with someone else's GPL v3 code, because that is
> not a right that GPL v3 grants you.

>
> Of course, it would rather pointless for you to do it with your own
> code unless you never intend to have anyone create derivative works.
> They would be forced to remove either your code or the code under the
> other license in order to proceed.
Agreed.  Sort of like saying "nothing in the GPL prevents you from
releasing your own 100% original work under the GPL to anyone who flies
a manned mission to Pluto first" but this seems unlikely to grant any
reasonable rights....
>
> I'd say you are correct in pointing out that GPL v3 creates "major
> license compatibility problems", since it is intentionally
> incompatible with any license that has weaker copyleft than GPL v3
> (which includes many if not most open source licenses).
Are the BSD licenses incompatible with the GPL v3 simply because they
have weaker copleft than GPL v3?
>
> I believe some have claimed that linking to GPL code is not as
> forbidden as the FSF would like it to be, so optional dependencies can
> perhaps be implemented in that way. I don't see why having something
> optional via, say, conditional compilation in the code would be
> allowed by the GPL though.

My argument that optional dependencies might be excluded is that only
required dependencies are mentioned in the GPL v3 corresponding source
definition, and optional dependencies do not appear to fall inside the
four corners of that definition.  Did I miss something in 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.


>
> I also don't see how GPL v3 could be compatible with MS-PL, in the
> sense of combining code from GPL v3 with code from MS-PL in a single
> program.
>
It probably depends on what GPL v3 section 7b actually means.  IANAL,
but I could see how a simple reading of this could allow the
requirements of the MS-PL.

Does the MS-PL place any specific requirements on the code that the GPL
does not allow?  If so, what are they exactly?

>
>> It seems clear to me that any component falling under the
>> Corresponding Source definition must be able to be distributed under
>> terms of which the GPL v3 must be either identical or a proper
>> subset. Because the MS-CL provides per-file restrictions, I don't see
>> how this could be met.
>>
>> The MS-PL is harder for me to evaluate. A lot of it depends on what
>> 7b additional terms allow under the GPL v3. The MS-PL could be read
>> as requiring the distribution of the license as a legal notice (seems
>> reasonable to me) and possibly noting which sections of code are
>> MS-PL-licensed. Again, this seems to be in line with the GPL v3 7b
>> options by my reading.
>
> I imagine that maintaining a copy of the MS-PL as a legal notice could
> be done under section 7b of GPL v3. Now the question comes down to
> your reading of the MS-PL where it says:
>
> "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."
>
> 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] */

> I'll let others address that, but I don't think I agree with your
> reading. If you take the "by" as indicating that said licensing is
> incomplete without including a copy, then there is no way to meet the
> requirements of section 5c of GPL v3.

Is the license itself a reasonable legal notice?  If so, then it meets
7b options and one could force the inclusion of the license.

Best Wishes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Donovan Hawkins]

On Sun, 19 Aug 2007, Chris Travers wrote:

> "This product contains code by .... " on a Help/About screen seems like a
> reasonable requirement by section 7b standards if required in other licenses.
> "This product is in part based on code by ..." seems seimilarly allowed.
> Where would the line be drawn?

That is a very good question. I'm afraid "reasonable" is generally one of
those things that is left to the courts to decide. Common usage within the
industry is probably going to weigh heavily on their decision though.

It's pretty trivial to have an option on a menu somewhere to display a
long scroll of attributions and legal notices, so I don't think this is a
big issue for most people. You just cut-paste to the end of the big list
and move on. The user only sees the big list if they select it.


> This doesn't seem to preclude the sort of advertising clauses that Internet
> Explorer must display regarding code from Mosaic.  Or am I missing something?

GPL v3 allows requirements to retain notices on your source files and on
the interfaces. I don't see anything that allows requiring notices on
advertisements (in, say, a magazine). That sort of requirement is a
"further restriction" as defined in GPL v3 section 7:

"All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10.  If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further restriction,
you may remove that term."

So you can put the advertising term in, but it can just be ignored. If the
term came as a result of your using code under a license that contained an
advertising clause, then it is not possible to convey the combination
under section 5c. If this is your original work, then you created
something no one can make use of. If you used other GPL v3 code, then you
violated GPL v3 with respect to that code.


> Are the BSD licenses incompatible with the GPL v3 simply because they have
> weaker copleft than GPL v3?

I'm being very loose with the word "compatible" I'm afraid, but then so
are most people.

BSDL code (without the advertising clause) can be used in a project which
is released under GPL v3. GPL v3 code cannot be used in a project which is
released under BSDL.

<bad analogy alert>
GPL v3 is like having type AB blood: you can get transfusions from almost
anyone but only other AB blood people can get a transfusion from you. BSDL
is like having type O blood: almost everyone can get a transfusion from
you, but you can't accept transfusions from anyone who doesn't also have
type O blood.
</bad analogy alert>


> My argument that optional dependencies might be excluded is that only
> required dependencies are mentioned in the GPL v3 corresponding source
> definition, and optional dependencies do not appear to fall inside the four
> corners of that definition.  Did I miss something in the definition of
> "corresponding source?"

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.


Linking is another matter, and I'll defer to others on that since I think
some people disagree with the FSF on that point.


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

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


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

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


> Is the license itself a reasonable legal notice?  If so, then it meets 7b
> options and one could force the inclusion of the license.

The problem isn't keeping the legal notice. The problem is simultaneously
having the code licensed only under MS-PL and having it licensed under GPL
v3. That equation is only solvable if MS-PL == GPL, which I think we all
agree is not likley. ^^

---------------------------------------------------------------------------
Donovan Hawkins, PhD                 "The study of physics will always be
Software Engineer                     safer than biology, for while the
hawkins@...                   hazards of physics drop off as 1/r^2,
http://www.cephira.com                biological ones grow exponentially."
---------------------------------------------------------------------------

[Chris Travers]

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

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Nils Labugt]

søn, 19.08.2007 kl. 15.43 -0700, skrev Chris Travers:

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

I would read "only under this license" as "under this license and not
under any other license".

Nils Labugt

Hi Jon

Jon Rosenberg (PBM) wrote:
[]

> (D) [...] If you distribute any portion of the software in
> compiled or object code form, you may only do so under a license that
> complies with this license.

The first part of this sentence appears to limit its own application to a "portion of the software", while the second part implies that a portion of the software (perhaps all of it?), if it is compiled, is not restricted to being licensed under the MSPL.  What is the intention here?

Compliance with a license is something I think of as a person - rather than a license - doing.  Could you give some examples of what it means in practice for a license to "compl[y] with this license?"

Thanks


Brendan

[Donovan Hawkins]

On Sun, 19 Aug 2007, Chris Travers wrote:

<snipped lengthy description of a licensing chain for OpenSSL>

You seem to be right on top of the key question: does linking/dynamic
linking/using a "plugin"/connecting to an "optional module" invoke the GPL
requirements that all source be available under GPL. When that question is
answered, you have the answer to your question. AFAIK, that isn't entirely
decided currently. FSF says optional doesn't cut it (see their FAQ), and
many times have rejected linking. IIRC someone just posted to this list a
few days ago saying otherwise.

BTW, Wikipedia notes in their OpenSSL page why even the "Major Component"
exception doesn't help distros: GPL (v2 I assume but they don't indicate)
adds "unless that component itself accompanies the executable" as an
exception to being a Major Component. That makes it impossible for
anything included with a distro to make use of the exception, because the
OS itself accompanies the executable. GPL v3 doesn't appear to contain
this exception.


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

All you said was that you would use a closed-source authentication system
and treat your bindings to it as "System Libraries" under GPL v3. I don't
recally any mention of PAM or NSSWITCH.

GPL v3 seems clear that "Major Components" come with the OS/compiler and
"System Libraries" are "included in the normal form of packaging a Major
Component". That means anyone who has the OS and compiler should already
have a copy of the System Libraries and Major Components.


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

Ask RMS. I think availablility to a typical user/developer on that
platform is going to play a role in defining what is part of the
OS/compiler.

The intent of the section is abundantly clear though. If everyone already
has a copy on their system, you don't need to give them one. Doing
otherwise would make it impossible to create GPL programs to run on closed
platforms.


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

<snip>

MS-PL says "license this only under MS-PL". It is obvious that you cannot
license that code under GPL v3 (or any other license).

GPL v3 says "license everything under GPL v3". It is obvious that this
precludes using MS-PL code in a GPL v3 program.

The only remaining question of yours then is why is new BSDL compatible
with GPL v3. Note that BSDL doesn't ever say you can ONLY license it under
BSDL...it just says "you must do the following N things". GPL v3 is
capable of ensuring that those N things are done in all derived works, so
licensing under GPL v3 satisfies the requirements of BSDL and is therefore
allowed.

You'll have to talk to a lawyer if you want to debate this point further.
I merely observe this to be the way things work.

This is getting way beyond the scope of the MS-PL license discussion
thread though, so I'm going to stop here.

---------------------------------------------------------------------------
Donovan Hawkins, PhD                 "The study of physics will always be
Software Engineer                     safer than biology, for while the
hawkins@...                   hazards of physics drop off as 1/r^2,
http://www.cephira.com                biological ones grow exponentially."
---------------------------------------------------------------------------

[Chris Travers]

Just a quick note.  IANAL, TINLA, etc.

Copyright law does not appear to give you the right to restrict what
your users can do with third party code under your own copyright
licenses (provided there is no other contract involved, etc).  Therefore
no license seems to allow changing the license of the code released to
the public.  The most it can allow you to do is choose licenses for the
work as a whole.

Therefore the BSDL does not permit sublicensing or relicensing of code
if you provide it to a customer as part of a GPL application.*  All it
allows you to do is comply with the ability to provide all downstream
users with the same permissions (but not necessarily restrictions) that
the GPL offers.  Since copyright and license notices cannot be removed,
and since the original code can still be *only* distributed according to
the terms of the BSDL, there is no operational difference between the
implications of the BSDL under standard copyright law and the portions
of the MS-PL under debate.

* Of course, the BSDL itself neither requires that you give the customer
the source at all nor does it prevent you from using your own changes to
further encumber the work as a whole.

I would therefore say that *all* MS-PL-licensed code contains an
implicit GPL v3 license.

Best Wishes,
Chris Travers
>


[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Chris Travers]

Nils Labugt wrote:
>
> I would read "only under this license" as "under this license and not
> under any other license".
>  
That is an odd reading of a license that doesn't require, say, the
distribution of source code at all (as noted by the conditional).  That
seems to suggest that binary-only distributions with standard EULA's are
acceptable forms of distribution...

Best Wishes,
Chris Travers


[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[David Woolley (E.L)]

Chris Travers wrote:

> Therefore the BSDL does not permit sublicensing or relicensing of code

I think sub-licensing is normally understood to mean licensing it to a
third party.  I think even the BSD licences were intended to be licences
to everyone (public licences in the GPL terms).

> if you provide it to a customer as part of a GPL application.*  All it
> allows you to do is comply with the ability to provide all downstream
> users with the same permissions (but not necessarily restrictions) that
> the GPL offers.  Since copyright and license notices cannot be removed,

I think part of the confusion is that people are giving names, like
BSDL, or GPL, to sets of conditions on use, whereas what is actually
important is the set of conditions, and whether they are compatible.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Chris Travers <chris@...> writes:

> Well put.  I would add that I think the OSI should turn down any
> licenses from any submitters (FSF, Microsoft, or otherwise) if there
> are unanswered valid concerns about how well it meets the OSD.  But I
> think approval discussion should be limited to the scope of the
> license though polite requests may be broader.

This comes back to an old question on this list: is the OSI simply
responsible for mechanically approving licenses?  Or is the OSI
responsible for, as it says on the web site, "maintaining the Open
Source Definition for the good of the community"?  In my opinion,
which I acknowledge is not widely held, the good of the community does
not require approving every applicable license.

That said, I personally would be in favor of approving the Microsoft
licenses.  I think it is overall a benefit to the community to
acknowledge that code under these licenses is open source.

Of course, it also means that we need to apply extra vigilance to
ensure that Microsoft does not attempt to use this certification to
further confuse end-users with their non-open-source licenses.  I
don't think is as big of a risk as it used to be, as it seems to me
that most people tend to distrust Microsoft these days (for a long
time hackers distrusted Microsoft, but the general public liked them).

Ian

[Chris Travers]

Hi Ian;

Here is my opinion regarding where OSI should draw the line an why.  
Others I am sure will have different views.

Ian Lance Taylor wrote:
>
> This comes back to an old question on this list: is the OSI simply
> responsible for *mechanically* approving licenses? [emphasis mine]
No.  Is there anyone here who thinks otherwise?
>   Or is the OSI
> responsible for, as it says on the web site, "maintaining the Open
> Source Definition for the good of the community"?
Yes.
>   In my opinion,
> which I acknowledge is not widely held, the good of the community does
> not require approving every applicable license.
>  
Agreed as far as you take it.  However, I would suggest that we ought to
be careful about invoking the "Good of the Community" lightly and try to
have fair and even-handed standards of acceptance.  Being fair and
even-handed is fundamentally good for the community.  Does anyone
honestly disagree with this premise?

Suppose someone ran an OSI-approved license such as the BSDL through a
sed program that changed names.  Should that be approved?  Probably not
(we might want to state that we believe that it is simply a BSDL variant
not different enough to get a separate listing).  Same permissions might
mean no separate approval necessary or possible.

However, the following problems occur when we look at approving licneses:

1)  If a license has different legal terms than other licenses (because
different lawyers see things differently), are we *ever* in a position
to reject that license simply on a nonproliferation basis?  Are we ever
justified in saying "We don't think your attourneys'  concerns are
justified?"

My answer here is that we should work with groups sponsoring similar
licenses to help them cooperate on consolidating their licenses for the
future, but should not reject licenses solely on nonproliferation bases
when license terms are arguably different.

2)  Is there ever a time when we should consider *who* is submitting a
license as a part of the formal approval process?  I don't think so.  I
think that being fair and evenhanded is *always* in the best interests
of the community.

Obviously, the less individuals trust the submitter, the more scrutiny
they might place on the license.  It is OK to say "I don't trust
Microsoft/FSF/The Foo Corporation/Whoever else.  Therefore I am going to
look more closely for a reason we should reject."  However that is
different than "I don't like them so they should be forced to justify
why we should get beyond this hurdle."
> That said, I personally would be in favor of approving the Microsoft
> licenses.  I think it is overall a benefit to the community to
> acknowledge that code under these licenses is open source.
>
> Of course, it also means that we need to apply extra vigilance to
> ensure that Microsoft does not attempt to use this certification to
> further confuse end-users with their non-open-source licenses.
Agreed as far as you take it.  I thought my post about the FSF said the
same things about extra vigilance there too but some people took it as
some sort of inquisition.

Again, distrust of the organization should not be, IMO, sufficient
reason to reject.  It is sufficient reason to think about the licenses a
lot more closely and ask if they are *truly* open source licenses or not
by the terms of the OSD.  But eroding the OSD based solely on distrust
does not serve the good the the community.  "The licensors are trusted
by OSI" sems

>   I
> don't think is as big of a risk as it used to be, as it seems to me
> that most people tend to distrust Microsoft these days (for a long
> time hackers distrusted Microsoft, but the general public liked them).
>  
I still don't *trust* Microsoft.  I think that their response to open
source is disorganized and confused and this makes them dangerous
because you don't really know which faction will win the battles at the
end of the day.  At some point they may become trapped by the rhetoric
they use to appease stockholders and forced to initiate patent suits.  
Make no mistake, Microsoft because their market position and possibly
even future is threatened is extremely dangerous.  Even if they
uniformly had the best of intentions *now* this would not make them less
dangerous.  They are dangerous simply because at the moment they are
unpredictable.

Having said this, that is no basis in my mind to reject the license.  
Rejecting simply due to such concerns and hence reducing any leverage we
may have in helping Microsoft learn how to work with open source without
losing their revenue (yes it is possible), and establishing that there
is a higher standard for outsiders to participate than for insiders
would not serve the good of the community by any standard, except for
those who see this as the sort of perpetual conflict where expediency
must exist before ethics.

Best Wishes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---

[Chris Travers]

Chris Fagan wrote:
>  A design goal of the MS-PL is to allow developers to choose to ensure that the specific rights in Section (2) continue to be available to downstream developers and users through generations of adoption and adaptation.
>  
I guess the questions people are asking include:

Does Microsoft see any problems including MS-PL code in applications
licensed under other arbitrary licenses provided that the license offers
a subset of  MS-PL rights?  I.e. if the software is distributed in
source form can sections of code other than those under the MS-PL code
have any other arbitrary restrictions?  Can a work as a whole include
restrictions absent from the MS-PL license.  Is this a design goal?

I am phrasing this in a way to leave out the requirement of analyzing
other licenses (such as the GPL v3).  This way you can leave it up to
the attourneys whether or not such conflicts exist with specific
licenses :-).

Best WIshes,
Chris Travers

[chris.vcf]

---

begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@...
tel;work:509-888-0220
tel;cell:509-630-7794
x-mozilla-html:FALSE
version:2.1
end:vcard

---