(I apologize for the fact that this won't thread. Future messages should thread properly.)
I agree that for the purposes of writing guidelines, it is not necessary to be either precise or objective. Therefore my comments below relate to the definition of 'preferred form ...' in the context of license texts. I have decided to reply to many postings in summary form. License texts must be objective, fair and reasonably precisely worded if they are to be enforceable. The question at hand is: In those licenses that dictate that the distributor of a binary must also distribute the source of that binary in "the preferred form for making modifications", what does 'preferred' mean? A reply was made against this question demanding to know why it should be answered: "What problem does this solve?" The answer is that answering the question would at least clear up the confusion evidenced by the variety of different responses to the question in debian-legal. Perhaps answering the question will lead to better wording in future free software licenses. Another reply claimed that the answer is obvious. I don't think so, as evidenced again by the fact that people are disagreeing widely about the answer. A third objection was that the question should not be answered because the license works best if it is vague and subject to interpretation. Answer: Vague terms can be the right ones to use when expressing a vague understanding of a complex situation. However, precise terms are usually better than vague ones in a legal document. If one ever tries to enforce the license, the benefit of doubt is on the side, first, of the richer party (because doubt generates legal costs) and second, of the licensee (because a violation must clearly have occurred before a court will find against the licensee). A fourth objection was that courts will define the term in practice by means of a "reasonable man" test. But this begs the question of what objective basis the reasonable man would use for his reasoning. Surely that is something we should think about here. In any case, people have suggested several different definitions. One definition of 'preferred' that was suggested was, in effect, 'liked most by the licensee'. Such a license would allow the distributor to distribute whatever he liked. Another definition was: 'liked most by the distributee'. Such a license would not be fair to the distributor. Another definition might be: 'liked most by the licenser'. This seems to give authors too much control over the descendents of their work. Another definition was: 'liked most by us'. That isn't acceptable because it depends on whom 'us' refers to. I suggested that the term be defined, roughly, as 'the form of the program available to the distributor containing the most information'. A number of objections were raised against this suggestion, which I will now discuss. Objection #1: The license must not force the licensee to keep around old crufty versions of the source. Answer: Using my definition, it doesn't. The licensee is only required to provide the most informative form at his disposal. Does this mean that he can destroy his source files and then not distribute source? Yes; but that isn't a problem: if the source has really been destroyed, then no license will bring it back; and we don't want to punish people for losing their source files; and we don't want to rule out the distribution of binaries for which the sources have disappeared. Objection #2: This definition would make it harder to produce free software using non-free tools. Answer: If your codebase is in a proprietary format and you work on this using proprietary tools, and you release binary and source in a non-proprietary format, then you are indeed in violation of the license. Good. The GPL contains one important limitation of what can be done with licensed code: No Distribution of Binaries Derived From This Without Providing Source. Why does it have that prohibition? In order to prevent private parties from taking possession of free code through an embrace-and-extend strategy. Your proprietary codebase gives you an advantage over the rest of the free software community: perhaps enough of an advantage that effectively people will be forced to pay you to make changes. Aha! Do you plead that your contract with your tool vendor doesn't allow you to make your codebase available along with the tools for developing in it? Too bad: you can't distribute. The GPL is very clear about this. Objection #3: Source code can be obfuscated without loss of information. Imagine a developer has a source file S and generates from it a release version R by running it through an obfuscator. He releases R, satisfying the requirement, but clearly hasn't released the preferred form! Answer: This is a useful case to consider. The obfuscator could be an encryptor. Clearly, if R is an encrypted form of S then R is not the preferred form unless the key is also provided. How would we state this requirement? Do we require the licensee to provide tools for generating *all* forms of the program in his possession so that we can choose the one we prefer? That seems too burdensome. However, I can't think of a weaker requirement that doesn't allow the licensee off the hook too easily. Enough for now. Thanks for the good feedback. -- Thomas Hood
