Re: Illustrating JVM bindings
> On Thu, 20 Jan 2005 11:53:37 -0500, Raul Miller <moth@debian.org> wrote:
> [snip]
> > I'd say this differently. The program is not a derivative work of
> > the library if it was written without any of the relevant copyrighted
> > material of that library.
On Thu, Jan 20, 2005 at 04:26:18PM -0800, Michael K. Edwards wrote:
> No, it's not a derivative work if it was written without _copying_ any
> of the relevant copyrighted material _into_ the program source code.
Didn't we just get done discussing that while technical details are
informative they don't tell the entire story?
While there are copyrighted programs which consist of only a single file,
it's fairly typical for a program to be composed of many files.
> It's OK to inspect the library source code, comprehend it, experiment
> with it, work out what undocumented call sequence actually works
> instead of something equally plausible but wrong, and generally to
> write a program that wouldn't work without the library and couldn't
> have been written without reference to its internals. You just can't
> cut-and-paste, or even plagiarize in another language, expressive
> content that could equally well have been written differently without
> losing interoperability.
There are different kinds of cases to consider here.
If you're talking about being in compliance with the copyright on the
library, and you're talking about a case where you don't need copyright
privileges on the library itself, then you are essentially correct --
you're not violating its copyright by writing something that uses it.
However, if you need copyright privileges for that library, that's a
different story. If you need to provide copies of that library to other
people, you still need to comply with its copyright. If you need to
distribute modified copies of the library you need to make sure you're
doing so under the terms of its license.
And, the same thing goes for the code which uses the library -- if you
need to distribute it, or modified forms of it, you still need to comply
with the terms of its license.
For example, if the precedent of lotus v. bourland were relevant in a
context where you were distributing the library as a whole, that would
be tantamount to saying that the library as a whole was not copyrightable
because it was purely functional in nature. While that would be a rather
interesting and perhaps exciting development for computer software
professionals, I don't believe that's a likely ruling in a copyright
infringement case.
> > "A published functional interface" is a easily recongizable and legit
> > way for a program to be written so that the program uses the library
> > even though the program was written without using the library. Here,
> > there's other material under a different copyright (the spec [obviously],
> > but also the library headers and a library implementation).
>
> I think you and I are using "published" differently. You're assuming
> that it's a standalone specification, probably with multiple
> independent implementations, with fairly explicit permission to code
> against it. I just mean "published" in a copyright sense, so that one
> doesn't have to deal with trade secrets, "fair use" reverse
> engineering, and "clean-room" standards. The notion of having to get
> the job done without peeking at the internals just doesn't apply to
> published source code.
I think you're missing or ignoring the issues I'm trying to bring up.
I rather intentionally did not go into the technical details of what
distinguishes "published" and "not published".
> > It's probably worth noting that Borland did this without using any
> > lotus library (or headers, and probably without reference to any formal
> > specification), and they certainly weren't being sued for using any such
> > library inappropriately.
>
> Actually, they were being sued primarily because copying the menu
> interface went along with copying the macro language, and both helped
> users migrate from 1-2-3 to Quattro Pro. So they were being sued for
> reimplementing a functional interface, part of whose function was very
> much like a library API.
I think I understand that.
> > Since the GPL restricts distribution of itself at violation time, this
> > idea of "function isn't copyrightable" isn't going to solve all the
> > problems faced by someone violating the GPL.
>
> I don't understand this sentence. Perhaps you are trying to say that
> for A to study a GPL library to understand how it works, and then
> write non-plagiarized, non-GPL code that uses it correctly, causes A's
> GPL rights to self-destruct, even if it is not true that under
> copyright law the non-GPL code is a derivative work. That's not in
> the GPL that I've read, and if it were -- this is freedom?
That's hypothetical situation is rather narrowly focussed away from
the typical cases I was trying to address. You don't seem to be asking
me about what I meant to say -- instead you seem to be asking me about
philosophy or something. If you have a question about what I meant to
say, could you try again?
Also, I don't think your hypothetical example is all that meaningful.
Unanswered questions:
[1] Is A distributing this program?
[2] How can A rely on the GPLed content being there for this program?
[3] How can A ensure that the GPLed content is the proper version of
the GPLed content?
[4] Why did A bother doing this in the first place?
[5] Why is A not releasing this new code under GPL compatible terms?
The GPL intentionally removes the freedom to collaborators freedoms on
collaborative works. So, yes -- to answer your philosophical question --
there is an observable loss of freedom there, if you specifically look
for it. This sort of boundary issue is a common problem when talking
about ethics, rights, and similar concepts.
--
Raul
Reply to: