GPLv3 Draft 3 Comments

This is an annotated copy of a letter I sent to the FSF in April 2007. The individual comments were also added to their comment tool (list of my comments).

My name is Gervase Markham; I am first point of contact for copyright and some trademark issues for the Mozilla project. The Mozilla codebase is extremely large, and most of it is available under the GPLv2 or later, and also other licenses. I therefore have a reasonable amount of experience in reading, interpreting and applying license terms. However, I am offering this document in a personal capacity.

Here follow my comments on the GPLv3 draft 3. I believe I've found two bugs; I also present a number of suggestions for improvement, either legal, practical or authorial.

Before I begin, I would like to commend the FSF on their comment and discussion process, which seems to me to have an unprecedented level of openness and inclusion, and on their willingness to make major changes to the drafts based on feedback received.

I am particularly impressed with the new definition of Installation Information, which replaces the requirements surrounding cryptographic keys. This seems to me to be an excellent example of replacing a definition of mechanism with one of policy.

Bugs

The bugs are, clearly, the most important things and so I present them first.

1. Breaks hardware reseller business model

Section 6c) (show) has a bug. Let's imagine I'm in the business of buying consumer hardware in bulk and reselling it - a common business model. If I buy a pallet of routers which contain GPLv3 software and come with a 6b) written offer, can I resell them as-is? My reading of the definition of "propagate" and "convey" leads me to believe that this reselling is "conveying", which I may only do under one of sub-clauses a) to e) of section 6.

I am not covered by 6b) because it's not my offer, and I'm not offering support or spare parts. What about 6c)? The current wording suggests no, because it permits such conveying only "occasionally and non commercially", and my conveying is regular and commercial. Do I have to download the source, burn to a CD and pop it in the box (thereby being covered by 6a) before I can resell it? Surely the license must make it possible for me to merely pass on the boxes as I receive them.

My suggestion is add another exception to the "occasionally and non commercially" one, to permit passing on copies you received. One might phrase a modified 6c) as follows:

c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only if you received the object code
with such an offer (in accord with subsection 6b) and either:
- you are conveying copies that were conveyed to you; or
- your conveying is occasional and non-commercial.

So the extra exception permits a high-volume and commercial business model reselling items, yet one cannot use it to increase the number of copies the offer covers. The danger of a large increase of this type and the consequent unfair effect on the person making the written offer is, as I understand it, the reasoning behind the "occasional and non-commercial" wording.

Since I wrote this, it has been suggested that what the resellers are doing is not covered by copyright law, and so cannot be covered by the GPLv3. The doctrine of first sale is also important here. I suggest this point needs to be clarified.

2. Large loophole in anti-Tivoisation clause

There is a bug in the paragraph in section 6 beginning '"Installation Information" for a User Product...'. (show) Let's imagine I am making a User Product whose primary purpose is to communicate over a network. There is a networking chip with proprietary firmware in ROM which manages the voltages on the wires. The product's main processor runs a GPLv3 OS and kernel. The kernel has a device driver which exchanges packet information with that chip.

I can write a proprietary boot loader which checksums my kernel and, if the checksum fails (i.e. the kernel has been modified), sends a signal to the networking hardware to stop putting packets on to the wire, thereby rendering the product useless. The chip continues to behave normally in all other ways. This is not forbidden by the license, because the relevant paragraph in section 6 reads:

The information must suffice to ensure that the continued functioning of
the modified object code is in no case prevented or interfered with

The object code is functioning exactly as it did before - it is passing networking packets to the networking chip. So this system does not fall foul of this clause. I think this is a large loophole, and permits Tivoisation schemes. I believe the following two-word change will achieve the desired effect:

The information must suffice to ensure that the continued functioning of
the modified User Product is in no case prevented or interfered with

Practical/Legal

1. Section 5d) - GUI notifications

There is much to say about section 5d) (show). As I understand it, the purpose of this section is to make sure that users of the program know their rights. However, I believe it has several practical and philosophical problems. In true lawyerly fashion, I will try multiple possible arguments:

• 5d) is misplaced in section 5, given that it really relates to object code forms and yet 5 is a source code section.
• 5d) is redundant, given the existence of section 5b) and the word "prominent" therein, and the existence of section 4, para 1 (which is applicable because of the inclusion of the terms of 4 into 5 - see 5 para 1).
• Examples such as menus are bad because they will date the license and may force a particular inappropriate implementation of the underlying goal.
• The current way 5d) is phrased is close to being (some would say, is) a restriction on modification, thereby violating freedom 1.
• The current version of 5d) is more intrusive in that regard than the version in GPLv2, and applies in more circumstances.
• 5d) should be written to focus on policy, not mechanism - as was done to turn the requirement to surrender keys into the requirement to provide Installation Instructions.

I believe 5d) should be scrapped entirely but, if that is not to be, perhaps something like the following wording would achieve the goal while alleviating the problems in the latter half of the list:

d) If the work has interactive user interfaces, users of each
interface must have an easily-discoverable mechanism to display an
appropriate copyright notice, and to be told:
- the extent of the warranty, or lack of it, for the work;
- that licensees may convey the work under this License;
- how to view a copy of this License.
However, if the work has interactive interfaces that do not comply with
this subsection, your changes need not make them comply.

This rephrasing removes most things that might be construed as a restriction on modification, and becomes solely an expression of policy - you must make users aware of their rights.

2. Making CD Distribution Easier

A common method of distributing free software is the handing out of CDs, for example at trade shows or conferences. With some sets of software, such as the Debian GNU/Linux distribution, there are a large number of CDs of source to go with the binaries. Which of the section 6 options (show) can people doing such distribution take?

• 6a) requires handing out of source CDs to everyone, whether they want them or not, raising the cost of distribution significantly;
• 6b) puts a high burden on the distributor, who is often a non-commercial GLUG or similar, and may not have an arrangement with the original software developers;
• 6c) might apply if they can obtain the CDs from someone who has made such an offer, but they are most often home-made. Also, there is doubt about whether regular activity of this sort would remain "occasional".

6d) is almost perfect, but it is focussed on network distribution. The generalisation of a single word in 6d) - "copy" -> "obtain" - makes it much easier to distribute free software in this way:

d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to obtain the
Corresponding Source along with the object code.

The CDs could then be distributed under 6d), with the "designated place" being the distribution location. There would be a pile of binary CDs and one of source; people could take the source CDs or not, as they chose.

3. "User Products" definition

I would add my voice to those who argue that the User Products distinction in section 6 should be removed if it is at all possible to find alternative means of enabling those B2B business models the FSF is concerned about breaking. As the discussion document points out, there are several potential problems with its interpretation, and to me it smells like a fudge.

4. Apache License 2.0 Compatibility

I urge the FSF to continue to do their utmost to achieve compatibility with the Apache License version 2.0.

Authorial

1. Non-software works

It is great that changes have been made to make sure the GPL is applicable to non-software works. However, further work is required to generalise the language, particularly in the preamble (show). Editing such famous and evocative text feels like handling the crown jewels, but here is my attempt at para 2:

Some licenses for software and other works are designed to take away your freedom to share and change them. By contrast, the GNU General Public License is intended to guarantee that you and all other users have and keep those freedoms. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work whose authors commit to using it. You can apply it to your works too.

2. Preamble simplification

Preamble para 4 (show) could be greatly simplified, and the double negatives removed, by saying:

To protect these rights you in turn have certain responsibilities if you distribute or modify copies of the software.

You could then put it on the end of para 3. (This suggestion from 'augustz' on gplv3.fsf.org).

3. Consistency of location of definitions

In general, definitions used throughout are in section 0, and definitions used only in one particular section are in that section. However, this is not true of "essential patent claims", which is defined in section 0 but used only in section 11. Suggestion: move it to the top of section 11.

4. Definitions of Standard Interface, Major Component and System Libraries

The intermingled definitions of Standard Interface, Major Component and System Libraries are confusing, perhaps partly because Major Component is (needlessly) used before it is defined. These two paragraphs need expert attention from a wordsmith.

5. Inconsistent Section Titles

Sections 4 and 5 both apply to source code, and section 6 to object code. However, the title of 4 does not say so (whereas 5 and 6 do) and the title of 6 does not use the pre-defined term "object code". I suggest the following set of consistent and progressive titles:

• 4] Conveying Verbatim Source Code
• 5] Conveying Modified Source Code
• 6] Conveying Object Code

6. Inconsistent formatting of definition of "Aggregate"

The definition of Aggregate (show) is inconsistent with the other definitions, in that it does not capitalise the word, and does not begin 'An "Aggregate" is...". It also uses the phrase "extensions of the covered work", which is undefined in the rest of the license. What does this mean?

I hope these comments are useful, and look forward to the next draft.

Gerv