Re: Bug#509287: Please give opinion about "Bug#509287: afio: license is non-free"
Hi Koen,
Thanks for taking the time to prepare this. I am happy to hear that you've
made contact with the original author; I for one think this completely
resolves the question raised by the Fedora folks (but then, I didn't think
that was much of an issue originally, either).
I'm going to skip straight down to the discussion of permission to modify,
which I believe is the point of greatest concern for Debian. Responses to
your individual points inline. I don't necessarily find each of the
arguments I'm advancing to be persuasive, but I think they're arguments that
could be made if this ever went to court, so should be examined carefully.
On Mon, Feb 23, 2009 at 09:56:57PM +0100, Koen Holtman wrote:
> Issue 3. License does not permit modification
> =============================================
> So we have to ask ourselves: did the copyright holders of afio in fact
> grant the right to modify their work to others? I believe they did,
> so afio does satisfy DFSG#3. I have 2 arguments why they did.
> 1) Argument by the contents of the license notices
> If we look at the 4 license notices, we see that
> - notice 1 contains the statement
> It may be distributed within the following restrictions:
> [...] (2) This credit and notice must remain intact.
> - notice 2 contains the statement
> Permission to copy and/or distribute granted under the
> following conditions:
> 1). This notice must remain intact. [...]
> - notice 3 is the LGPL, which explicitly allows modification
> - notice 4 refers to the conditions of notice 1.
> So in fact notice 1, 2, and 4 all contain the clause 'this notice must
> remain intact'. Such a clause can be read to imply that 'it is not a
> condition that the parts of this work outside of this notice remain
> intact'. By explicitly forbidding the modification of the notice,
> they license owners are implicitly allowing the modification of other
> parts of the work. Had they wished to forbid such modifications of
> the rest of the work, they would have written different license
> notices.
Counterargument:
The license notice is not an integral part of the work, which is a piece
of computer software. Removing the license notice therefore does not
constitute a modification of the work under a typical interpretation of
copyright law, so any requirement that the notice be retained must be made
explicit even if there is no other intent to grant a license to modify the
work.
> 2) Argument by implied licensing
<snip>
> A. Mark Brukhartz, an employee of the license holder at the time,
> posted the afio source code, including an explicit license
> statement, to comp.sources.unix in 1987. Link:
> http://groups.google.com/group/comp.sources.unix/browse_thread/thread/ce3312137ad92a37/ec49f37f3e59a267?lnk=gst&q=afio#ec49f37f3e59a267
> B. The explicit license text was silent on limiting the right to
> modify the code. To show that there was an implicit license of to
> modify the code, we have to show that modification was one of the
> uses that the license holder could have expected after posting the
> code to comp.sources.unix.
> C. The comp.sources community was an early FOSS community, and people
> extending other people's code was one of the things that could be
> expected in that community. Indeed the creation of such extensions
> happened almost immediately in the case of afio -- see D. and
> E. below.
> D. The above newsgroup archive link shows that after Mark submitted
> the sources of afio to the newsgroup, Rich Salz, the moderator of
> the newsgroup, added a Makefile to the sources before forwarding
> them to the group, thereby in fact distributing a modified version
> of afio. It was common practice for Rich Salz to add a Makefile
> when submitted sources did not have them; the license holder would
> probably have known this -- and took no steps to forbid it.
Counterargument:
Adding a Makefile (i.e., a build script) to the work is not a modification
of the work; like a license notice, a build script accompanies the work
but is not a part of it, so its addition does not constitute the creation
of a derivative work.
(ObCDDL: build scripts distributed with GPL works are a different question
because the GPL itself makes it a condition of the license that the build
scripts be distributed under the same terms as the work.)
> E. Mark did not explicitly object when modifications to afio were
> posted. For example, three days after the afio post to
> comp.sources.unix, Karl Denniger posted an improvement for afio to
> comp.sources.d (an unmoderated companion newsgroup to
> comp.sources.unix), with the description:
> These are context diffs to the 'afio' program, a cpio
> replacement, that was posted recently. The changes here take
> care of what I saw as a possible 1gaffe in the '-y' and '-Y'
> options.
> Link: http://groups.google.com/group/comp.sources.d/browse_thread/thread/381df257b583954e
Counterargument:
Although Mark was responsible for drafting the license and, we presume,
had approval from the copyright holder (his employer) for this, we cannot
infer that the copyright holder had any expectation that the work would be
modified once released on USENET. Mark may have had this expectation as a
developer familiar with the conventions of this USENET community, whereas
the copyright holder may not have - and Mark may not have had a fiduciary
responsibility to police modifications made to the work after release to
the newsgroup. Consequently, demonstrating that Mark knew modifications
would happen once posted to the community may not be sufficient for an
estoppel defense. (If Mark can attest that his employer did know of the
consequences of his posting the work to the newsgroup, I think that would
negate this counterargument.)
> F. The license holder knew that it was common practice to modify code
> posted to comp.sources.unix. To illustrate that Lachman Associates
> would have been well aware of the practice of extending software
> tools in the context of the comp.sources newsgroups: in 1989, two
> Lachman employees greatly extended a terminal emulator program
> written by someone else in 1986, and posted their extended version
> to comp.sources.atari.st, see:
> http://groups.google.com/group/comp.sources.atari.st/msg/95d006760c056af1
Combined with the previous point, this is strong, but not conclusive,
evidence that the copyright holder approved of modifications to their work.
> It is very common for trained lawyers to apply this worst-case-rule,
> to go by the worst possible interpretation of an ambiguous legal text.
> In fact, in a multidisciplinary business team, one of the key skills
> that a lawyer is expected to bring to the table is the skill to find
> the legal ambiguities and worst-cases.
debian-legal trains non-lawyers to do the same thing. :) But that doesn't
imply that the Debian project as a whole will feel itself bound by such
worst-case scenarios.
> However, I would argue that applying this worst-case-rule to afio, a
> historical product of the FOSS community for which the license text
> cannot be changed anymore, is like throwing out the baby with the
> bathwater. There is no need to treat afio as if it might be a
> carefully constructed Trojan horse.
Indeed, it's clearly not a Trojan horse, and if the holder of the original
copyright did flip out and decide to sue, Debian and anyone receiving the
code from Debian would be pretty far down on the list of defendants. We
should nevertheless recognize that this is a possibility, and make an
informed decision about whether to accept that risk.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: