Re: RES: What makes software copyrightable anyway?
On 5/23/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
> On 5/23/05, Raul Miller <moth.debian@gmail.com> wrote:
> > I'll need to think about that some, but I think there are some obvious points
> > you missed. (For example, that contract law can and will be used in
> > resolving ownership issues in copyright cases.)
>
> As long as you modify "copyright cases" to "claims of license under
> copyright", I'm good with that. Contract law is not used to resolve
> any issue other than the validity and scope of a claimed license.
> License as in "non-exclusive copyright license", a term in a contract,
> not any statutory or judicially created defense such as "fair use" or
> "doctrine of merger".
Ok. Except, last sentence no verb.
> > Anyways, I'll see if I can come up with some other points of
> > agreement. (Many of your statements are statement I agree
> > with if they're phrased as possibilities rather than in
> > "always applicable to everything" form -- that is, if they're
> > rephrased to assert existence rather than universality.)
>
> OK. But let's both be careful about mistaking, say, "some copyright
> licenses are terms in contracts" as nearly agreement with "all
> copyright licenses are terms in contracts"; the former (in law, not in
> math) implicitly suggests that some copyright licenses are not terms
> in contracts, which is diametrically opposed to the latter.
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.
Note that I haven't take time to wade back through what we've written
over the last few weeks, looking for points we now agree on. It's a
daunting tsk.
> > > That's certainly true of Lotus v. Borland. However, if you look at
> > > the cases from video game space, you will see lots of other
> > > permutations: game developers using fair means or foul to defeat
> > > console makers' efforts to impose onerous contract terms (Sega v.
> > > Accolade and Atari v. Nintendo), emulator developers leveraging the
> > > availability of games authored for an existing console (Sony v.
> > > Connectix and Sony v. Bleem), and one publisher distributing add-ons
> > > for another's game (Micro Star v. FormGen).
> >
> > One thing these cases share is that the alleged infringers were
> > not distributing the game software which was being infringed on.
>
> I don't believe that makes any difference to the logic in these cases.
> There would be no additional cause of action in, say, Sony v.
> Connectix if Connectix had legitimately purchased Sony games for
> resale and bundled them with its PlayStation emulator. Not as long as
> it did not claim "collective work" copyright on the bundle (compare
> Palladium Music v. EatSleepMusic) or violate trademark law by implying
> that the emulator was a Sony-approved product.
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.
> > 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.]
> [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.
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.
[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.
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.
> > 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.
> > 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.
2) C alleges D violated C's copyright (same basic model, just
a different party charged with the violation).
> > > Note that a court is likely
> > > to decide that releasing a project under any "open source" license has
> > > two primary benefits for the copyright holder: 1) access to
> > > improvements contributed by licensees, and 2) enhanced personal or
> > > corporate reputation. The Planetary Motion v. Techplosion appeals
> > > court used exactly this approach to decide that GPL release was "use
> > > in commerce".
> >
> > Depending on the license, there could be additional benefits. For
> > example, the court might decide that there are different benefits with
> > one license than with another (contrast BSD and GPL here). The GPL
> > grants protection from [perhaps unfair] competition in a way that the
> > BSD license does not -- in a way which is roughly analogous
> > (probably inferior in some ways, for example in terms of trade secret
> > protection, probably superior in other ways, for example in terms of
> > copyright protection) to the protection received by "secret source"
> > release.
>
> 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.
Also, I do not share your truculence against the FSF.
> > > The licensor's odds of reaping these benefits when his or her work is
> > > leveraged by another program are much higher if it is conspicuously an
> > > independent component available for use from still other programs, and
> > > if it's easy to apply a bug fix to all uses of that component in the
> > > system. So unless there is a pretty good technical reason for static
> > > linking, dynamic linking should be the rule, as part of the evidence
> > > that the publisher of the combined work is sincere about securing the
> > > benefits of open source release on the component author's behalf.
> > > Which is ethically and technically the right answer most of the time
> > > anyway.
> >
> > In principle, compilers can generate higher quality code for the
> > "static linking" case. Here, some of the interface overhead costs
> > do not need to be paid. In practice, there's still a lot of room for
> > improvement in this area, and the current industry practices
> > with respect to distribution of binaries tend to favor (but do not
> > always favor) dynamic linking.
>
> 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.
> > Anyways, I don't think you should argue that use of static linking
> > shows anything insincere.
>
> Static linking alone doesn't demonstrate insincerity. Static linking
> without a good reason may, since it's a lot scarier to an end user to
> relink than it is to drop in a replacement shared library.
> Performance-based justifications for static linking tend to come up
> mostly on embedded systems anyway, where it is the vendors' habit to
> obstruct piecemeal upgrades by end users. If you want to change that
> habit, I think you're going to have more success evangelizing "freedom
> to modify (the GPL bits)" without the "we 0wn your applications"
> baggage.
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.
> > > Perhaps you misunderstand. Both parties acknowledged the existence of
> > > two contracts, namely the GPL and the "interim agreement". MySQL
> > > appears to have claimed breach of both contracts. The judge ruled for
> > > MySQL on breach of the "interim agreement", saying that "Progress
> > > violated Paragraph 6 of that agreement by using the MySQL trademark
> > > after the termination and by using an unauthorized combination
> > > trademark". Her comments on that agreement, and those of the
> > > commentator you cited, suggest that it was focused exclusively on
> > > remarketing rights and trademark license.
> >
> > I'm going to try restating my point. The scope of license for the
> > trademark agreement focusses purely on the contract signed between
> > Progress and MySQL. The GPL does not grant trademark rights.
> >
> > The scope of license for the copyright agreement necessarily
> > includes not only that contract but the GPL. The GPL does grant
> > copyright license.
>
> 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".
> > 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.
> > Also, for the two paragraphs we're discussing, you only have to
> > look at the order to see that Saris was not interpreting the GPL
> > at all, but was instead relying on people's affidavits and sworn
> > statements -- about what had happened and about what would happen.
>
> I see no evidence to support this assertion. Are you seriously
> suggesting that she didn't read the GPL in the course of adjudicating
> the GPL claims?
Saris said (about the lack of irreparable harm): "... even if MySQL
has shown a likelihood of success on these points, it has not
demonstrated that it will suffer any irreparable harm during the
pendency of the suit, particularly in light of the sworn statement
that all source code for Gemini has been disclosed and the stipulation,
given by Progress during the hearing, that the end use license for
commercial users will be withdrawn."
In other words, it very much looks like Progress promised, in court,
to release the code under the terms of the GPL. I think that Saris
was relying on this promise when declaring that irreparable harm
seemed unlikely.
> > > The judge then turned to the breach of contract claim with respect to
> > > the GPL, analyzed it as we have discussed, and denied it. There is no
> > > indication of an overlap in the scope of the two agreements or of the
> > > consideration of any copyright license alternate to the GPL. The
> > > paragraphs I quoted speak exclusively of the GPL in determining what
> > > license Progress did and didn't have to modify and make copies of
> > > mysqld. If you think there is a shadow of an indication otherwise in
> > > the opinion, please point out exactly where it is in the text.
> >
> > The judge's choice of which issues are relevant to the preliminary
> > injunction must, I think, be based on the facts of the case.
> >
> > Additionally, Saris indicated that these findings were based on sworn
> > statements and affidavits. That's hardly "speaking exclusively of
> > the GPL". In essence, these findings are relevant to cases which
> > share the same affidavits and sworn statements.
>
> 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.
> > > "Dual licensing" was not at issue in Progress Software v. MySQL. And
> > > as for the benefits of having a single developer community, that's an
> > > argument that any monopolist can make. Outside the sphere of GPL
> > > enthusiasts, I think you will find that most people (and especially
> > > most judges) find an ostensibly altruistic monopolist every bit as
> > > distasteful as a profit-seeking monopolist.
> >
> > How can someone releasing code under the GPL be in any way
> > construed as a monopolist in that area?
> >
> > The GPL demands that if anyone else incorporates the GPLed work
> > that they not remove that work from the development community, but
> > that's hardly a monopoly.
>
> 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.
Let's agree that discussion of monopoly is not relevant to any
current GPL issues.
> 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.
--
Raul
Reply to: