Re: Illustrating JVM bindings
On Thu, 20 Jan 2005 20:55:12 -0500, Raul Miller <moth@debian.org> wrote:
> > 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.
We seem to be talking past one another. Maybe it's just that I'm
implicitly assuming a separation between "library source code" and
"program source code", and saying that the latter is only a derivative
work of the former if it contains copyrightable material, which API
calls are not. I don't think either of us means to get into a
semantic debate about whether the phrase "program source code" ought
to refer to the whole ball of wax. So I'll use "program exclusive of
the library", or PEOTL, instead.
My previous interpretation was that your "written without" phrasing
meant to imply that clean-room practices are necessary for the PEOTL
not to be a derivative work, and that's what I was arguing against.
Clean-room practices, in a project to clone proprietary functionality,
help minimize the risk of being prosecuted for misappropriation of
trade secrets. With published source code, there are no trade secrets
in play. Clean-room practices might also reduce the likelihood that a
similarity genuinely dictated by functional requirements would be
taken by a court as evidence of copying. However, that's usually not
a problem when you're implementing the opposite side of the interface.
> > 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.
Am I correct in reading this as agreement that the PEOTL is not a
derivative work of the library?
> 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.
ACK.
> 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.
Let's assume that I wrote the PEOTL and intend to distribute it under
the following license: "You have the copyright holder's permission to
use, copy, modify, and distributed modified copies of this code, in
source code or binary form, and to relicense the result to others
under terms of your choice, as long as everyone pets a cat." This is
GPL-incompatible in the sense that a derivative work of both GPL and
"pet-a-cat" code is undistributable.
> 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.
That's actually very nearly the substance of the Lexmark ruling, given
the additional fact that an SHA-1 checksum of the program in the
printer cartridge was used by the printer as a "lock-out code" to
reject non-Lexmark cartridges. Lexmark was trying to use the
copyright monopoly to criminalize the creation of interoperable
cartridges; instead, the appeals court ruled that they gave their
entire program a functional aspect and rendered it uncopyrightable.
That's not where I was going, though; I was saying that the PEOTL
doesn't infringe the library's copyright. But the PEOTL+library
combination, like any collection of things containing the library,
does constitute "copying" in the legal sense. If I don't have a
license to copy the library, or if I had one and it was rescinded,
then I'm infringing its copyright. So far so good?
> > > "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 was misinterpreting the thrust of your argument, I think.
> I rather intentionally did not go into the technical details of what
> distinguishes "published" and "not published".
OK.
> > > 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?
OK. I still don't understand the sentence: "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." Specifically, I don't understand "the GPL
restricts distribution of itself at violation time". Could you please
rephrase it?
> Also, I don't think your hypothetical example is all that meaningful.
>
> Unanswered questions:
>
> [1] Is A distributing this program?
Yes.
> [2] How can A rely on the GPLed content being there for this program?
A is distributing the library as well, on the same CD.
> [3] How can A ensure that the GPLed content is the proper version of
> the GPLed content?
A distributes both.
> [4] Why did A bother doing this in the first place?
To write a useful program, for which the library is a useful
component, under a reading of the GPL that permits this usage.
> [5] Why is A not releasing this new code under GPL compatible terms?
Any legitimate purpose for which A didn't think the GPL was the best
choice. To make a buck. To encourage people to pet cats.
Let's take, for a moment, a myopic view of the stipulated facts. The
conditions under which the GPL undertakes to self-destruct, as I read
them, apply to the copying of the original work, the creation and
distribution of derivative works, and possibly also to copyrightable
collections that are not formed by "mere aggregation". The library is
a copy of the original work, but I'm following the GPL prescription
with regard to its source code. The PEOTL is not a derivative work of
the library, and the GPL doesn't apply to it.
The PEOTL+library combination, formed by a routine mechanical means
such as linking, is not a derivative work of the library, nor is it a
copyrightable collection, so the question of whether I've done
something other than "mere aggregation" to create it is moot. A CD
containing the PEOTL, the library, and various other carefully
selected components is a copyrightable collection, but it is certainly
formed by "mere aggregation". So I've done nothing contrary to the
library's GPL, and I can distribute the lot, separately or together.
There's a weak point in the myopic argument. "Mere aggregation" isn't
quite a term of copyright law, and some people are willing to argue
that other activities that have nothing to do with copyright (like
understanding the library well enough to use it properly, or using the
library through its published API, or perhaps noting that the PEOTL
has been thoroughly tested with version N of the library) go beyond
"mere aggregation" and cause rescission of my license to distribute
the library.
Now let's take a broader view, in light of the judgments about public
benefit that are also part of a judge's job. The monopoly right
granted by copyright law is supposed to be for the public benefit. It
encourages the creation, expression, and publication of knowledge and
ideas by penalizing unauthorized copying and plagiarism of published
works, since without constraints on publishers there would be no
incentive to pay authors to create works that the others could copy
for free. (Now that everyone has the means to be a publisher, the
maintenance of those constraints is a fraught issue.)
The "expressive vs. functional" distinction that limits the scope of
copyright, and the recognized, protected "fair uses" of copyrighted
material, exist largely to moderate the effect of the copyright
monopoly on other people's legitimate commercial interests.
Essentially the entire history of software copyright litigation is
about striking the balance between rewarding creativity and hampering
competition in a new kind of subject matter. US courts have permitted
aggressive competitive tactics to replicate various kinds of
functional interfaces in the absence of any license from the copyright
holder, largely in the declared interest of interoperability for the
public's benefit and convenience.
Imagine one of those same courts faced with published source code,
offered at no charge by its authors for others to build on. Imagine a
commercially motivated developer that has proceeded to build on that
code, respecting its terms with regard to derivative works, using the
same development techniques routinely used to manage boundaries
between related but separately maintained code projects. She
appreciates that the published material has been placed in the
commons, and she does her bit to keep the commons well groomed. She
just doesn't want to have to give away her own, arm's length,
interoperable work.
Faced with a license that loudly claims it is founded in copyright
law, which the developer can only be held to have violated if the
court interprets "mere aggregation" in a way that has nothing to do
with copyright law, what do you think that court will do? Where do
you really think the balance of harms lies?
> 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.
I can't quite parse this, but I shall assume you are saying, "The GPL
intentionally removes the freedom to take a derivative work
proprietary, in the interest of strengthening collaborators' freedoms
to create collaborative works in an environment of trust." I agree,
and I think it's well written for the purpose (although I have some
quibbles). But an interpretation of the GPL in which one's mind is
tainted by reading and learning from GPL material is not good for
anyone's freedom.
Reasonable people may differ about whether it would be good to attempt
to extend a "monopoly of the commons" across boundaries which
commercial monopolies are obligated to respect. I am persuaded that,
whether or not it would be good, it isn't in the GPL and wouldn't be
honored by a US court if it were.
Cheers,
- Michael
Reply to: