need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
noted by on 2007-06-19 at 15:04 EDT:
There is a potential loophole here: "regenerate automatically" can be quite hard in some cases. This paragraph should probably include "and easily" and maybe even "using general-purpose tools or generally available free programs" (as in the previous paragraph). The word "easily" may be a bit vague, but hopefully good enough.
One example of automatic regeneration of souce code that would not be "easy" is if one source file contains a number that can be used to generate another source file by factoring a very large integer. It can certainly be "generated automatically" but not "easily" as it could take several years to generate the missing file. The distributor could even include the tools for factoring that number as a sign of "good faith"... while still knowing that nobody could use that tool in a reasonable amount of time.
Another example is that the tools for automatically regenerating one of the missing source files could depend on external resources that may not be available to the recipient. For example, one of the build tools could be some software that depends on a specific (and expensive) piece of hardware or that needs to fetch some data over the network. This dependency on external resources could be avoided by being a bit more strict in the wording of "...from other parts of the Corresponding Source."
This sentence remained unchanged since draft 1 of the GPLv3, although several users expressed their concerns about possible loopholes:
- Comment #517 by stone on draft 1: http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-1&id=517
- Comment #2014 by sanjoy on draft 2: http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-1&id=2014
- Comment #2652 by AlanCox on draft 3: http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-3&id=2652
One of the replies added a year ago to the comment on draft 1 suggested that it could be used to bypass the DRM avoidance (anti-Tivoization). I think that this loophole can indeed by exploited as I described above. But maybe it becomes clearer if I explain the scenario step by step:
- Company A sells a User Product that contains significant portions of code covered by the GPLv3.
- The product includes a piece of hardware or software that checks if the code running on it is allowed to run or not. For example, it can use a kind challenge-response mechanism that requires the code to perform some operations using a secret key in order to pass the challenge (that key may be unique to each device).
- Company A provides the Installation Information and the Corresponding Source for its product. However, as allowed by this sentence in section 1, company A does not provide one file that can be automatically regenerated. Instead, they provide the tools to regenerate that missing file, as well as the complete, very detailled and user-friendly instructions explaining how to build and install the whole thing. The source code (together with the generated file) is of course "the prefered form of the work for making modifications to it" in order to be in full compliance with the GPLv3.
- Problem: the tool that re-generates the missing file requires factoring the product of two large prime numbers (or solving some other hard problem). So the file can be regenerated automatically, but it will probably take several hundred years. Yet, strictly speaking, it can be regenerated automatically.
Company A has not violated the GPLv3. But nobody can run modified code on their devices.
Solution: add "automatically and easily" or "automatically and conveniently" in that clause of the GPLv3. Or think about a better wording that also forbids external dependencies, etc.