Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
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.)
And in any case I've tried to be clear that I think Debian's standard
of conduct in this area (going out of its way to resolve GPL
compatibility concerns) is prudent and should be continued, as a
matter of conflict avoidance and courtesy to the FSF. (I may
personally speak less than courteously of the FSF's conduct from time
to time but am just as glad that the Debian project maintains a
largely cooperative relationship with them, at least on GPL issues.)
I do feel strongly that consistently citing the wrong reasons for a
pattern of conservative GPL compliance measures puts Debian at risk of
being estopped from arguing otherwise if and when that cooperative
relationship can no longer be maintained. That's a way of looking at
the problem that is new (and alarming) to me, based on a revised
understanding of how courtroom resolution of contract ambiguities
works.
[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.
[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.
> 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 )
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.
[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).
[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.
> > 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?
> > 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.)
> > 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.
> > 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. :-)
> 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.
> 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?
> 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.
[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.
[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"]
... 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.
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.
[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.
> 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.
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 ).
> 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.
> 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.
> > 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.
> 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.
> 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.
[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.
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
Reply to: