Re: Illustrating JVM bindings
> > "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.
On Tue, Jan 25, 2005 at 03:41:28PM -0800, Michael K. Edwards wrote:
> 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.
You think the "bright line" which has yet to be drawn is not far from
the theory articulated in lotus an lexmark? That's... a fairly murky
way of thinking...
> 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.
Right, because people generally pay attention to the license on the
components they'll be building on and don't bother to make an investment
in any area where they're likely to have problems.
In this context, the handling of objective c and gcc is probably relevant.
> 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.
Agreed.
> 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.
You're swimming up the same river when you claim that a binary is a
derivative work of the source.
> 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.
For contexts where the treatment of copyrighted material is an obstruction
to hardware compatability, sure.
> 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.
The FSF apparently has some analogous fear. Last time I checked, they
insisted that they be given copyright on code before they accept it into
their code base.
> 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.
Everone else, with a few million exceptions, sure.
--
Raul
Reply to: