On 4/22/05, Marco d'Itri <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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
