For Approval: GPLv3
chris at metatrontech.com
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
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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 171 bytes
Desc: not available
More information about the License-discuss