On Tue, 25 Jan 2005 17:19:43 -0500, Raul Miller <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 25, 2005 at 01:41:02PM -0800, Michael K. Edwards wrote:
> > I'm focusing on a simple case. Pre-existing GPL library, shipped
> > unaltered, or with any bug fixes and enhancements contributed
> > upstream. New application ("PEOTL") written to use the library.
> > Tested and shipped together, with no tricksy business to pretend that
> > the application isn't dependent in an engineering sense on the
> > library. Intent: to exploit the market for the application, and to
> > save on engineering cost by not reinventing the wheel contained in the
> > library.
>
> "Written to use the library", in the simple case, with no trickery
> involved, means that you are incorporating a modified form of some of
> the copyrighted code of that library. In the typical case, this would
> be anything covered by copyright that has to be included when compiling
> the combined work.
The scope of copyright in external interfaces is the crux of the legal
debate. I don't mean to claim that the "bright line" has yet been
firmly drawn, identifying published interface definitions as
intrinsically uncopyrightable portions of software works. I do think
that's pretty close to industry practice, and not far from the theory
articulated in Lotus and Lexmark.
There doesn't seem to be much case law in which a court has been asked
to apply sanctions against "unauthorized use of a published API" under
a copyright theory. The various cases I have cited are mostly
competitive situations (creation of interoperable substitutes), and
older precedents on interface usage from the telecom industry usually
hinge on contract terms and trade secret status rather than on
copyrightability.
Personally, I think that the FSF is swimming upriver when it claims
that any of the steps involved in implementing and linking against a
library creates a derivative work. As far as I can see, this attitude
goes against the legal trend in the US and in any other jurisdiction
which looks to the US judiciary for reasoned analysis of the public
policy issues. Moreover, together with the FSF's bizarre insistence
on a "non-contract license" interpretation of the legal basis for the
GPL, it discourages established software players from publishing
mature software components under the GPL, since they fear that
allowing a patch from a competitor to leak into the GPL component will
provide a lever with which to open up their entire code base or to
obtain crippling injunctions under the generous copyright standard.
Arguably, the barriers to adoption of GPL components in commercial
software projects are in the interest of programmers of limited skill
and experience, since the usual alternative is in-house Greenspunning,
which seems to be most of what novice programmers are employed to do.
They might also be in the interest of the egos of the maintainers of
some GPL components which would be overdue for a rewrite if
mission-critical projects depended on them. Everyone else loses out.
Cheers,
- Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
