Re: RES: What makes software copyrightable anyway?
On 5/24/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> True. Replace that non-sentence with:
>
> By "license", I mean the usage of the word in a copyright law context
> -- i. e. "(non-)exclusive copyright license", a term in a contract --
> and not any statutory or judicially created defense such as "fair use"
> or "doctrine of merger", for which judges almost never use the word
> "license".
>
> OK?
Sure.
> > To my knowledge all (or perhaps almost all -- I'm not enough of an
> > expert to say which) U.S. case law involving copyright claims have
> > dealt with contractual issues.
>
> Not at all. Take Lexmark v. Static Control, for instance; there was
> not, nor was there ever contemplated, a contract between the parties.
> Copyright infringement is a statutory tort and contract law enters in
> only if the defendant claims license from the copyright holder. And I
> repeat that "fair use" and other statutory and judicially created
> defenses are not "license" and are not assessed using contract law.
Ok.
> > I was not referring to distribution of cloned software but distribution
> > of the original software. If Connectix was distributing Sony software,
> > that issue (along with any associated contracts) would have been
> > very significant to the case.
>
> Not really. Not unless Connectix signed some sort of distributor
> agreement pledging not to do what it did, or obtained access to trade
> secrets that it used to build its emulator; and those would be
> separate causes of action under state law. The factual status of
> "copying" does not changed based on any contractual relationship
> between the parties, only the assessment of whether it constitutes
> infringement -- and the only defense affected is a claim of license,
> not any of the statutory or judicially created defenses. IANAL,
> TINLA.
I'll agree that this hypothetical distribution might not have changed
the outcome of the case (though it might -- depending on the details).
But I think both sides would have spent some time addressing this issue
in court, had it been relevant.
> > > > If we draw an analogy between these cases and a dynamic linking
> > > > case, a parallel would be cases where the dynamically linked
> > > > library was not being distributed by the alleged infringer.
> > >
> > > That simply doesn't make a bit of difference to whether a program is a
> > > derivative work of the library to which it's linked -- and all of the
> > > cases cited above are copyright (and/or trademark) infringement cases,
> > > not breach of contract. Now, if the library's license agreement
> > > contained a prohibition on distributing the two things together, then
> > > the court might have to consider whether that prohibition is a
> > > legitimate term for a contract to contain. But in the case of the
> > > GPL, I do not believe (IANAL) that it contains such a prohibition when
> > > construed according to the applicable principles of common law
> > > (irrespective of the details of the given jurisdiction's
> > > implementation of contract law). Participants from civil law
> > > countries appear to reach similar conclusions.
> >
> > The GPL certainly allows distribution when the source code for
> > the program as a whole is available under an appropriate license.
> > One of the things we're discussing in the context of Quagga is whether
> > the source code for the program as a whole is available under
> > an appropriate license. [We're also trying to nail down the
> > "why or why not" issues.]
>
> I think you missed the thrust of my comment. However you interpret
> "work based on the Program", the question of whether or not the same
> person distributes both W and P has no bearing on whether W and/or W+P
> are works based on P. It has bearing on whether the "normally
> distributed with the operating system" exemption applies; but that's
> part of the clause defining (as I see it) return consideration, and
> certainly has nothing to do with the definition in Section 0.
That's an extremely limited meaning for "doesn't make a bit of
difference" -- it only counts for a specific flavor of bit.
> > > [snip citations anchored in Feist]
> > >
> > > You do understand that Transwestern v. Multimedia, BellSouth v.
> > > Donnelley, and Feist v. Rural Telephone are discussing the "thin"
> > > copyright on "compilations" of facts (such as telephone directories)?
> > > Copyright on a "collective work" (a compilation whose components are
> > > themselves copyrightable works) is in some ways stronger, but it still
> > > has to meet a non-zero threshold of "creative expression in selection
> > > and arrangement", and the act of combining the compiled binaries of
> > > Quagga, libsnmp5, and libssl doesn't cut it. The modifications to
> > > Quagga to support publishing routing tables via Net-SNMP certainly do;
> > > but those are part of the creative expression in the source code of
> > > Quagga, and do not add weight to the "selection and arrangement".
> > > They also don't make Quagga a derivative work of Net-SNMP or OpenSSL.
> >
> > I'm thinking here that you've not understood my stance on this
> > issue -- you're certainly not addressing it.
> >
> > My stance is that Quagga was written to include these other
> > components. Once that's been done, there's certainly no originality
> > in selecting these components again.
>
> No, it was written to _use_ those other components through their
> published APIs.
That would mean that it contains collective work elements.
> I do agree with your second sentence, though; which is why
> Quagga+libsnmp5+libssl is not a "collective work", it's an
> collection that is not copyrightable as a whole.
That doesn't follow.
> Any claim that Quagga is a "derivative work" of libsnmp5 or libssl
> has to rest on the Quagga source code alone.
That's a part of what Saris might have called "a matter of fair dispute".
> > Likewise, the authors have no one to blame but themselves if
> > libssl does not have a compatible license. They're in no position
> > to take action against anyone else for infringement when they
> > use libssl.
> >
> > However, if Quagga incorporates significant GPLed code from other
> > authors -- people who were not a party to this choice -- that
> > would be a problem.
>
> Only if the OpenSSL source code is part of the source code of a "work
> based on the Program" under the Section 0 definition. (Which it's
> not.)
That's an assertion. I don't see why I should agree with it.
> > [dynamic vs. static linking]
> >
> > > My argument was going somewhere completely different. The GPL is a
> > > true offer of bilateral contract because the licensor receives
> > > valuable return consideration from the licensee: enhanced reputation
> > > and access to the licensee's code enhancements. Squirreling away a
> > > GPL library (or the Linux kernel or any other kind of program) inside
> > > a box marked "No User-Serviceable Parts Inside", and being silent
> > > about (or worse, obfuscating) its presence, may be "malicious
> > > compliance" even if the letter of the GPL obligations are met.
> > >
> > > "Malicious compliance" that uses loopholes in the contract language to
> > > deprive the other party of substantially all benefit of the exchange
> > > is often (IANAL) grounds for contract termination. Once a licensor
> > > swallows the bitter pill of the inescapable bilateral-contract-ness of
> > > the GPL, its medicine starts to go to work, and she may find it much
> > > easier to obtain redress for genuine abuses. She probably does,
> > > however, have to give up the pretense that the GPL encumbers
> > > independently developed works that link against GPL works; a court
> > > would probably see that as an attempt to deprive the licensee of
> > > substantially all benefit of the exchange.
> >
> > I'm not sure I agree with this logic. People who use the
> > unilateral permissions (verbatim copying, with no restrictions)
> > are going to be the primary sources of reputation.
>
> Not really. The primary sources of reputation are going to be the
> people who look at the code. Eric A. Young's global reputation as a
> programmer presumably rests mostly on the quality of the OpenSSL code
> and the extent to which other programmers have made use of it, and
> Linus Torvalds's reputation as a programmer and a manager of a highly
> distributed project rests mostly on the quality and widespread
> adoption of the Linux kernel. Reputation as a public figure is a
> different story and has little to do with the exchange of value found
> in the GPL.
You're overgeneralizing, when say that your opinions here on value
turn the GPL's grant for verbatim copying into a bilateral contract.
> > Also, the GPL does not require that the copyright holder ever
> > gain access to the code enhancements -- the GPL only requires
> > that the community at large (whoever receives the code
> > enhancements) also has access to the sources.
>
> It doesn't technically require that, of course; the GPL can be used,
> and is frequently used, for privately distributed materials that no
> participant ever feels like putting up for public download. But the
> Planetary Motion court recognized the return contribution of patches
> (and even bug reports) as part of the value received which made GPL
> release of CoolMail "use in commerce"; and that's obviously a big part
> of what people get out of GPLing their work.
And how significant this factor is can be an issue of fact, for
a specific case.
> > > > I'm less convinced for cases where the dynamic linked library is
> > > > being routinely distributed (for example, in the context of Debian).
> > > >
> > > > Let me put it this way: if someone (A) has distributed their
> > > > work under the GPL, they can reasonablly expect to take
> > > > the entire source code for a program someone else (B) has
> > > > written which incorporates their work (A) and make further
> > > > significant creative changes to that work and release it.
> > >
> > > It depends how it is "incorporated". As I read it under US law
> > > (IANAL), the text of the GPL does strike that bargain with respect to
> > > "derivative works", but not with respect to works that use the GPL
> > > work through its published interface. The sources of law that I and
> > > others have cited (even, as I read them, the cases you've cited)
> > > appear to agree that copyright cannot be used to claim rights on a
> > > program that merely uses yours.
> >
> > I think you're focusing on an important distinction, but I
> > think its exact boundaries are a bit more fluid than you
> > represent here.
>
> Uncertainty again?
If someone takes you to court, it's usually wise to think that
they might have something of a point. Even if they're clearly
wrong-headed idiots.
It's also usually wise to realize that the judge might understand
their point(s) better than you. Dealing with these points
often requires understanding them, and addressing them.
It's not automatic.
> > > > If some other party (C) can charge (A) for doing something
> > > > outside the law (perhaps breach of contract or copyright
> > > > infringement) after having done so, then someone messed up.
> > > > Probably that someone was B.
> > > >
> > > > This same principle should hold if some independent party
> > > > (D) puts in this kind of creative effort against that same
> > > > original work, and where (D) releases the new creative
> > > > content under the GPL.
> > >
> > > I am not succeeding in following any of this. Who is alleging what
> > > against whom?
> >
> > Two cases:
> >
> > 1) C alleges A violated C's copyright for treating C's product
> > (libssl, perhaps) as if it were available under terms
> > compatible with the GPL.
>
> In what way is this a violation of anyone's copyright? Did A (the
> Quagga authors) create a derivative work of libssl without
> authorization from C (the OpenSSL authors)? I think not. Nor do I
> think they have done anything to suggest that OpenSSL is offered under
> the GPL -- which would in any case be some kind of tort of
> misappropriation, or maybe a false claim of agency, rather than breach
> of contract. (IANAL, TINLA.)
Now try replacing the '(libssl, perhaps)' with some arbitrary
piece of software under some arbitrary license.
> > 2) C alleges D violated C's copyright (same basic model, just
> > a different party charged with the violation).
>
> If A incited D to do so -- say, by distributing the source code for
> both A and C's work without clearly delimiting the boundary, and added
> a top-level README saying "this whole thing would be much better if it
> were refactored, but I'm too lazy to do it" -- then C might be able to
> claim contributory infringement against A. Otherwise, none of this is
> A's problem.
I wish to consider the case where B incited D by violating A's copyright.
More specifically, I'm trying to draw a parallel between these two
cases (A violates and D violates), to indicate something about where
the lines are drawn.
> > > Nothing about the GPL grants protection from competition. It places
> > > return conditions on the distribution of derivative works that the BSD
> > > license doesn't. Trying to leverage the copyright monopoly for
> > > anti-competitive purposes puts you right in the boat with Lexmark.
> > > And that's frankly the suspicion I harbor about the FSF's behavior
> > > surrounding GCC, and if Mr. Wallace doesn't succeed in busting them
> > > for it, I wouldn't be surprised if someone else does.
> >
> > Let's focus on unfair competition in the context of release of
> > source code in human readable form.
>
> Why? Are you not interested in the question of whether it might
> constitute unfair competition to, say, claim that GPL programs can't
> legally link against OpenSSL, write a mostly API-compatible
> replacement (GNU TLS), pressure non-FSF GPL projects to adopt it, and
> thereby shove OpenSSL and its authors to the fringe of the open source
> world?
Why do I have to be uninterested in "random topic FOO" to be able
to focus on this issue?
> > Also, I do not share your truculence against the FSF.
>
> Evidently. :-) But "truculence" is not the word I would use. It
> bothers me that the FSF makes claims that strike me as patently false
> about how copyright law and copyright licenses work. Like a good
> investigator, I ask, cui bono?
I also do not think that those claims are patently false. So
far, it looks like this assessment (that these claims are
patently false) require some rather significant assumptions.
> I look around and I see GCC and GDB as
> the core of various commercial development environments, such as Wind
> River's Tornado and Apple's XCode, apparently developed with the
> active engagement of the FSF while prominent spokespeople for Wind
> River and Apple fulminate against the GPL. Hmm, where's the pressure
> on them to open up their IDEs?
And your own fulmination against the FSF helps, how?
> I see the OSDL -- funded principally by IBM, HP, CA, Intel, and NEC --
> handing Eben Moglen four million dollars to create a "Software Freedom
> Law Center" apparently dedicated to meeting the legal challenges
> facing the FSF, Samba, and other clients of Moglen's (see
> http://trends.newsforge.com/article.pl?sid=05/02/11/2216239&tid=147 ).
> I see Moglen bragging that he succeeds in strong-arming code out of
> "GPL violators" who are afraid to face him in court. And I say, this
> is not the rule of law. This smells like a protection racket, no
> matter how "bad" the guys on the other side are. I don't have the
> facts or the background in law to say whether it's actionable; but I
> think it's nasty.
Eh... but this is the industry standard practice. RIAA, Microsoft,
AT&T, etc. etc. are engaged in this far more heavily. If you want
to fix this in some fair fashion -- some way that works evenly across
the board -- more power to you.
Meanwhile, Eben Moglen hasn't been posting to debian-legal, nor
have any other industry movers, so the best you can do on this
issue here is rip apart straw men.
> > > Depends whether you care more about dynamic linking overhead or memory
> > > savings from libraries shared between processes running different
> > > programs. I know enough about compiler and linker design to say that,
> > > in almost any case where static linking is a significant performance
> > > win (as opposed to a workaround for moving-target-API problems, as in
> > > libbfd), judicious inlining is a bigger win. Of course you only want
> > > to inline things that you're pretty sure are bug-free, if you care
> > > about swapping the rest of the library without a recompile.
> >
> > Don't underestimate the moving-target issue. For example, there
> > can also be security issues (for example) with dynamic linking.
> > With static linking, you can nail down more specifics about the
> > behavior of a program than you can with dynamic linking.
>
> You're seriously telling me that somebody who can monkey with
> LD_PRELOAD can't do anything he pleases to the user account under
> which that process runs? This strikes me as a pretty far-fetched
> justification for static linking.
That's not the risk model.
The risk model has to do with introducing changes into secure
and heavily tested code through the update of independent
components.
Think about the general case of multiple administrators in
multiple organizations managing a bunch of systems and deploying
code for them which you can promise is secure.
> > It's not just embedded systems where efficiency is important.
> >
> > For example, programs which are intended to be used by shell
> > scripts have their startup costs multiplied by the number of
> > times the program is invoked in a unit of time. Current
> > design practices favor dynamic linked libraries for libc
> > and so on, but this needn't always be the case.
>
> Hence shell built-ins, busybox, and Darwin-style prelinking. But my
> basic point still holds: when static linking (or any other technical
> measure) can reasonably be interpreted as part of a scheme to
> obfuscate the presence of GPL components inside a system and to
> unreasonably obstruct the "freedom to modify" that the GPL tries to
> ensure, it strengthens a GPL licensor's claim for breach of contract
> through malicious compliance.
Ok, I have no problem with what you've stated here is your basic
point.
> > > I think you're abusing the phrase "scope of license" here. I repeat,
> > > please show me any indication that the judge didn't mean "GPL" when
> > > she said "GPL".
> >
> > I'm not saying the didn't mean "GPL". I'm saying she didn't mean
> > "The GPL as a contractual agreement, considered in isolation"
> > when she said "GPL".
>
> I'm not that interested in arguing this point any more. Maybe I'll
> have more to say if and when I get hold of the full docket. It seems
> quite obvious to me that Judge Saris read the GPL substantially as I
> have interpreted it, except for some uncertainty as to whether the
> case law in her jurisdiction implied that Gemini was a derivative work
> of MySQL's copyright material. For all I know, MySQL may have brought
> forth evidence that Gemini contained fragments copied from other MySQL
> table type implementations. But I'm done responding to a line of
> argument that says that she was talking about some license terms other
> than the GPL, in a stretch of text that begins with "With respect to
> the General Public License ("GPL"), ..." and ends with "... regarding
> the use of the MySQL program under the GPL."
> > > > That said, I entirely agree that there could be additional factors --
> > > > including factors specific to that case -- which also apply to the
> > > > relevance of the GPL in that case. For example, the concept
> > > > that Progress could have been estopped from filing infringement
> > > > charges against someone releasing new and creative GPLed code
> > > > which incorporated some Gemini code.
> > >
> > > This strikes me as far-fetched. Is there any part of the record that
> > > supports this speculation?
> >
> > Her comments about how MySQL had not demonstrated irreparable
> > harm.
> >
> > I agree that I am speculating here, about what reasons she had
> > for stating that they had not demonstrated irreparable harm.
> > However, I do think it's plausible to view the statements by
> > Progress in that case as estoppel against harm to MySQL.
>
> That's not what "estoppel" means. MySQL simply didn't demonstrate
> that it would suffer any irreparable harm between the preliminary
> injunction hearing and the full trial. The concessions by NuSphere
> did contribute to that conclusion. But it's important to note that,
> had this been a copyright infringement action, MySQL would have been
> entitled to an automatic presumption of irreparable harm, the burden
> of proof would have been on Progress to rebut that presumption, and
> the record would reflect that pattern of reasoning. Judge Saris did
> not take the "copyright-based license" argument seriously, nor, in my
> opinion, would any judge.
I thought you said, a few paragraphs above, that you weren't
interested in arguing this point any more.
Put differently: the contract in this case was not the GPL alone,
which entirely accounts for this lack of infringement due to
contract breach.
> > > You seem to be promoting the idea that there is some uncertainty about
> > > whether Judge Saris construed the terms of the GPL under contract law
> > > in the course of deciding whether or not MySQL's claim was likely to
> > > succeed on the merits. I do not believe that there is any such
> > > uncertainty. *** Does anyone else believe that Judge Saris didn't
> > > construe the GPL to reach the conclusions cited from her opinion? ***
> >
> > You asked if there were any indication that the paragraphs did not
> > speak exclusively of the GPL. I'm saying that the judge appears
> > to have been relying on Progress to keep their promise and to fully
> > repair the breach.
> >
> > That said, under contract law, the contract in breach must include
> > all agreements between the two parties -- thus the contract in
> > breach could not have been the GPL alone. The GPL the part of the
> > contract which allows the breach to be repaired with the
> > proper release of source code.
>
> The FSF persists in the contention that breach of the GPL cannot be
> repaired except by proclamation from the licensors, and considers it
> essential to the extra-judicial enforcement of GPL terms; Eben
> Moglen's affidavit is quite eloquent on the topic.
Termination of copyright license is the only remedy listed in the
GPL.
I don't think the FSF makes any such claims about cases where other
remedies are listed in other contracts.
> Judge Saris rather pointedly ignored this contention, probably not
> least because it doesn't seem to have been offered by MySQL's counsel.
Nor did I see it in Moglen's affidavit.
I'm guessing that everyone was aware that the GPL was not the only
relevant agreement.
Does it really have to be stated explicitly by the court that
"We are not considering this case as if the GPL had been the
only agreement between MySQL and Progress. Please take this
into account when considering what this decision means in
other contexts."
?
> And as for the claim that the circumstances, including the existence
> of a separate covenant regarding trademark license and remarketing
> rights, could fundamentally alter the judge's approach to construing
> the GPL, I reject it based on the text of the opinion as discussed
> ad nauseam.
I don't see any reason to agree with you on this point. Nor do I
agree that the commercial contract should be construed as having
granted no copyright license.
> > > Let me draw the parallels for you. Nintendo sought to monopolize the
> > > supply of game cartridges (sold at high margin) compatible with their
> > > consoles (sold at low or negative margin). Lexmark sought to
> > > monopolize the supply of toner cartridges (sold at high margin)
> > > compatible with their printers (sold at low or negative margin). It
> > > is imaginable that some GPL licensors may seek to monopolize the
> > > supply of end-user applications and feature add-ons compatible with
> > > their (GPL) core components -- either for financial or ideological
> > > benefit. Call me a cynic, but I've been around this industry for a
> > > while and in my uninformed and non-lawyer opinion I've seen patterns
> > > of behavior that quack very much like that duck.
> >
> > You're using prejudicial language here. I'm inclined to ignore
> > that aspect of the argument -- I'll just focus on one issue:
> >
> > This does not reflect any current state of affairs I'm aware of.
> >
> > In any event, when someone has a monopoly, they have to follow
> > special rules. Those rules do not apply to people who do not
> > hold monopolies.
>
> That's a different use of "monopoly", relevant to antitrust claims.
> "Monopoly" is a perfectly good word to describe the Nintendo and
> Lexmark states of affairs, in which a vendor claims sole authority to
> authorize the creation of compatible accessory products, and is used
> several times in the latter decision. For instance, in Judge
> Feikens's partial concurrence in that opinion: "We agree that the
> Digital Millennium Copyright Act (DMCA) was not intended by Congress
> to be used to create a monopoly in the secondary markets for parts or
> components of products that consumers have already purchased."
I don't think this applies here, either. Certainly the GPL allows
anyone to create compatible accessories. The requirements for
source code release do not create anything approaching this kind
of problem.
[snipping repeats of this issue...]
> > > That leaves the GPL. The FSF's quasi-legal strategy with respect to
> > > the GPL remains partially untested. Progress Software v. MySQL
> > > demonstrated, as I see it (IANAL), that the "copyright-based license"
> > > contention holds no water; but it didn't go into the FSF's business
> > > practices at all.
> >
> > I think you're ignoring what Saris wrote if you believe that.
> >
> > As I understand it, Progress did release Gemini under GPL
> > compatible terms. Not all at once, but Saris indicated
> > that a part of the compliance would be future.
> >
> > Additionally, the contract in breach was never the GPL alone,
> > so it's improper to construe that the reasoning expressed in
> > that case represents a treatment of breach of the GPL.
> >
> > Try it this way: If we have a broken contract between us
> > and I offer you a new contract and you indicate agreement
> > to that contract and promise in court that you will comply
> > with all the terms of that contract, would the court treat
> > you as being in breach of this new contract even though
> > you don't comply with all of its terms immediately? Or
> > would the court instead focus on issues which are outside
> > the new contract but were inside the old contract?
> >
> > As far as I know, Progress is now in compliance with all
> > the terms of their contract with MySQL. To my knowledge,
> > this is exactly what they promised in court.
> >
> > I guess I don't understand what problem you have with this.
>
> With the exception of the implication that the GPL came after the
> interim agreement and supplanted some of its terms, I don't have a
> problem with it. As I understand it, the copyright license on which
> Progress relied all along was the GPL; and Eben Moglen's affidavit
> appears to support that understanding. He states in paragraph 36:
> "The mysqld program as distributed was covered by the GPL."
I don't mean to imply that the GPL came into existence after the
initial contract. I meant to imply that it was another alternative
and that the contract between MySQL and progress was shifting
between the earlier contract and the GPL.
Also, Moglen's statement clearly meant that mysqld was available
under the GPL license. Rather clearly, Progress thought that
the commercial contract they had signed gave them the right to
develop Gemini as a proprietary product.
> Note, however, that this time you have stated the situation entirely
> in terms of breach of contract, and that's why I don't have a problem
> with it. Does this mean we can add this to the "things we agree on
> about the GPL"?
The two bits at the top of this post that I've indicated agreement on
I have no problems with.
Thanks,
--
Raul
Reply to: