Re: [Fwd: Re: Bug#304316: section non-free/doc]
On 4/22/05, Marco d'Itri <md@linux.it> wrote:
> m.k.edwards@gmail.com wrote:
>
> >Legally, I can't modify a glibc API and then paste my revisions into
> >the glibc documentation, because my changes truly are a work derived
> >from GPL material and can't be amalgamated with GFDL material. I
> You are totally missing the point. Even if an API were copyrightable
> (it's not), even if the description of an API were a derived work
> (I doubt this), you as the author of the changes can license them any
> way you want.
At least under US law, it's a little subtler than this. (IMO, IANAL.)
The sense in which APIs are "uncopyrightable" is that they are
ineligible for copyright enforcement insofar as copying them is de
facto necessary in order to make arm's-length use of the functional
object to which they are attached. But the courts that created this
doctrine haven't wanted to authorize outright plagiarism -- and thus
infringement of an author's copyright of an API in its "literary
character" can still be successfully prosecuted.
The Sixth Circuit's ruling in Lexmark v. Static Control (
http://www.eff.org/legal/cases/Lexmark_v_Static_Control/20041026_Ruling.pdf
) does a much better job than I could of describing the history of
"uncopyrightable because inseparable from a method of operation"
arguments. I will just emphasize that editing the insides of a GPL
implementation and editing the literary content of GFDL documentation
are only permitted under the terms of the respective license
contracts. The assumption of "arm's-length" authorship intrinsic to
the "method of operation" test fails, and it becomes very difficult to
claim that one hasn't copied anything either direction.
As regards Matthew Garrett's view that license incompatibility isn't a
freeness issue, I really couldn't disagree more. It's always been a
freeness issue, just one that pragmatic people treated as unavoidable
when it concerned independent works under separately authored
licenses. And Matthew and many others, to their credit, have been
more successful in ameliorating the consequences of license
incompatibility by emphasizing utility rather than freeness.
As I see it, the individuals who assigned their copyright in GNU
documentation to the FSF probably didn't expect to see the relicensing
of their work under a GPL-incompatible license, creating yet another
"gated community" carved out of the ostensible commons. In my
opinion, this is a truly unfortunate regression and, together with
concerns about whether program and documentation are really separate
works, raises the freeness _issue_ to a freeness _problem_. (In
addition to the other problems with the GFDL.)
Cheers,
- Michael
Reply to: