For Approval: GPLv3

Thu Aug 16 00:23:43 UTC 2007

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chris.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070815/ddc18b59/attachment.vcf>