Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On Mon, May 09, 2005 at 01:51:53AM -0700, Michael K. Edwards wrote:
> On 5/8/05, Jakob Bohm <jbj@image.dk> wrote:
> > On Fri, May 06, 2005 at 02:00:54AM -0700, Michael K. Edwards wrote:
> [snip]
> > OK, there may be more dissenters than I had previously noticed.
> >
> > I was ticked off by the way your original message to -devel
> > *could* leave people not following -legal with the impression
> > that there was the opposite consensus, which could result in a
> > lot of misguided future activity which could be unlawful if you
> > turn out to be wrong in your conclusions.
>
> Well, I have to admit it didn't occur to me that anyone might think my
> opinion represented an opposite consensus. More widely recognized
> debian-legal personages such as Raul and Andrew seem to think I'm an
> idiot or a troll, and to have no particular compunction about telling
> d-d so. (For the record, I am neither, thank you very much.)
>
<mode="Fake Irish accent, pitiful">
I was thinking of the about 800+ poor souls who never read d-l
because they are too busy being DDs and doing useful work, and
how those poor misguided souls might mistake Mr. Edwards for an
official spokesman for the d-l consensus on what constitutes the
proper way to package software for Debian without attracting
legal trouble.
</mode>
> ...
>
> [snip]
> > One obviously needs to claim material breach if the defendant
> > claims to have a license. I am certainly not claiming that
> > published or unpublished APIs constitute protectable expression
> > (though I am not admitting the opposite either), and I do not
> > see the logic of the GPL FAQ doing so either.
> >
> > More specifically, the theory in the GPL FAQ does not depend on
> > the use or non-use of header files or other API definitions by
> > the linking work. The theory is about the inclusion of parts of
> > the library itself (the GPL-ed implementation code) in the
> > resulting linked binary.
>
> And as such it relies on the premise that a linked binary constitutes
> a "work based on the Program". The GPL FAQ's analysis doesn't appear
> to have anything to do with what makes something a "derivative work
> under copyright law", and as such I consider it completely irrelevant
> to the definition actually present in the text of the GPL.
>
I believe there are multiple ways in which the text of the GPL
can potentially be interpreted in a manner which results in the
same conclusion as the one reached by the GPL FAQ.
In this thread of discussion, Mr. Edwards has presented a
specific interpretation of the GPL text, which 1. Does not
result in that particular conclusion, and 2. renders large parts
of the GPL text redundant and/or without force.
Taking that particular reading as a premise, Mr. Edwards then
makes a number of rather strong statements regarding the honesty
and/or intelligence of any statement or action making different
presumptions regarding the proper interpretation of the GPL
text. It would simplify the discussion if Mr. Edwards would
distinguish between his primary opinions regarding the
interpretation and force of the GPL and various conclusions he
makes on the assumption that his particular position would
eventually prevail.
> [snip]
> > > Again, you're missing my point; of course the copies and/or derivative
> > > works require license. But no additional license is required to
> > > bundle them in ordinary commercial ways as long as they remain
> > > separately identifiable. There's a bit of an untested boundary line
> > > involved in the electronic analogy to anthology vs. box-o-books; but
> > > industry practice (which courts do notice) is to roll installers for
> > > X, Y, and Z onto the same CD-ROM, so you don't need a "mere
> > > aggregation" clause to justify that.
> > >
> > > In fact, computer makers jumble together fragments of software
> > > components licensed from dozens of vendors on a pre-installed system
> > > without anyone caring whether they can veto related or competing
> > > products on the same install. The exceptions are rather notorious
> > > (IE, Java, generally Somebody v. Microsoft), and those cases have
> > > hinged on anti-competition and cross-development license disagreements
> > > rather than "hey, you created an anthology without specific license".
> >
> > The "mere aggregation" clause (if it is not a no-op) explicitly
> > excludes this scenario from being limited by the GPL. One can
> > thus debate the reach and meaning of the rest of the GPL without
> > appealing to the effect of those scenarios on the reasonability
> > or legality of an interpretation.
>
> I'm appealing to them, not as examples of people's conduct under the
> GPL, but as examples of industry practice with regard to the scope of
> copyright on a piece of software. Courts consult industry practice on
> points of fact, and sometimes even when clearing up a point of law on
> which there is no clear precedent.
>
> For instance, one does need explicit permission to reprint an article
> in a bound anthology, over and above permission to copy it as an
> isolated work; but as I understand it one does not need explicit
> permission to punch holes in a stack of reprints and send them to a
> friend in a three-ring binder. I don't know exactly where the
> boundary is in the printing industry, but if it came up in a court of
> fact, that court would consult prevailing industry practice in order
> to find out where the consensus lay, and rule accordingly in the
> absence of other legal factors.
>
I see these and similar issues in 3 related, but different,
contexts:
1. Just in case (local) law does require permission, it is quite
useful for that permission to be explicit. Not through estoppel
or similar, but as a clear and explicit permission capable of
standing on its own in jurisdictions where it is not automatic.
2. By explicitly and specifically not prohibiting activities
which law or industry practice would not allow a license to
prohibit, the license offerer may protect himself from claims
that broader parts of the license should be ruled invalid or
otherwise being weakened by a court enforcing the requirement
that a license cannot prohibit those activities.
3. By explicitly and specifically avoiding demands that could
function as a means of monopoly abuse, an attempt to protect
methods of operation, etc. The license offerer may protect
himself from having the license ruled invalid or severely
weakened based on such grounds.
Returning now to your reference to industry practice, I may have
seen industry practice where statically linked binaries are
considered to be much more tightly bound than completely
unrelated files residing on the same disk. Or maybe I have not,
I'd rather not say.
> > For static linking, it is much more like "a commented edition of
> > a book". For dynamic linking, the relationship is more
> > debatable, but some (not necessarily me) could claim that this
> > is at least as close as very tight bundling with a book of
> > comments to the individual chapters of the first book, but
> > without the (US specific) defense of fair use for criticism.
>
> Nah. A commented edition is a commented edition. Which, I think,
> might make a GPL program plus its GFDL documentation form a single
> derivative work, and thus undistributable except by the FSF --
> especially if one has, say, modified the program and documented the
> change. I say might -- but I personally am disinclined to chance it
> just at the moment, although I reserve the right to change my mind.
> (Hopefully that statement won't estop me from anything. :-P )
>
I was not saying that a statically linked program might be
called a commented edition. I was saying that a statically
linked program might be considered to be just as invasive to the
integrity of the original work as a commented edition is to the
unaltered uncommented text, in the sense that both kinds of
combined string of bits / letters could be seen as repeatedly
interrupting the narrative flow of the original text to state
something else of varying relevance to the point of
interruption.
> The state of a GNU/Linux system at run-time is sort of like like a
> bunch of three-ring binders strewn around the surface of a desk, with
> a bunch of reprints taken off the shelf and stuck in them or left
> around loose. Some binders (statically linked programs) contain
> additional copies of (almost) all of the reprints mentioned in their
> front matter; others (dynamically linked programs) just have
> references to shared copies. The first few chapters contain the theme
> of the binder, which might be in a single language (a binary
> executable) or several (a data file stacked on top of an interpreted
> program stacked on top of the binary that executes it). The CPU is a
> djinn that lives in the magic lamp labeled "Linux kernel" sitting on
> the desk. ;-)
>
> As I see it, there are "work" boundaries everywhere there's a work of
> authorship that makes sense by itself, although you have to understand
> the ideas in many others to read it. In order to make mechanical use
> of them the djinn in the desk has to follow the syntax back and forth
> from work to work. But that's completely irrelevant to any
> copyright-based analysis. Copyright is about concrete forms of
> expression (and to a lesser extent about characters, settings, and
> plot arcs), not about ideas or engineering relationships.
>
An interesting and somewhat entertaining analysis. Actually, I
might (or might not) be inclined to considered the CPU etc. to
be more similar to the mechanisms of a theatrical movie
projector or a home TV or radio receiver.
In this analogue, while the mechanics of those devices is of
limited legal significance to the works they process, their
usual and expected behavior as apparently presumed by the
creator of the works or other collections of bits provided to
them may (or may not) have a profound influence on the legal
status of those works or collections of bits.
An even simpler, but more distant, parallel could (or could not)
be an ordinary printed and hardbound book, both in its final
form and as the unfolded printed sheets of paper where the pages
have been printed in a weird n-up layout which puts the pages in
the "correct" order after folding and binding. While the exotic
mechanics of the bookprinting and bookbinding process is of
limited legal significance, the creators or publishers presumed
expectation that the text will eventually end up in the final
book form and be read in the sequence and manner traditional to
our western culture may or may not be of great importance when a
court considers the legal status of the unfolded prints of a
book whose legality is being disputed.
> [snip]
> > > As I said, there isn't a 100% firm precedent that I can find, but
> > > courts tend to ignore technical quiddities and focus on issues of
> > > preserving the public benefit of encouraging competitive
> > > interoperation on one side vs. the suffering due to possibly unfair
> > > (plagiaristic) means of competition on the other. There's no legal
> > > reason to care whether three shared libraries are shipped on separate
> > > hard disks and combined in memory at run-time (or interconnected via
> > > Clay Pigeon Protocol) vs. statically linked into the same blob o' ELF
> > > bits -- unless there are specific contract terms dictating one or the
> > > other as a condition of license, with violation agreed to be grounds
> > > for termination. That's a really strict standard; see Sun v.
> > > Microsoft for discussion of "condition of license" vs. "contractual
> > > covenant".
> >
> > Interestingly, this is the (sometimes controversial) claim of
> > the GPL FAQ with respect to dynamic linking! Except that the
> > GPL FAQ theory is that the legal insignificance of the technical
> > details implies that dynamic linking should be as restricted as
> > static linking, not that static linking should be as
> > unrestricted as dynamic linking.
>
> Right. There is very little (but not quite no) difference -- that's
> one of the few points of law that the GPL FAQ gets right according to
> my lights. I don't know all of the facts, but I would guess that what
> gave the FSF (or was it Cygnus?) a lever in negotiations with the
> companies that wrote the Objective C and C++ front ends was not how
> things were linked but the fact that the GCC intermediate
> representation wasn't really a boundary between two independent works
> of authorship. Ditto the MySQL table type interface -- at the time
> that NuSphere implemented against it, I don't think there were other
> arm's-length users. Now that there is InnoDB, I doubt that a judge
> would even go as far as Judge Saris's "MySQL seems to have the better
> argument" when reviewing the "derivative work" point of fact.
>
> > [ Note, I have not tried to look up the transcript of that
> > really long and outdrawn case. I don't have a shorthand tool
> > for locating individual US court transcripts based solely on the
> > names on the participants, and I certainly have no easy way of
> > finding the right page within such a transcript based on so
> > loose a reference. ]
>
> Sorry, I have been omitting precise citations to opinions to which I
> referred the last time this debate raged on debian-legal. I meant
> http://caselaw.lp.findlaw.com/data2/circs/9th/9915046.html (note: the
> first Google hit for "sun v. microsoft debian-legal" is an archived
> e-mail in which I cited this case).
>
I may look at that later.
> [snip]
> > I argue no such third scenario. I argue that the paragraph
> > might not disclaim all attempts to reach outside the limits of a
> > "work based on the Program", this hinges on whether "a whole
> > which is a work based on the Program" covers a different scope
> > than "a work based on the Program".
>
> I can't imagine reading the two substantially differently, given the
> use of "which is"; but YMMV.
If a legal document suddenly varies its language compared to the
rest of the document, I tend to think there might be a legal
significant in that.
>
> > > As I read it, this paragraph is there to reassure people that if they
> > > add their special sauce to a GPL program and then pass it along under
> > > the rubric of a single whole, they can still use their special sauce
> > > in their own closed source product. As I understand the history, RMS
> > > was spurred to add this clause (and perhaps to write the GPL itself)
> > > when a closed-source vendor tried to demand exclusive rights to any
> > > special sauce he might add as a condition of source access. Such a
> > > demand would be pretty much at the outer limits of enforceability
> > > anyway.
> >
> > While this clause does provide such reassurance, comparison with
> > other licenses written at approximately the same time (like the
> > commercial licenses for Borlands development tools) indicates to
> > me that this may also be written to ensure that the clause does
> > not try to reach so far as to be thrown out of court wholesale.
> > Kind of like the way in which some warranty disclaimers make
> > explicit that they are not trying to disclaim that which cannot
> > be legally disclaimed.
>
> I don't think that's much help in most jurisdictions without the sort
> of "separability", "to the full extent permitted by law", etc.
> provisions that the GPL willfully omits under the pretense of not
> being an offer of contract. Any lawyers around care to comment?
I have heard of jurisdictions where simply saying "to the
maximum extent permitted by law" etc. does not protect a clause
from being ruled invalid. But this is not what the GPL or its
use does here. The GPL explicitly limits itself from having
specific legal effects even where those legal effects might be
permitted by law. As such a court might or might not rule that
the GPL is not even trying to exceed the applicable limit of the
law and rule much more favorably than if it had tried to demand
those things and then added a "to the extend permitted by law"
or "separability" cop out.
>
> > > With or without this paragraph, there's a line beyond which it's none
> > > of the licensor's business what else is rolled into the same
> > > transaction. In the case of a product distributed under the same
> > > terms to all comers, that line is generally drawn at the outside of
> > > that product's shrink-wrap, even if there are six more layers of
> > > shrink-wrap around products of progressively larger scope. There is
> > > plenty of precedent for sub-components with different license terms
> > > within a tarball, so an upstream's innermost "shrink-wrap" may be as
> > > small as a single file (or smaller if a chunk of text remains an
> > > identifiably separate work of authorship embedded for a valid
> > > engineering reason, such as a firmware blob in a driver maintained
> > > with the vendor's cooperation in the main kernel tree).
> >
> > The question is partially where that line is, partially how far
> > out the GPL is actually trying to reach. Your argument seems to
> > be (at least partially) that if the GPL cannot reach out to the
> > whole universe, it reaches nowhere at all.
>
> That's not my argument at all. I am of the opinion that it reaches to
> the boundary of the enclosing "derivative work under copyright law",
> which is (for any given work under discussion) completely unambiguous.
> There may also be one or more enclosing scopes, each of which is
> itself a work of authorship identifiable separately from its context.
> Each of these is not a derivative work but a collection, either
> copyrightable or uncopyrightable depending on the non-triviality of
> its selection criterion. (Geez, this is starting to sound like I'm
> talking through a mouthful of mush.)
I don't think we live in a world of concentric crystal spheres
guiding the paths of each planet around the Sun, but then I am
not an astronomer either.
>
> > > Look at it this way. There's an MP3 player with a big CompactFlash in
> > > it sold at very low margin, with the expectation of making it up on
> > > their cut of the bundled music download service's revenues. A
> > > retailer sticks it in a baggie with a Torx wrench and an dismantling
> > > instruction sheet, and it sells like hotcakes for the CF salvage
> > > value. The MP3 player vendor might have some legal means of
> > > retaliation, but it's unlikely to be a claim that the retailer didn't
> > > have license to anthologize the MP3 player's doco with the dismantling
> > > instructions. Nor is it contributory infringement if the instruction
> > > sheet says "look at Figure 3 in the player's Quick Install Guide to
> > > find the pressure points on your particular model".
> >
> > How would this be if the MP3 player came with a sale condition
> > that the MP3 player not be resold in dismantled form? Could
> > this bundling then be construed as an unlawful attempt to
> > circumvent the sale condition? And again remember that the GPL
> > FAQ viewpoint is not (primarily) about the copyright on the API
> > definition / MP3 player's doco, but about the copyright on the
> > API implementation / big CF chip.
>
> That was not the intent of this analogy. As I wrote, the MP3 player
> vendor might have some legal means of retaliation. But claiming that
> the retailer has "anthologized" the MP3 player doco with the
> dismantling instructions, or claiming that references to figures in
> the doco make the instructions a "derivative work" of the doco, and
> then trying to proceed directly to preliminary injunction under
> copyright law just isn't going to get them anywhere.
>
Since the MP3 manufacturer in your hypothetical is trying to
protect the device, not the doco, I find it difficult to get a
good parallel without treating it metaphorically as if the MP3
player itself was a copyrightable work rather than a piece of
hardware. For a better variant of the analogy consider that the
item being salvaged is not a CF chip but a pre-burned ROM
containing copyrighted music not licensed for use outside the
context of the player.
> > > The phrase "work based on the Program" is defined in Section 0 as
> > > "either the Program or any derivative work under copyright law", and
> > > then that legal definition is incorrectly paraphrased. Under the
> > > legal definition, I think it is clear that only creative adaptation
> > > creates a derivative work, and linking X against Y doesn't qualify (as
> > > long as X is not derived from Y in a creative sense).
> >
> > But does "a whole which is a work based on the Program" mean the
> > same as "a work based on the Program" (call this "YES"), or does
> > it also cover a whole (copyrightable as a whole or not) which
> > includes within itself a copyrightable portion which is truly "a
> > work based on the Program" (such as, by example, the Program
> > itself)?
>
> Er, that would be "a whole which contains a work based on the
> Program". "is" \neq "contains". And it's just plain perverse to
> claim that "a whole which is a work based on the Program" can be
> interpreted without reference to the Section 0 definition of "work
> based on the Program". Nice try, though. :-)
I am not trying to interpret it without reference to the Section
0 definition. I am considering the possibility of maybe
interpreting the longer and different phrase as referring to
different set of items implicitly defined *in terms of* the
definition of "a work based on the Program" as defined in
Section 0. Put another way I am considering the potential
interpretations of the prefix "a whole which is" when used in
front of that phrase.
>
> > And does "a work based on the Program" indeed have the limited
> > meaning debated elsewhere in this message?
>
> Ask a court. I've beaten that horse as much as I'm going to.
Which is why I was not arguing it here, just declaring a logic
dependency on the (as yet disputed) outcome of that animal
abuse.
>
> > As I wrote, if the answers to these two questions are YES, YES,
> > then the GPL looses its reach, and several of its permissions
> > (including the "mere aggregation" paragraph) become no-ops
> > granting permissions already granted. But if either of these
> > two questions are answered with a NO, then this paragraph is
> > disclaiming the GPL's reach in fewer cases and the other
> > paragraphs are no longer no-ops.
>
> Actually, there is a sense in which they're not no-ops. I think they
> estop the offeror from claiming in a courtroom that they didn't intend
> to authorize the conduct that is explicitly permitted in them. But
> the contract's meaning is otherwise the same with or without them.
> (IANAL, and all that.)
>
> > > "Mere aggregation" has no legal meaning as far as I can tell, and this
> > > whole paragraph is a no-op. I believe it was written to reassure
> > > people about putting GNU and UNIX on the same tape.
> >
> > Actually the GPL goes out of its way to (try to) ban that
> > specific action.
>
> Where do you read that?
In the "part of the operating system" paragraph there is
explicit language making that exception conditional on said part
of the operating system not accompanying the GPL work. I have
heard rumors that when Sun, Microsoft and others occasionally
ship GPL works, they do so on a physically separate tape, CD or
DVD to comply with that condition. Similarly, in the OpenSSL
scenario (see the subject line of this debate), a work shipped
on CD#1 along with the Linux Kernel, gcc, glibc, OpenSSL and
other works is normally considered incapable of taking advantage
of that clause, but a GPL work shipped outside Debian but
created to run on a Debian system where OpenSSL accompanies
those major components of the Debian operating system might be
able to link to the CD#1 copy of OpenSSL because of that clause.
>
> > The paragraph is an effective no-op, if the paragraph before it
> > already permits the same thing. Assuming for the sake of
> > argument that this is not the case, then the next question
> > becomes what actions it does permit.
>
> See my <mode sarcasm="on"> post for commentary on that point.
See my 3 point list above for why it makes sense to consider
what a clause would mean if it was not rendered redundant, even
if one might (or might not) strongly believe that it was indeed
redundant.
>
> [snip]
> > > Sorry, I misspoke; contracts are construed against the offeror, not
> > > against the drafter, when there's a distinction. The offeror had the
> > > option of proposing language as explicit as he or she chose, so
> > > ambiguities are as a matter of law construed against his or her
> > > interests. That is the case even if the offeror chose a boilerplate
> > > license drafted by someone else.
> >
> > AH, that is a big difference indeed. But what happens if the
> > person offering the contract text is not the person offering the
> > goods or services being contracted? Like if someone hands out a
> > form contract offer that people need to sign to be considered
> > for an audition, or if the licensee has directly or indirectly
> > asked the licensor to use the GPL.
>
> The "offeror" is the entity that brings proposed contract terms to the
> table. There are probably corner cases, but once it can be
> demonstrated that an instance of the GPL has been accepted by X with
> regard to work P, each copyright holder on P stands in the role of
> offeror under the GPL. Not counting code cribbed by a third party
> without the copyright holder's permission, of course, and modulo
> interpretation of the weird "automatically receives" language in
> Section 6, which could go off into doctrines of implied agency and
> such strangeness.
>
I was thinking of cases where Y brings the GPL text to the table
and tells X to make the GPL offer with respect to P in order to
attain some benefit.
> [snip]
> > There are 3 issues here:
> >
> > Does "a work based on the Program" cover separately engineered
> > programs inspired by or designed for use with "the Program" (I
> > hope not)?
>
> I believe that it does not, irrespective of the mechanism of use,
> unless the usual abstraction-filtration-comparison test (or whatever
> is current in a given jurisdiction) succeeds in finding that the later
> program constitutes a derivative work of the earlier at an expressive
> level.
>
> > Does "a work based on the Program" include works (copyrightable
> > or not) that include within them a copyrightable copy or
> > derivative of "the Program", to the extent that the GPL has not
> > explicitly exempted those larger bundles as "mere aggregation"
> > (whatever that means)?
>
> I believe that it does not, based on what seems to me to be the most
> natural construction of the language of Section 0.
>
> > Does the GPL impose conditions on the combination of "a work
> > based on the Program" with something not "a work based on the
> > Program" in some limited circumstances?
>
> It appears to me that Section 2b would impose such conditions if it
> were not for the "a whole which is a work based on the Program"
> language in the paragraph following 2c. The remainder of Section 2
> muddies the water further:
>
> 2b) ... any work that you distribute or publish, that in whole or in
> part contains or is derived from the Program or any part thereof ...
>
> (paragraph after 2c) ... But when you distribute the same sections as
> part of a whole which is a work based on the Program ...
>
> (next paragraph) ... the intent is to exercise the right to control
> the distribution of derivative or collective works based on the
> Program ... [the only place where the drafter mentions "collections"
> or "collective works"]
>
Could the textual proximity and relationship of those two
paragraphs be read so as to define the "a whole which is" prefix
to mean "optionally collective work of", given that there might
be no other definition of that prefix in sight?
> ... and then the "mere aggregation" clause.
>
> See why there's a principle of construction against the offeror? The
> only way I see to construe a single interpretation out of this muddle
> is to say that the broad language of 2b is narrowed back to the same
> scope as the rest of the contract by a restatement that only mentions
> two cases -- distribution "as separate works" and "as part of a whole
> which is a work based on the Program". The claim that "the intent is
> to exercise the right to control the distribution of derivative or
> collective works based on the Program", and the "mere aggregation"
> clause, then reduce to estoppel fodder.
Different legal systems might not go so far as to constructing a
contract in a manner which would make it so much more
inconsistent than another construction more consistent with a
plain reading of the totality of its text.
>
> The reductio ad absurdum still holds with respect to 2b in isolation,
> of course; nobody who accepts the GPL really believes that it reaches
> to the largest conceivable "work" that encloses the Program, once it
> occurs to them that their living room is such a "work". (Hey, my
> living room is a work of art; isn't yours?) And indeed neither you
> nor I would accept it without the rest of Section 2; and I don't know
> about you, but I certainly observed the six usages of "work[s] based
> on the Program" in Section 2 the first time that I read the GPL, and
> without being particularly conscious of the "construction against the
> offeror" principle I decided that the subsequent "separate works" /
> "whole which is a work based on the Program" dichotomy cut 2b down to
> a size that I could stomach.
>
See my 3 points list above.
> [snip]
> > Not much here that differs from what I wrote (and you quoted)
> > above: The judge deferred ruling on the derivation issue to a
> > later trial, but actually leaned towards derivation. The
> > preliminary injunction was denied because the judge was not 100%
> > certain that derivation would win in the end, and because a
> > balance of harms consideration indicated that such a drastic
> > measure should await further proceedings. Those later
> > proceedings never happened because of an out-of-court
> > settlement.
>
> I repeat, that's not why it was denied. Check out the full opinion at
> http://pacer.mad.uscourts.gov/dc/opinions/saris/pdf/progress%20software.pdf
> . There are a standardized sequence of criteria for preliminary
> injunction (at least under the US version of common law; YMMV), and
> the judge followed that sequence to the letter. MySQL would have to
> have met all of the major criteria: likelihood of success on the
> merits, potential for irreparable harm, and balance of equities/harms
> (courts of fact rarely go into the effect on the public interest in a
> routine contract law case). They didn't meet any of them.
>
> The judge's stance on the "derivative work" issue (note: she appears
> to have ignored the paraphrase and concluded that the factual dispute
> hinged entirely on whether Gemini had created a derivative work) was
> indeed to lean towards MySQL's interpretation, based on a review of
> the parties' affidavits followed by oral arguments of which I have yet
> to find a transcript. But she then systematically trashed MySQL's
> case that winning that point would meet the "likelihood of success on
> the merits" criterion, let alone the others. Had there been any
> reasonable prospect of piercing the contract and proceeding to
> copyright law standards, MySQL would have been entitled to an
> automatic presumption of irreparable harm and a bye on the "balance of
> harms" standard.
>
What I said, the judge was not convinced that the likelihood of
success on the merits was sufficiently high so as to grant a
*preliminary* injunction. This is very different than saying
that there was a greater likelihood of the opposite outcome.
And then there was the apparent ruling that the defendants
corrective actions reduced the harm significantly compared to a
hypothetical case where the defendant had taken no such actions.
> > So the injunction tactic failed, the GPL was declared enforcible
> > in general, and the more specific issue of derivation and
> > linking was deferred to a trial that never happened.
>
> I think it's way too strong to say that Judge Saris declared anything
> of the kind. I think (although I have not read their affidavit) that
> Progress Software did not dispute acceptance of the GPL, and argued
> exclusively that Gemini was not a derivative work of MySQL's GPL code
> and that they had in any case acceded to MySQL's GPL-related demands
> by the time of the hearing.
>
OK, still I see no ruling against the GPL here. No ruling
against derivative work. Only a failure of the injunction
tactic in a case where the defendant had already corrected their
behavior.
> Mind you, there is no particular reason to think that the GPL is not
> just as valid an offer of contract as any other shrink-wrap license.
> It is somewhat less common for install media for GPL software to force
> a "click-through" acceptance than it is for closed-source "freeware";
> but there is little question that (at a minimum) creating a derivative
> work and then redistributing it constitutes acceptance by conduct,
> since there's no way you can claim that you didn't need copyright
> license to do that. Well, you could claim that you thought it was
> public domain; but there is separate, ironclad precedent on that point
> (Planetary Motion v. Techplosion 2001).
>
> [snip]
> > > If gcc, flex, and bison had purported to create GPL-encumbered output,
> > > few people outside the FSF would ever have cared to use them. Few
> > > people had any interest in glibc before the LGPL was drafted to give
> > > it some viability beyond the pure-GNU-system enthusiasts. (Bluster is
> > > a nuisance even if you don't believe it's enforceable.) Perl's
> > > Artistic License came first, and Larry added the GPL so people could
> > > write XSUB glue to (L)GPL libraries without doing legal research, and
> > > nobody ever seriously argued that Perl programs had to be GPLed.
> >
> > You missed my point here: The 30.000 feet view you described as
> > well as cases that cite fairness in competition in various ways
> > are based on legal theories applying only to a small subset of
> > the cases where the derivation theory in the GPL FAQ might be
> > applied or rejected. In actual practice, the various holders of
> > important GPL copyrights have directly avoided such a clash
> > between fair competition and GPL FAQ derivation theory.
>
> Well, in that where there was any question, most people steered clear
> of these bits of software until the FSF made enough concessions to
> lull their suspicion. Remember, cc, lex, and yacc came first; the
> only significant non-classroom use case for flex and bison when they
> were pure GPL was to build gcc, which I think acquired the "don't
> stress about the bits of our chocolate that wind up in your peanut
> butter" clause early in the game. I don't think you can really credit
> the FSF with habits of conflict avoidance; Eben Moglen is on record as
> telling the world, more or less, "you wanna piece a' me? you wanna be
> my sacrificial lamb?" (
> http://www.gnu.org/philosophy/enforcing-gpl.html ).
>
I did not say they tried to avoid conflicts in general. I said
that the FSF seems to be trying to steer clear of some losing
battles in order to preserve the strength of their licenses for
more winable battles.
> > This makes sense: case law tends to be influenced by the
> > concrete facts of whichever concrete case gets to set the
> > precedent. If the first case to fully test the GPL derivation
> > theory is one where the purported violator was merely using an
> > unavoidable system interface covered by the GPL, then a court
> > would tend to rule in favor of fair competition and against a
> > license interpretation creating a monopoly. If the first case
> > is one where the purported violator was actively trying to
> > circumvent the GPL by putting avoidable code received under GPL
> > in a shared library in a way that makes no sense otherwise, the
> > court would be more likely to rule in favor of GPL FAQ theory.
> > So it is prudent for those with an interest in the enforcibility
> > of the GPL FAQ theory to carefully choose their battleground and
> > make way in places where they are more likely to loose.
>
> Happily, contrary to what many people think, that's not how binding
> legal precedent is created (in the US, anyway). The only court that
> can set a precedent with regard to a point of law is an appellate
> court, and appellate courts have no power (in principle) to make or
> change determinations of fact regarding the parties' conduct. But
> you're right -- since the FSF is engaged in social engineering rather
> in clearing up people's confusion about the law, I fear they are only
> interested in getting into a courtroom if they can engineer an
> apparent "win". I invite you to read the MySQL opinion side by side
> with the FSF's press release (
> http://mailman.fsfeurope.org/pipermail/press-release/2002q1/000035.html
> ) and to form your own judgment about the motivations of the
> individuals involved.
>
I am more concerned about social engineering directed at the
courts. How many appellate court rulings tend to involve
multiple points of law? And how many of those rulings become
precedents for cases where only some of those points of law are
present?
> > MySQL was actually a risky case to try: MySQL AB is pushing a
> > far-reaching variant of the GPL FAQ theory way beyond what is
> > commonly accepted. It could easily have resulted in a much
> > worse precedent for the GPL side because of that.
>
> In my eyes, it's a catastrophic precedent, from which nothing but
> instant out-of-court settlement could have distracted attention. The
> popular press seems to have taken the press releases at face value at
> the time -- but then who has time to research when you're on a
> deadline? And it's so, so sad that the FSF has put so much of its
> credibility into a set of claims about the legal significance of the
> GPL that I believe will sooner or later be demolished in court in a
> way that no press release can spin.
You have yet to quote anything from that precedent that actually
ruled against the GPL in any way.
>
> > > As for Linus and Linux, it appears that his opinion about the legal
> > > meaning of the GPL is not too far from mine (though not quite
> > > identical; see thread at http://lkml.org/lkml/2003/12/4/239 , for
> > > instance) and that he's done the sensible thing and estopped himself
> > > from pursuing a class of silly copyright infringement claims. Which
> > > is what the FSF should do, and then we can all get on with making
> > > software that sucks less.
> >
> > The FSF should do that if it is in its interest or makes no
> > legal difference.
>
> Or, of course, if they do know better and they value their credibility
> as individuals or as an institution. They may have a bunch of law up
> their sleeve that I can't find, or I could just be sadly incapable of
> legal reasoning. But I call your attention to the fact that an
> attorney at law who is admitted to the bar in a given jurisdiction is
> in fact an officer of the law, and is sworn to uphold the law to the
> best of his ability, modulo a few very limited outs related to
> attorney-client privilege. If Eben Moglen has no reasonable basis for
> a belief that his public statements about the legal implications of
> the GPL are true (which I am not qualified to assess), then he is
> skating on some rather thin ice.
>
This is what I meant by "makes no legal difference". If they
believe that your analysis is correct, then it would make no
legal difference for them to admit so and move on. If they have
any doubts (or even a firm belief to the contrary) then making
such a declaration should be done only if it is in their
interest to do so for reasons other than your analysis.
> > It is in Linus interest to assure the world that running on top
> > of a Linux kernel does not subject your code to the terms of the
> > GPL, and to do so in a manner seen as legally binding by those
> > who might otherwise refuse to use his big creation.
>
> I believe that Linus chose the GPL at a date when the LGPL was also an
> option, and did so with no intention of suggesting that userspace
> programs would be obliged to be GPLed. He's long since estopped out
> the yin-yang from making any such claim, as is anyone with enough
> knowledge of what a kernel is to submit a patch to the LKML. Sneering
> at Linus's "big creation" does not become you.
I am not sneering at it, it really is a big creation, perhaps
the greatest thing he will ever do to benefit mankind (but he is
still young, and might still live to do even greater things). I
am saying that to further this great benefit to mankind it is in
Linus' interest to assure the world that there is no legal risk
in running non-GPL software or drivers on a Linux-based
operating system, even at the cost of imposing extra legal
restrictions upon himself.
>
> > The FSF has a different interest in many cases, especially for
> > its various GPL-ed libraries and it is thus in the interest of
> > the FSF to stick to its GPL interpretation if at all possible,
> > and grant explicit additional permissions in the cases where its
> > software would otherwise not be used, or where the circumstances
> > could otherwise inspire the creation of case law to the
> > contrary.
>
> Well, I'll just say that gerrymandering the licenses on individual
> software components to avoid exposure of a fraudulent legal
> interpretation -- if that is in fact what the FSF is doing, which I am
> not qualified to judge and emphatically do not assert -- does not
> strike me as a way to retain the public's trust as the guardian of
> copyright on a substantial corpus of software, much of it donated on
> the basis of that trust.
>
I see it more as culling the licenses where they could be ruled
invalid for legal reasons not applicable to the license in
general. Like cutting a branch off a tree in your garden to
prevent that particular branch from growing out on a public road
where it could be declared a menace to public safety, causing
the entire tree to be cut down at court order.
> [snip]
> > Disclaimers: IANAL, TINLA, IANADD, plus the one in my sig
> >
> > Jakob
> >
> > P.S. The disclaimer in my sig has not been cleared through a
> > lawyer. Its primary design criteria was the 4 line limit of
> > Usenet sigs.
> >
> > --
> > This message is hastily written, please ignore any unpleasant wordings,
> > do not consider it a binding commitment, even if its phrasing may
> > indicate so. Its contents may be deliberately or accidentally untrue.
> > Trademarks and other things belong to their owners, if any.
>
> Whew. All of a sudden we're both getting very, very careful about our
> disclaimers. Disclaimers about disclaimers, no less. In the course
> of writing this message I learned for the first time about the
> existence of Daniel Wallace's suit.
The kind of suit that my 3 point list above is about.
>
> To whom it may concern: my debian-legal and debian-devel postings on
> the topic of the GPL are Copyright (C) Michael K. Edwards 2004, 2005
> (as applicable), All Rights Reserved, and you plagiarize them at your
> peril. I am not a lawyer or legally qualified to any degree in any
> jurisdiction, and everything I say is at least a little bit wrong.
> Any use you make of evidence I cite, or of the ideas contained in an
> argument I make, is without my consent or personal involvement and at
> your own risk unless you can exhibit a signed, notarized written
> agreement to the contrary.
>
> As for the expressive content of my writings, I will, sooner or later,
> read every document that is part of the public record of any court
> proceeding involving the GPL, and I assure you that I will notice any
> derivative work that you create without my permission, either explicit
> and in writing or the absolute minimum implied by my having sent
> messages to their original recipients and implicitly to the Debian
> e-mail archives, which are not in the public domain. For all my
> differences with the FSF, I will not be used as somebody's
> stalking-horse against them.
>
> Cheers (to debian-legal, anyway)
> - Michael
Are you making a legal commitment to read a potentially infinite
amount of public records within your lifetime?
Disclaimers: IANAL, TINLA, IANADD, plus the one in my sig, I do
not encourage or advise anyone to duplicate these disclaimers
for themselves, nor do I profess to prohibit anyone from doing
so at their own peril.
Jakob
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
Reply to: