The latest draft of the GPLv3 contains many improvements over the previous ones. It also still contains several minor issues, some of which date back to the first draft. Among these, there is a paragraph that remained unchanged since the first draft, although there were several comments saying that it could provide a loophole:
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
The problem is that “automatically” is not defined and it could lead to abuses, including preventing users from running modified versions of GPL software on some devices (the Tivoization problem that GPLv3 tries to prevent). “Automatically” can cover current practices such as generating Makefile from Makefile.in using autoconf, generating parser.c from parser.y using bison, etc.
But “automatically” could also include some operations that are impractical in terms of time or special equipment required. A file that can be regenerated automatically but requires several hundred years of computation on a supercomputer will effectively prevent most people from compiling the software and installing it on their device (if that file is required during installation or during run time). The canonical example would be if the tool that regenerates the missing source file requires the factorization of the product of two very large prime numbers.
As long as the company selling the device provides the complete Corresponding Source (including tools necessary for regenerating the missing files) and Installation Information, then they would be compliant to the GPLv3. As long as the source code (with the missing file) is the “prefered form of the work for making modifications to it”, then they have followed the GPL to the letter… while still preventing users from running modified code on their devices.
Of course I reported this problem and I included links to the previous comments on the same issue. But it looks like this issue has been ignored so far, despite the fact that the comments on the first draft are more than a year old. 🙁
Well, it should be noted that courts tend to take a common-sense approach to such language.
Anyway, the fact that it says “regenerate” implies that it was generated in the first place. So anything computationally infeasible would be out, since the distributor could not have generated the file using that method in the first place.
The product instead of the factors (to use your example) would clearly not be the preferred form for modification. So I don’t think this loophole will work.
The reason why I reported it as a problem is that according to way the text of the license is written, the source code must be “the preferred form of the work for making modifications to it” but it is allowed to remove some files from the source code if they can be regenerated automatically. So this implies that the license allows distribution of a form of the work that it not the preferred form for making modifications to it (because the preferred form includes the files that have been removed).
That would be fine if there was also a requirement to make it easy to regenerate the files because then it would be trivial to go back to the “preferred form of the work for making modifications to it”. But this requirement is missing, so it could be exploited by people or companies who want to prevent others from compiling and using some GPLed code.