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 with the nVidia drivers which
is why, despite harsh critism by the FSF, they have not yet suggested that nVidia's
closed source kernel drivers are in fact a license violation.

It becomes a harder question when you ask whether distributing Linux with ndiswrapper
*and* appropriate Windows NDIS drivers constitutes a violation based on the work as a
whole now including those closed source drivers.  In short, I wonder if distributors
would be liable where developers might not be and if there are cases where mere
aggregation can actually create a new covered work, extending the license to other
components listed on the same media.

In short, I think the question of linking GPL code with non-GPL-compatible code is more
complex than the FSF wants to publically admit and center around what is actually
included in the "work as a whole" as well as what is actually "derivative."  The above
examples would be areas where I would argue the proprietary code is neither derivative
nor part of the same "work as a whole" and is hence can be linked after distribution.
Again, IANAL.....

Now, this is not a *total* thread hijack as it actually comes back to the question of
GPL v3 approval.

Possible Problem:
Basically, there exists a possible concern that a GPL v3 covered work could exist in a
synthetic (and hence contageous) form which might extend to otherwise uncovered works
aggregated on distribution media.  Here is the case I am thinking of:

OS Kernel under GPL v3.
Proprietary driver originally written for Windows.
LGPL v3 bridge allowing Windows drivers to be loaded.

Ordinarily, it would be hard to argue that the proprietary Windows drivers were part of
the same work as a whole as the kernel, but if they were distributed together on the
same media, an argument could be made that they are.  In the GPL v3, it seems to me that
the case is harder to make, but might be possible if a hardware/software bundle required
those drivers.

Analysis:
The GPL v2 is actually worse in this regard than the GPL v3, and it has long been deemed
an OSD-compatible license.  It seems to me therefore that if the GPL v2 is recognized,
that:

1)  This specific problem should be seen as outside of the scope of the OSD and
2)  The FSF deserves some credit for addressing this problem more clearly in this license
by limiting the requirements to *requirements* as opposed to all libraries which may or
may not be indirectly linked.  This also helps to address issues of "I link to library x
and it *might* link to OpenSSL depending on compile-time options so what then?"

In short I do not think that this problem should prevent adoption of the GPL v3.  I have
other concerns however (over whether it is really technologically neutral and whether it
discriminates against fields of endeavor) which I have already posted.

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]

I guess I sent my concerns some time before I was actually subscribed.
If they come through separately, I appologize for the re-post.

I see a number of possible issues with the GPL v3. I will list them with
the sections of the OSD here:

6: No discrimination against fields of endeavor:
The license must not restrict anyone from making use of the program in a
specific field of endeavor. For example, it may not restrict the program
from being used in a business, or from being used for genetic research.

I think that the anti-Tivoization provision in the GPL v3 effectively
prevent its use (or at best are not technology-neutral regarding its
use) in areas such as, say, WIFI card firmware, or the like where the
hardware/software package is subject to sufficient regulation as to
prevent the user from being able to make arbitrary modifications ot the
code and still run it on that specific piece of hardware.

9: License must not restrict other software
The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.

I suspect there are *cases* where the GPL (both versions 2 and 3) fail
in this regard, particularly where works which might be considered
separate when distributed separately might be considered the same work
when distributed together. I don't see this as an obstacle, but want to
mention it anyway. See below.

10: License must be technology-neutral
No provision of the license may be predicated on any individual
technology or style of interface.

There are GPL v3 provisions which are predicated on the distribution of
software in restricted environments being limited to ROMs.

Further Discussion and Recommendations:

OSD Sections 6 and 10 vs the anti-Tivoization provisions in the GPL v3.
The GPL v3 added provisions which require one who conveys GPL v3
software with a user product (such as a Tivo) to provide installation
instructions sufficient to get user-modified software running on the
system. The direct target of this change was Tivo, but the larger
concern appears to be the interplay between software and hardware. In
essence the GPL v3 requires that these are treated as entirely separate
goods unless the software is distributed via a method whereby nobody has
the ability to change it (for example, a ROM). The intent was to prevent
GPL v3 software from being used in unTrustworthy Computing platforms in
a way which were not fully usable when the source was changed by the end
user.

The relevant section of the license is:

'“Installation Information” for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product
from a modified version of its Corresponding Source. The information
must suffice to ensure that the continued functioning of the modified
object code is in no case prevented or interfered with solely because
modification has been made.

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

As a side effect, this effectively bans the use of GPL v3 code in any
device which requires government certification of the hardware/software
package (such as a WIFI card and related firmware). It could also
prohibit use of GPL v3 software in voting machines in that it would be
illegal for the counties that use the machines (and hence distribute the
software) to prohibit modifications of the software through technical or
legal means. In fact the only option open in these cases is to remove
the ability to do any vendor updates (including security updates) from
the products in question and hence take on a substantial competitive
handicap.

I would recommend that the FSF drop the questionable provision before
this is adopted. It violates either portion 6 or 10 of the OSD by my
reading, depending on how I read the OSD and the GPL v3.

As for OSD section 9: There are cases where the GPL, versions 2 and 3
may affect other software on the same media even when it might not were
they separate.

IANAL, but I see a few cases where this could happen. I will draw
parallels between existing cases in the GPL v2 in this section, however.

For code to fall under the GPL licensing requirements when linking to a
GPL application, it would need to be either a) derivative of that GPL
application or b) part of the same "covered work." If neither of these
apply, then the GPL licensing requirements don't apply either.

For example, ndiswrapper provides, under a GPL-compatible license, a way
of linking NDIS Windows drivers (closed source) to the GPL v2-licensed
Linux kernel. I do not believe that this is a GPL violation when the
Windows drivers are distributed separately because they are not
derivative of the Linux kernel nor are they by any reasonable measure
part of the same work just (being independantly written and distributed).

A similar case I believe exists with regard to the nVidia closed source
drivers for Linux. Again, the proprietary code is non-derivative, a
compatibly-licensed bridge exists, and the software is distributed
seprately. (This same argument might *not* apply to the Apple ObjC
plugins for the GCC because it is not clear to me that these were
written for another environment and that a compatibly licensed bridge
existed.)

However, what happens now when I pre-install those same nVidia or wifi
drivers on a Linux-based laptop that I sell? Can it then be argued that
I am, in distributing both the closed source and open source packages
together essentially creating a new "covered work" based on the "Linux
kernel" but that license incompatibilities forbid me from distributing
it? In short, there are cases where mere aggregation *may* under the GNU
GPL (versions 2 or 3) create new covered works which hold a distributor
liable for copyright infringement even when the original developers are not.

However, the fact is, the GNU GPL v2 has been accepted as an
OSI-compatible license for some time and the GNU GPL defines source code
and covered work a little more tightly than does the GPL v2. Therefore
the GPL v3 is an improvement in this case and I believe it would be
inconsistant of this organization to let this specific problem (of OSD
part 9) get in the way of approval. I would therefore hope the OSI would:

1) State specifically that definition 9 does not apply to cases where
these problems only exist in corner cases.
2) Thank the FSF for helping to reduce the impact of this problem in
version 3 of this license.

I would therefore suggest that we consider either clarifying why the GPL
does not erode or volate OSD sections 6 and 10, or ask that they drop
the anti-Tivoization clauses prior to approval.

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

---