For Approval: GPLv3

[Russ Nelson]

See Chris DiBona's approval request here:
http://crynwr.com/cgi-bin/ezmlm-cgi?3:sss:13072:200707:nifbaainbjiiahpeankh#b
with more discussion here:
http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:13098:200707:fdleeeclihhhobfbmbnn
and here as well:
http://crynwr.com/cgi-bin/ezmlm-cgi?3:sss:13296:200708:mnagdpgjpcanfbikcobl#b

Please discuss the GPLv3 here, to avoid further fragmentation:

--
--my blog is at    http://blog.russnelson.com   | People have strong opinions
Crynwr sells support for free software  | PGPok | about economics even though
521 Pleasant Valley Rd. | [phone]       | they've never studied it.
Potsdam, NY 13676-3213  |     Sheepdog          | Curious how that is!

[Luis Villa-3]

More useful archive URLs inline, and then a summary of previous
comments on OSD compliance below to re-start discussion about v3's OSD
compliance (and only the OSD compliance :)

On 8/6/07, Russ Nelson <nelson@...> wrote:
> See Chris DiBona's approval request here:

http://www.nabble.com/Submitting-GPLv3-and-LGPLv3-for-OSI-inclusion.-tf4001061.html

> with more discussion here:

http://www.nabble.com/forum/ViewPost.jtp?post=11916798&framed=y

> and here as well:

http://www.nabble.com/conducting-a-sane-and-efficient-GPLv3%2C-LGPLv3-Review-tf4197233.html

> Please discuss the GPLv3 here, to avoid further fragmentation:

Some comments from within the threads (all conclude in favor of
approval, but I can't find any serious commentary which concludes that
the license is not OSD compliant):

Matthew Flaschen did the only thorough section-by-section review that
I can find:
http://www.nabble.com/Re%3A-Submitting-GPLv3-and-LGPLv3-for-OSI-inclusion.-p11367961.html

He concluded that it is compliant. If anyone wants to discuss actual
planks of the license, I recommend copying and pasting the relevant
portion of Matt's analysis into this thread and going from there.

Past that, the comments appear to mostly be either not about OSD
compliance, or strongly in favor:

Lawrence Rosen commented "GPLv3 is obviously OSD-compliant. Let's get
right to the point. It is an open source license, even if RMS prefers
to use a different name for it. :-)"

Rick Moen, in reply to that: "Indeed, I think what you say is
abundantly obvious, and doing anything else would merely waste
everyone's time." (both from
http://www.nabble.com/forum/ViewPost.jtp?post=11938684&framed=y )

Mark Radcliffe summarized the new license in his blog:
http://lawandlifesiliconvalley.blogspot.com/2007/07/general-public-license-version-3-legal.html

and said on-list that we should have a review, but that "I am
confident that it will pass the review." (from
http://www.nabble.com/forum/ViewPost.jtp?post=11918577&framed=y )

Jesse Hannah noted: "As far as I can tell, the only question between it and the
OSD would be over OSD number 9, and even that I don't think comes out
to be anything that would keep it from getting approved. That's just
at a glance, but personally I'm surprised it isn't approved already."
(from    http://www.nabble.com/forum/ViewPost.jtp?post=11937846&framed=y
)

Hope this summary is useful. As I said, it is so far overwhelmingly
positive (on the question of actual OSD compliance), but I can see
some possibility for reasonable discussion and disagreement raised by
Matthew's review. I would urge anyone who wants to discuss it in more
detail to read his post and reply to it here.

Luis

[Disclaimer: like Mark, I participated in the GPL drafting process, so
I am invested in it, but my own casual review suggests that the
license is OSD-compliant.]

[Wilson, Andrew-2]

luis.villa@... wrote:

> More useful archive URLs inline, and then a summary of previous
> comments on OSD compliance below to re-start discussion about v3's OSD
> compliance (and only the OSD compliance :)

and see my post here
http://www.nabble.com/conducting-a-sane-and-efficient-GPLv3%2C-LGPLv3-Re
view-tf4197233.html
with the comments about lack of compatibility between GPL versions and
the
as-yet-unwritten OSD principle bounding license proliferation.

To my mind, this is one of the true ideological differentiators between
"open source"
and "free SW."  Open source is about growing the commons; free SW as
espoused
by FSF & RMS is about creating a maximally free class of SW, and
maximizing
utility of that free SW with the existing FLOSS base for the sake of
growing a commons is a non-goal for them.
This is an opportunity for OSI (IMO) to make the point that while
GPLv/LGPLv3
are OSD-compliant licenses, there is still a valid ideological
distinction
between free SW as defined by FSF and open source.

Andy Wilson

[davelab6]

On 08/08/2007, Wilson, Andrew <andrew.wilson@...> wrote:
>
> Open source is about growing the commons

One of the key benefits of v3 is that it is compatible with more
licenses than v2, and the license consolidation suggests to me that
growing the commons is a just as much a goal of the free software
movement as the open source movement.

For me the true ideological differentiator is that open source is
about closed source being okay.

--
Regards,
Dave

[Matthew Flaschen]

Wilson, Andrew wrote:
> To my mind, this is one of the true ideological differentiators between
> "open source" and "free SW."  Open source is about growing the commons; free SW as
> espoused by FSF & RMS is about creating a maximally free class of SW, and
> maximizing utility of that free SW with the existing FLOSS base for the sake of
> growing a commons is a non-goal for them.

I think this is quite incorrect.  The FSF spent significant effort in
making GPLv3 compatible with Apache and in eliminating other
compatibility problems.  And they have always maintained a list of
licenses compatible with the GPL.

Meanwhile, OSI has approved every license viewed to be compliant with
the OSD, with little concern for compatibility.  OSI doesn't maintain
any kind of compatibility matrix.

From another perspective, why should we approve CPAL, which is
incompatible with both GPLv2 and "GPLv2 or later" software and unlikely
to become a significant part of the commons, but not GPLv3, which is
supported by major FOSS organizations and compatible with "GPLv2 or later"

Matt Flaschen

[Dag-Erling Smørgrav-2]

Matthew Flaschen <matthew.flaschen@...> writes:

> "Wilson, Andrew" <andrew.wilson@...> writes:
> > To my mind, this is one of the true ideological differentiators between
> > "open source" and "free SW."  Open source is about growing the commons; free SW as
> > espoused by FSF & RMS is about creating a maximally free class of SW, and
> > maximizing utility of that free SW with the existing FLOSS base for the sake of
> > growing a commons is a non-goal for them.
> I think this is quite incorrect.  The FSF spent significant effort in
> making GPLv3 compatible with Apache and in eliminating other
> compatibility problems.  And they have always maintained a list of
> licenses compatible with the GPL.

You have a short memory, or maybe you weren't around when the GNOME
project was started, or when Stallman later stabbed Trolltech in the
back after they had spent considerable time and effort making their
license GPL compatible, or when he announced that enough people had
swallowed the LGPL bait and glibc should switch to the GPL (luckily,
the glibc maintainers declined).

DES
--
Dag-Erling Smørgrav
Senior Software Developer
Linpro AS - www.linpro.no

[Wilson, Andrew-2]

 
Matthew Flaschen wrote:

> From another perspective, why should we approve CPAL, which is
> incompatible with both GPLv2 and "GPLv2 or later" software and
unlikely
> to become a significant part of the commons, but not GPLv3, which is
> supported by major FOSS organizations and compatible with "GPLv2 or
later"

As I've stated on this list (several times now) GPL and LGPLv3 should
be approved, since they do, IMO, meet the OSD.  On the other hand
OSI does have an opportunity to send a pro-compatibility message
to FSF along with approval.

> The FSF spent significant effort in
> making GPLv3 compatible with Apache and in eliminating other
> compatibility problems.  And they have always maintained a list of
> licenses compatible with the GPL.

This is a good example of why emphasizing compatibility to FSF is a good
idea.
As you know, defensive suspension of the patent grant was present in
early
drafts of GPLv3 but dropped in the final version.  Apache 2.0, with
its defensive suspension provision, would not show up as 'compatible'
on FSF's matrix absent a generous reading of GPLv3's termination
and liberty-or-death provisions on FSF's part.  FSF should be
encouraged to continue working in this spirit.

As far as approving new licenses such as CPAL, OSI is stuck until
we codify pro-compatibility as an explicit component of OSD.
The anti-license-proliferation discussion has been 'resting' of
late; perhaps it can be re-awakened as pro-compatibility.

Andy Wilson
Intel open source technology cneter

[Rick Moen]

Quoting Dag-Erling Smørgrav (des@...):

> You have a short memory, or maybe you weren't around when the GNOME
> project was started, or when Stallman later stabbed Trolltech in the
> back after they had spent considerable time and effort making their
> license GPL compatible...

Not that Trolltech ASA were in any way responsible for the KDE licensing
blunder (they weren't, and remain with the Opera Software ASA staff my
second-favourite bunch of crazy Norwegians after my tante Bjorg and my
onkel Reidar[1]), but QPL 1.0 was very clearly, but tragically
GPLv2-incompatible: the patch clause, plus the initial-developer clause,
contravene section 2b.  This was pretty obvious to long-time
licensing-watchers (see: http://freshmeat.net/articles/view/172/), but I
think Trolltech kept not quite grasping the underlying copyright /
derivative works issue.

I'm very sympathetic, and they took a great deal of undeserved flak for
a problem not of their making, but they were in fact simply incorrect
about QPL 1.0 being compatible.

[1] No slight intended to any other crazy Norwegians present.  ;->

[Dag-Erling Smørgrav-2]

Rick Moen <rick@...> writes:

> Quoting Dag-Erling Smørgrav (des@...):
> > You have a short memory, or maybe you weren't around when the GNOME
> > project was started, or when Stallman later stabbed Trolltech in the
> > back after they had spent considerable time and effort making their
> > license GPL compatible...
> Not that Trolltech ASA were in any way responsible for the KDE licensing
> blunder (they weren't, and remain with the Opera Software ASA staff my
> second-favourite bunch of crazy Norwegians after my tante Bjorg and my
> onkel Reidar[1]), but QPL 1.0 was very clearly, but tragically
> GPLv2-incompatible: the patch clause, plus the initial-developer clause,
> contravene section 2b.  This was pretty obvious to long-time
> licensing-watchers (see: http://freshmeat.net/articles/view/172/), but I
> think Trolltech kept not quite grasping the underlying copyright /
> derivative works issue.

I am not referring to the QPL 1.0, but to a later version in which
Trolltech tried to correct the mistakes from QPL 1.0, with assistance
from the FSF, only to have Stallman turn on them after they released
it.  He plays the bait-and-switch game down to the fingertips.

DES
--
Dag-Erling Smørgrav
Senior Software Developer
Linpro AS - www.linpro.no

[Rick Moen]

Quoting Dag-Erling Smørgrav (des@...):

> I am not referring to the QPL 1.0, but to a later version in which
> Trolltech tried to correct the mistakes from QPL 1.0, with assistance
> from the FSF, only to have Stallman turn on them after they released
> it.

Can you tell me anywhere at all that I can verify this assertion?  I
cannot find the text of any post-1.0 draft or even any description
of one, anywhere on the Net, and Trolltech do not currently appear to
have anything but the original 1.0 text.  

I see Eirik Eng talking at several points about dropping QPL's patch and
developer-access clauses; those are and were to the best of my
recollection the sole compatibility obstacles.

I'm not saying you're wrong; I'm just saying that I'd rather see
something objectively verifiable and real than merely the still glowing
embers of past interpersonal flamewars -- and I note that the Trolltech
guys _did_ seem to not quite grasp the issue during the discussions
surrounding the 1.0-release timeframe.

[Dalibor Topic]

Dag-Erling Smørgrav <des <at> linpro.no> writes:

> You have a short memory, or maybe you weren't around when the GNOME
> project was started, or when Stallman later stabbed Trolltech in the
> back after they had spent considerable time and effort making their
> license GPL compatible, or when he announced that enough people had
> swallowed the LGPL bait and glibc should switch to the GPL (luckily,
> the glibc maintainers declined).

Please use gnu.misc.discuss instead of this mailing list for discussion of
positive or negative traits of Mr. Stallman. Thank you.

cheers,
dalibor topic

[Dalibor Topic]

Luis Villa <luis <at> tieguy.org> writes:

> Hope this summary is useful. As I said, it is so far overwhelmingly
> positive (on the question of actual OSD compliance), but I can see
> some possibility for reasonable discussion and disagreement raised by
> Matthew's review. I would urge anyone who wants to discuss it in more
> detail to read his post and reply to it here.

OSD Compliant. Both of them. Next license, please. ;)

cheers,
dalibor topic

[Dalibor Topic]

Wilson, Andrew <andrew.wilson <at> intel.com> writes:

> As far as approving new licenses such as CPAL, OSI is stuck until
> we codify pro-compatibility as an explicit component of OSD.
> The anti-license-proliferation discussion has been 'resting' of
> late; perhaps it can be re-awakened as pro-compatibility.

That sounds interesting. Would you care to elaborate on another thread what you
have in mind? Thank you.

cheers,
dalibor topic

[Matthew Flaschen]

Dag-Erling Smørgrav wrote:
> You have a short memory, or maybe you weren't around when the GNOME
> project was started

You mean the same GNOME project that uses LGPL specifically to allow
proprietary applications to be compatible with the libraries?

, or when Stallman later stabbed Trolltech in the
> back after they had spent considerable time and effort making their
> license GPL compatible

What are you talking about?  The QPL was obviously not GPL-compatible,
and Qt thus now uses the GPL.

, or when he announced that enough people had
> swallowed the LGPL bait and glibc should switch to the GPL (luckily,
> the glibc maintainers declined).

The glibc maintainers don't hold copyright.  glibc is still under the
LGPL because the FSF agreed to keep using that license.

Matt Flaschen

[Matthew Flaschen]

Wilson, Andrew wrote:

> As I've stated on this list (several times now) GPL and LGPLv3 should
> be approved, since they do, IMO, meet the OSD.  On the other hand
> OSI does have an opportunity to send a pro-compatibility message
> to FSF along with approval.
>
>> The FSF spent significant effort in
>> making GPLv3 compatible with Apache and in eliminating other
>> compatibility problems.  And they have always maintained a list of
>> licenses compatible with the GPL.
>
> This is a good example of why emphasizing compatibility to FSF is a good
> idea.
> As you know, defensive suspension of the patent grant was present in
> early
> drafts of GPLv3 but dropped in the final version.

I don't know what you mean.  GPLv3 final says:

"you may not initiate litigation (including a cross-claim or
counterclaim in a lawsuit) alleging that any patent claim is infringed
by making, using, selling, offering for sale, or importing the Program
or any portion of it."

Violations of this will result in termination:

"(including any patent licenses granted under the third paragraph of
section 11)."

  Apache 2.0, with
> its defensive suspension provision, would not show up as 'compatible'
> on FSF's matrix absent a generous reading of GPLv3's termination
> and liberty-or-death provisions on FSF's part.

Do you think the above clauses are insufficient for compatibility with
the Apache 2.0 patent clauses?  I think FSF believes in good faith that
Apache 2.0 is compatible.

> As far as approving new licenses such as CPAL, OSI is stuck until
> we codify pro-compatibility as an explicit component of OSD.

I think this may be too subjective as a criterion.  Anyway, my point is
that GPL should not be singled out as anti-compatibility, which it isn't.

Matt Flaschen

[Nils Labugt]

tor, 09.08.2007 kl. 23.32 -0400, skrev Matthew Flaschen:

> I think this may be too subjective as a criterion.  Anyway, my point is
> that GPL should not be singled out as anti-compatibility, which it isn't.


>From GPLv3:

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

It is this type of restrictions that are the source of the compatibility
problems. The MPL cannot be converted to CDDL, or vice versa, but that
is not much of a problem since files with those licenses can be linked
together. If I license my libraries under the CDDL, then it is the GPL
that prevents those libraries from being used in GPL programs, not the
CDDL. (And those libraries might be considered independent works,
depending on the jurisdiction.)


Nils Labugt

[Matthew Flaschen]

Nils Labugt wrote:

> tor, 09.08.2007 kl. 23.32 -0400, skrev Matthew Flaschen:
>
>> I think this may be too subjective as a criterion.  Anyway, my point is
>> that GPL should not be singled out as anti-compatibility, which it isn't.
>
>
>>From GPLv3:
>
> "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."

Yes, GPL has strong copyleft; this is a deliberate sacrifice of
downstream compatibility.  Unlike MPL, GPL is designed so you can't e.g.
factor out new but closely related functions into a different file.  If
the combination legally forms a derivative work of the GPL part, the
whole thing must be licensed under the GPL.

But this has always been part of the GPL, and didn't stop GPLv2 from
getting approved or becoming the most popular license.

Matt Flaschen

[Chris Travers]

I have the following concerns about the GPL v3.  I dont know if these
got onto the list yet so if they did, I appologize for the repost.

The GPL v3 either violates or erodes the Open Source Definition
   1)  Discrimination against fields of endeavor:  The anti-Tivoization
clauses effectively prohibit use of GPL v3 code in any device which
requires certification of a hardware/software bundle.  Examples would
include firmware of wireless network cards, and other devices which
require such certification by the FCC.

  2)  The license may not be technology neutral with regard to
hardware/software bundles which must be certified by the FCC or similar
entities.  In these cases, there is a distribution *requirement* that
the software is included in read-only media which is *not* subject to
vendor updates.

I would recommend requesting that the FSF drop or revise the following
clauses before the OSI approves the license:

Section 6-- the following paragraph:
"If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied by
the Installation Information. But this requirement does not apply if
neither you nor any third party retains the ability to install modified
object code on the User Product (for example, the work has been
installed in ROM)."

In the alternative, I would request that the FSF clearly expand the
interpretation of the following  such that hardware components which
access public airwaves (or similar networks) may also be disabled for
tampered software where required by appropriate government regulation:

"Access to a network may be denied when the modification itself
materially and adversely affects the operation of the network or
violates the rules and protocols for communication across the network."

In the absense of these, it is hard to see how the GPL v3 allows vendors
of regulated solutions which require full-package certification (of a
hardware/software bundle).  This strikes me as a clear and intentional
(on the FSF's part) discrimination against a field of endeavor which is
incompatible with the OSI's Open Source Definition.

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]

>>From GPLv3:

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

>It is this type of restrictions that are the source of the compatibility
>problems. The MPL cannot be converted to CDDL, or vice versa, but that
>is not much of a problem since files with those licenses can be linked
>together. If I license my libraries under the CDDL, then it is the GPL
>that prevents those libraries from being used in GPL programs, not the
>CDDL. (And those libraries might be considered independent works,
>depending on the jurisdiction.)

IANAL, and this seems sort of off-topic anyway, but anyway....

I was just reading this again and noticed something I had missed the first time.
It does indeed look like you could not have a GPL program *require* (language of
the GPL v3) a CDDL library.  However, if the CDDL library is used as an *optional*
add-on through an appropriately licensed bridge (say LGPL) which is also distributed
separately, it would seem to be no more of a violation than, say, distributing Linux
with ndiswrapper would be, (a similar case probably exists w