Michael K. Edwards wrote:
> On Wed, 26 Jan 2005 12:33:35 -0800, Josh Triplett <josh.trip@verizon.net> wrote:
>>That's the *point* of the GPL: to create a set of software available for
>>use by GPLed applications, giving those applications an advantage. If
>>GPLed components make it easier to develop Free Software applications
>>(which you inaccurately describe above as making it more difficult to
>>develop proprietary applications), then that's a good thing for Free
>>Software.
>
> <rant>
> That may be the point of the GPL in some people's eyes, but it ain't
> there in the text, unless you're relying on the afterthought about the
> LGPL. The major point of the GPL is to keep free software free. A
> Balkanized licensing landscape, with most reusable components under
> temporarily neutered version of the GPL or totally unrelated and
> sometimes incompatible licenses, doesn't serve that goal. Nor does it
> make it easier to develop Free Software applications that work well.
>
> And it certainly does make it more difficult to develop proprietary
> applications that can coexist with free software applications on a
> GNU/Linux system without massive bloat. I can't even run KMail,
> OpenOffice, and Firefox on the same system without getting nailed for
> triple the memory footprint (and triple the bugs) in code that
> provides 95% identical functionality -- let alone, say, Komodo or
> Acrobat Reader.
>
> Sure would be nice to run Nikon Capture (or DXO Raw Engine) on my
> Linux box to get a free-as-in-beer (or cheap-for-its-value)
> implementation of photo importing, correctly calibrated for my camera
> and lens. But it ain't gonna happen, largely because tying to GPL
> components is just as big a problem for people who are protecting
> sweat-of-the-brow in which none of us really has a legitimate "free
> speech" interest as for those who are trying to perpetuate their grasp
> on a spreadsheet that doesn't suck.
>
> I used to be pretty damn good at image processing, and would be at
> complete liberty to contribute to the GIMP now that I'm out of that
> line of business. But I'm not going to get around to it as long as I
> can't get the damn thing to build on MacOS and can't get good enough
> import results on GNU/Linux. How's that for collateral damage?
> </rant>
>
>>I find it difficult to separate your arguments regarding the extent of
>>the GPL's copyleft from your apparent opposition to the idea that it is
>>desirable for this scope to be as broad as possible.
>
> I am, in fact, opposed to the idea that unlimited reach for copyleft
> is desirable. I don't really care whether the software inside my
> microwave oven is Free. I do want my government and my cellphone to
> run on Free Software, and neither will happen in my lifetime if there
> isn't a commercially viable transition strategy. My opinion doesn't
> underly my legal analysis, though; it is a consequence of having read
> some case law and found that the FSF's attitude stands between us and
> a legally defensible modus vivendi that would get the job done.
Get what job done? Defanging the GPL, removing its copyleft provisions,
allowing proprietary companies to build from the commons without giving
anything back?
>>I believe this thread has become strongly sidetracked, from a simple
>>discussion regarding one of many interpreters for a relatively standard
>>language and a program written in that language, into a general attack
>>upon the foundations of the GPL. I would suggest that while it is
>>beneficial to argue that Eclipse is in no way a derivative work of Kaffe
>>(and therefore not subject to the GPL on Kaffe), it is harmful to
>>attempt to do so by arguing that the entire foundation of the GPL is
>>invalid. There are enough opponents of Free Software who are more than
>>willing to attempt such arguments; let us not assist them.
>
> I hate to break it to you, but "opponents of Free Software" don't need
> my help to read US case law. I used to think that proponents didn't
> either, but my confidence in that belief isn't what it used to be.
> Happily, legal precedent supports the validity of 99% of the text of
> the GPL and 99% of the ways that people are using it today. It just
> doesn't support the FSF's anti-linking stance or their threat of
> preliminary injunction under copyright standards without going through
> contract analysis first.
> If you're suggesting that I'm a stalking-horse for the Forces of
> Darkness, you're late to the conversation. ;-)
I'm not suggesting that you are *trying* to support the opposition. I'm
suggesting that whether you intend to or not, you are.
>>If you believe the copyleft in the GPL is weaker than expected, perhaps
>>you could provide some constructive suggestions on how to strengthen it.
>
> Sure. Want a pool of code that no one can legally exploit through a
> published interface? Don't publish any interfaces. Make sure that
> everything is both code and data, that all component boundaries are
> mere social conventions, and that no one can tell which bit of code
> came from where. The result will look a lot like a Symbolics Lisp
> machine, and will be a lot of fun to play with. It will be both a
> superior learning environment for the clever but inexperienced and a
> superior working environment for those who understand it intimately.
> There will be the occasional philistine who just wants a text editor,
> but they can always use vi.
That was a singularly unhelpful response. I'm not looking to rewrite
the world in Lisp, nor do I wish to kill off the idea of reusable
components. I'm just trying to ask a reasonable question: Suppose that
I *do* believe that copyleft should be extended as far as possible
(which I do), and suppose that I believe your arguments that the GPL
fails to do that (which I don't); given that, how can the GPL be fixed
(or replaced, or some other mechanism used) to further the goal of
extending copyleft as far as possible?
> Seriously though, "coopetition" across documented interfaces is the
> norm these days. The exceptions are on the very low end (embedded OS
> + proprietary application without much need for, or skill at, code
> reuse) and the very high end (supercomputer OS + application tuned
> over decades to push its performance limits). Why should anyone be
> surprised that courts notice and foster this norm in a commercial
> setting? Why should Free Software advocates fight it, when it allow
> students to learn commercially useful skills on a platform that is
> good for their souls, while more and more older pros can combine
> contributing at least some of their energy to Free Software with
> putting bread on their children's table?
If you want to argue against copyleft, please do so separately from your
attempts to attack the strength of the copyleft in the GPL. This
argument belongs in a "please don't use the GPL" rant somewhere, perhaps
on a BSD-advocate's site.
>>>I don't think the "distributing a competitor's product" argument
>>>should apply either, even if the GPL were to use some non-copyright
>>>mechanism to disallow distribution of commercial and free software
>>>together. Suppose Connectix had bundled legitimately acquired
>>>binaries and licenses to PlayStation games with their emulator. Would
>>>that change the logic of Sony v. Connectix? Would a clause in every
>>>PlayStation game's license forbidding the use of the game with any
>>>non-Sony console do the job?
>>
>>Connectix created an alternate implementation of the PlayStation
>>interface; no one is arguing against that ability.
>
> Last I checked, some people were arguing against the legitimacy of
> running Eclipse on Kaffe because this alternate implementation of the
> JVM interface happens to expose the inconsistency of the "linking
> creates a derivative work" stance.
No, people are arguing against the legitimacy of running Eclipse on
Kaffe based on some absurd interpretation of "mere aggregation" that
makes "Depends:" somehow relevant. Furthermore, I'm not arguing the
simplistic notion that "linking [automatically] creates a derived work".
As I said, this thread has become quite sidetracked. You support the
notion that Kaffe+Eclipse is OK, based on an strange interpretation of
the GPL in an attempt to support your belief that copylefted components
are a bad idea; I oppose your interpretation, but I still believe
Kaffe+Eclipse is perfectly acceptable for completely different reasons.
>>>My impression is that the same court system that discourages direct
>>>abuse of copyright monopoly frowns on tricksy indirect mechanisms as
>>>well. Although I don't have precedents handy, I would expect that
>>>rules that clauses forbidding competitive interoperation in licenses
>>>are unenforceable, especially in a "standard form" contract with
>>>little or no opportunity to assess the consequences and negotiate.
>>
>>Use of words like "abuse" and "tricksy" to describe copyleft sound about
>>as convincing as those who attempt to label the GPL "viral".
>
> Courts and respectable commentators do use phrases like "abuse (or
> misuse) of copyright monopoly" to describe the conduct of plaintiffs
> who knowingly push the limits of copyright protection for
> anti-competitive purposes. Hint: Google for "abuse copyright
> monopoly Lexmark". Or check out a case of real copyright misuse;
> here's one from the Seventh Circuit: Assessment Technology v. WIREdata
> ( http://caselaw.findlaw.com/data2/circs/7th/032061p.pdf ). Watch for
> a decision in Blizzard v. BnetD (Eighth Circuit), too; there are
> several good amici briefs linked from
> http://www.eff.org/IP/Emulation/Blizzard_v_bnetd/ .
>
> "Tricksy", however, is not a legal term; it's a Tolkien-ism ("tricksy
> hobbitses!") and was meant humorously.
I was well aware of that.
>>I see no reason why one should have the right to ignore terms they don't
>>like, nor do I see why this should become the case if they did not have
>>the opportunity to negotiate alternative terms that they would prefer.
>>If you don't like the license, find another piece of software.
>
> It's not "terms they don't like", it's "terms that try to use contract
> law to abuse the copyright monopoly in a way that would not be
> permitted under copyright law alone."
If a copyright is valid, any license saying "you can do [action
restricted by copyright] if you do X" should be valid for absolutely any
value of X, for the simple reason that the copyright holder doesn't have
to say "you can do [action restricted by copyright]" *at all*. In all
the cases you have cited, the copyright simply wasn't valid, so it
didn't matter *what* licenses or the copyright holder said.
Regardless, I was primarily referring to your comment "especially in a
'standard form' contract with little or no opportunity to assess the
consequences and negotiate"; that was why I responded with the idea that
whether or not you get to negotiate for terms you might like better is
irrelevant to whether you are bound by the terms you have available.
You aren't forced to accept the terms in the first place.
>>Back to your message:
>>
>>>As for the DirectX example, when was the last time Microsoft resorted
>>>to mere lawsuits to obtain compliance with its strategic imperatives?
>>>Those clauses get the message across: accept lock-in or we will
>>>destroy you. Do you really approve of similar tactics in the name of
>>>software freedom?
>>
>>Free Software (as a whole) is not equivalent to Microsoft (a single
>>organization). Free Software "winning" would not create a monopoly or
>>establish control over users and developers. And Free Software is not a
>>lock-in, as you are quite capable of using and/or developing competing
>>software. Regardless, I was not equating the terms in question, only
>>stating that there exist other cases where in order to distribute the
>>software to which API you are writing, you must follow certain conditions.
>
> This is not about Free Software "winning", and it doesn't have to be a
> zero-sum game. Think of the professional / amateur distinction in
> other fields, such as athletics and photography. "Amateur" in this
> sense isn't a term of disrespect; it means that one does it because
> one loves it. Amateurs benefit from the existence of professionals in
> their field, but they also have to live by rules that are designed so
> that the pros can make a living.
>
> Like most Free Software contributors over 30, I have an "amateur"
> software developer hat and a "professional" developer hat. Wearing my
> amateur hat, I want to do novel things in novel ways whether there's a
> market for them or not. Wearing my professional hat, I want there to
> be a reasonably secure mechanism for a business I run, or an employer
> who hires me, to recoup their investment in my beer and skittles.
> Like a pro basketballer who's an amateur baseballer, or a pro portrait
> photographer who's an amateur at landscapes, I don't want to have to
> change my operating system, my camera, or my jockey shorts depending
> on which hat I'm wearing at the time.
Again, this is basically an anti-copyleft rant, which belongs on some
pro-BSD site somewhere. If you want to argue against copyleft, argue
against copyleft. If you want to argue against the extent of the GPL's
copyleft, don't attempt to do so by bringing up why you think it would
be good for that copyleft to be weakened.
> Let's continue the parallel to DirectX. You're capable of developing
> a competing, non-interoperable gaming framework. There won't be any
> games for it on initial release, and all of the commercial game
> publishers will be bound by contracts and extortion not to create any,
> and you won't have a prayer of getting it to run on an X-box, but
> these considerations only affect your prospects of filthy lucre, and
> who cares about that? Courts do. I would look to a court for relief
> if Microsoft came down on me for cloning DirectX, and I'd cite all the
> same precedents. The court's overriding priority is to interpret the
> rules so that no one who plays fairly is forced out of the game by
> unjust legal means. Hence it is, if anything, less likely to ratify
> an interface monopoly on communitarian principle than on commercial
> grounds.
If you clone DirectX, using established principles like cleanroom
analysis and documentation, then I'll gladly defend your right to do so.
You can do the same thing for GPLed software (though I won't stand up
for you there :) ).
>>>Note also the absence of actual legal proceedings. It is also worth
>>>noting that the GCC front end / back end interface is somewhat fluid,
>>>unusually complex, and not intended for arm's length use.
>>
>>You seem to be acknowledging here that there exist interfaces for which
>>your rejection of the GPL's copyleft does not apply. That seems promising.
>
> I'm saying that conceptual boundaries, like "front end / back end",
> within an integral work like the GCC suite, don't automatically
> constitute published functional interfaces. Ever tried to make last
> year's front end work with this year's back end? The separation
> between, say, the C preprocessor and the compiler is a different
> story, even if its "interface" is equally complex.
And I believe that you have yet to establish the relevance of "published
functional interfaces".
>>To be honest, my primary objection to your logic regarding APIs is that
>>I see no real difference from a copyright perspective between a
>>"published" API and the functions provided by the guts of a program, the
>>latter of which could just as easily be considered an API. There are
>>library APIs which are fluid and complex, and there are program
>>internals which are rock-solid and rarely change. I don't believe
>>"published API" can be used as an automatic boundary for the GPL's
>>copyleft, any more than linking can be used as an automatic extension of
>>the GPL's copyleft, or than exec() can be used as a boundary.
>
> Automatic? No. Coders, and courts, still have to make judgment
> calls. But courts do not shrink from tests that take a lot more work
> to apply, such as the Altai "abstraction-filtration-comparison" test,
> which is now the law of the land in the US and Canada. Even "I know
> it when I see it" can be good law at times.
Certainly; I think we're in agreement here, and I certainly hope the
courts will go into detailed analyses in each case rather than relying
on issues like "linking" or "published interfaces".
>>>And
>>>irrespective of legalities, there are few factual settings in which
>>>proceeding in the face of hostility from the maintainers of the
>>>interlocked component would be greater folly than in the case of an
>>>optimizing compiler.
>>
>>Granted; in this respect, the GPL seems to have done its job, whether it
>>was enforcable or not.
>
> The GPL doesn't appear to me to have had anything to do with the
> outcome, except as an agreement among the GCC contributors about what
> they were willing to support and tolerate.
And as a statement to others about what they a willing to support and
tolerate.
> That usage, however, is
> very important; and I think it's good to check in from time to time
> about its interpretation. More and more projects seem to want the
> "linking-friendly GPL" model,
That's called the LGPL, or GPL+exceptions. Projects should say what
they mean, rather than taking an established license and interpreting it
in a nonstandard way. Whether you like it or not, the standard,
established interpretation of the GPL is that the copyleft may extend
across linking and other boundaries.
I don't think you can just say "linking" and be off the hook from the
copyleft, any more than the copyright holder can just say "linking" to
establish that a work is subject to the GPL.
> and the GPL text and case law seem to me
> to support that model without the need for special exemptions. I'm
> willing to stand up and be counted among those who think the GCC case
> is the exception rather than the rule and it would be wiser for the
> FSF to acknowledge this and move on.
Show me a person who truly believes that copyleft *should* extend as far
as possible, but doesn't think the GPL's copyleft works as expected;
until then, I think you are conflating what you would *wish* to be the
case with your arguments that it actually *is* the case.
>>>Similar conclusion, mostly different logic. Sega v. Accolade ruled
>>>that the reverse engineering process was permitted as "fair use"
>>>although the activities it entailed would otherwise have constituted
>>>infringement. This is a sensible mechanism by which to limit abuse of
>>>the copyright monopoly to block access to the ideas contained in a
>>>work that is distributed in a form ordinarily interpreted only by a
>>>machine, and is the main legal idea for which Sega is cited as
>>>authority in later cases.
>>
>>Of course; ideas are not copyrightable, and this case would be
>>reasonable precedent for arguing that you should be able to create a
>>proprietary reimplementation of the ideas in a GPLed work, even through
>>cleanroom analysis of that GPLed work. Accolade did not distribute any
>>of Sega's copyrightable material.
>
> Cleanroom, shmeanroom. That's for unpublished material. Read, learn,
> use, just don't plagiarize.
Good luck proving your replacement isn't a derived work after you've
studied the GPLed work you are replacing.
>>>To the extent that Sega also applies a theory of uncopyrightability of
>>>purely functional elements to legitimize copying of the Genesis
>>>"unlock code", it cites Computer Associates v. Altai as authority for
>>>doing so. The Sega court's paraphrase of Altai states that functional
>>>elements may be dictated "by external factors such as compatibility
>>>requirements and industry demands." Lotus and Lexmark go well beyond
>>>Sega in stating the public policy rationale and the beginnings of a
>>>litmus test for finding the elements dictated by compatibility
>>>requirements and declaring them to be uncopyrightable. These criteria
>>>translate quite well to contexts other than hardware "unlock codes".
>>
>>In the Sega v. Accolade case, it was decided that there was no method
>>for interfacing with the Sega hardware other than copying that exact
>>sequence of code, though Sega tried to argue otherwise by using their
>>internal knowledge to work around it. Furthermore, the code segment in
>>question was short, and would need to be (AFAICT) identical in order to
>>pass the check. As with the Lexmark case, you just can't say "if you
>>don't provide '42' to our system it will lock you out, and you can't
>>provide '42' without our permission", because you have no exclusive
>>rights to '42'. You might note that there have been other such systems,
>>such as Nintendo's 10NES system, in which the code required to
>>circumvent the lockout was considered expressive because it need not
>>have been identical.
>
> Agreed. But as I have repeated ad nauseam elsewhere, I am not arguing
> that the body of a library is uncopyrightable; I am arguing that
> distributing the library under GPL terms alongside a closed-source
> application that uses it is perfectly legitimate.
So stop citing precedents that are not relevant for anything other than
1) reverse-engineering for interoperability and 2) uncopyrightability of
purely functional code, given that neither of those are what you are
trying to argue.
>>However, the point of this discussion
>>is simply to discuss the current scope of the GPL. If you want to
>>*change* that scope, this is not the appropriate forum.
[...]
> As for the appropriateness of the forum, I am talking about the
> current scope of the GPL under applicable law. My analysis differs
> from the FSF's assertions on a couple of major points. This bears on
> topics that I didn't start, including the origins of this thread.
> Perhaps the Subject: line is no longer quite accurate; feel free to
> change it. I don't mean to be anyone's spam, though; "follow-up to
> private e-mail" is always a reasonable thing to request. Is that what
> you're requesting?
No, I'm not suggesting that. I'm suggesting that -legal is not an
appropriate forum for discussing anything other than legal issues
related to Debian, and since we've long since stopped talking about
Kaffe and Eclipse (which is a good thing), I don't think we're remotely
on topic for -legal.
>>>What is so great about having nineteen different debugging mallocs,
>>>and having to puzzle over their licenses before risking copying a
>>>technique from one to another?
>>
>>I certainly hope you aren't complaining about the first half of that;
>>the wide variety of available software is highly desirable, as well as
>>unavoidable in the sense that you don't dictate what people work on.
>
> You're quite right, tool diversity is a good thing. Nor should any
> developer of a new tool feel obliged to build a superset of existing
> tools before doing their new thing. That's one reason why license
> compatibility at the code fragment level is extremely important, even
> under an interpretation where linking is OK; someone who cares about
> having the superset in one tool can do the work of riffle shuffling.
So encourage license compatibility, then; since the majority of Free
Software is GPL-compatible, the best way to do that is to encourage
making software GPL-compatible.
>>Furthermore, nothing stops proprietary software vendors from building
>>their software on top of glibc, the kernel, or other required pieces of
>>software, so porting is certainly possible; is it so monumentally hard
>>to avoid building upon GPLed components?
>
> No, it's just monumentally stupid for all of the required components
> to contain latent booby-traps. If some distro's glibc maintainer
> copies in a bit of code from GNU readline, or if some major kernel
> contributor decides that the syscall boundary isn't GPL-proof after
> all, then either the FSF backs down in public or most of us can kiss
> the use of GNU/Linux in our day jobs goodbye. Maybe that would suit
> you just fine, but if so, I fervently hope that you are in a minority.
First of all, I agree with the logic the FSF proposed when LGPLing
glibc, and I don't think it would be beneficial to attempt to ban
proprietary applications from Free platforms. I don't mean to imply
otherwise. As for "booby-traps", that's standard anti-GPL FUD. For
glibc and GPLed applications, the answer is "take that code out"; in the
meantime, if the code is advertised as LGPL, it is generally reasonable
to expect it to be LGPLed, and whoever was depending on that assumption
can simply switch to an actual LGPLed source for glibc. For the kernel,
you've cited enough case law that you ought to know about estoppel.
>>I would also point out that there are many (myself included) who
>>couldn't care less about proprietary applications on GNU/Linux, but
>>benefit from any Free Software generated as a result of the GPL. From
>>my perspective, if the GPL somehow stopped a thousand proprietary
>>applications from supporting GNU/Linux (which seems highly unlikely),
>>and caused a single application or other component become Free Software,
>>I would generally consider that a net win.
>>
>>(Note, of course, that it is theoretically possible to fill in the
>>blanks to make that statement not true; for example, if one of the
>>proprietary applications would lead to millions of additional users of
>>Free Software, then there could be a non-zero benefit to Free Software
>>of having that application available.)
>
> On the planet on which I live, Free Software has millions of users
> because it can be used with free but non-GPL components such as the
> OpenSSL transport, the Apache webserver, the Netscape/Mozilla family
> of browsers, and implementations (free and otherwise) of the Java
> language. These components can in turn be used for commercial --
> sometimes even proprietary -- purposes. None of these things would
> exist in their current form without seed contributions by, and ongoing
> support from, government and commercial users for whom the GPL is only
> tolerable in a "weakened-virus" form. Despise them if you like, but
> it is the merest decency to acknowledge your debt to them.
I already acknowledged that there were cases in which the availability
of proprietary software on Free platforms has a non-zero benefit to Free
Software. I don't believe this has anything to do with the strength of
the copyleft on the GPL; proprietary applications can run just fine on
GNU/Linux without building upon GPLed software and being subject to the
GPL's copyleft.
- Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature