Re: Defining 'preferred form for making modifications'
(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
Reply to: