On Wed, 26 Jan 2005 12:33:35 -0800, Josh Triplett <[EMAIL PROTECTED]> wrote: > Michael K. Edwards wrote: [snip] > > Of course it is possible for proprietary software to compete with free > > software without employing GPL components. It's also possible for one > > commercial spreadsheet to compete with another without providing a > > compatible menu and macro interface. And it's possible for a software > > game engine to compete with a hardware game console without providing > > an emulation capacity for existing games. > > The latter two cases are in no way related to the first. In neither of > the latter two cases did the new competitor's software utilize the old > software in any way, and no one here is arguing that you cannot write a > proprietary replacement for GPLed functionality.
If the public benefit of interoperability outweighs the harm done to a copyright holder by permitting competitive use of the interface they created, how can it not outweigh the harm to him of permitting cooperative use? You can argue that there's a completely different kind of public benefit that would result from giving free software a special status, but you're going to find limited legal precedent for that view. In any case, the argument from free speech principles doesn't reduce the applicability of these precedents with regard to the copyright holder's economic interests. > > But just as Lotus customers had already invested in learning menus and > > creating macros, and Sony PlayStation users had already invested in > > game titles, many MySQL users (for instance) have invested in > > developing MySQL-bound applications and the knowledge required to use > > MySQL well. Had the Progress Software v. MySQL litigation proceeded > > far enough, I think it is no stretch to argue that MySQL's attempt to > > use the copyright monopoly to obstruct Progress's efforts to reach > > their customers would and should have foundered on the rocks of > > precedent and equity. > > I strongly disagree. No one is arguing that you should not be able to > develop a proprietary program with equivalent functionality to a GPLed > program. The issue concerns the ability to build upon the actual GPLed > program in order to provide that functionality. So Sony should have attacked Connectix, not for emulating the PlayStation's interface in order to compete with it, but for building on customers' access to Sony-authored games to make their emulator useful? Or perhaps Sega should have fought Accolade, not for copyright infringement in the course of reverse engineering to create games for the Sega console, but for interfering with Sega's ability to engage in social engineering within the Sega-game-author community? Fortunately for us all, engineering reality tilts the playing field in favor of componentization; where there are interchangeable components, there are opportunities to find new uses for those components, some of which may compete with their originators' interests; and courts properly frown on the abuse of the copyright monopoly to block this competition. There's a legal device designed to control the terms, not merely of copying, but of use; it's called a patent, and (in theory) requires a much greater showing of originality. > > The same goes for libraries used in desktop applications. Suppose I > > trust, say, Intuit to do a competent job on a small business > > accounting application, and would prefer to run it on GNU/Linux rather > > than one of those other operating systems. If disallowing them from > > linking to GPL libraries shared with free applications makes their > > software needlessly expensive in development cost and memory > > footprint, then I have a legitimate interest in restrictions on the > > GPL's reach. > > 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. > 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. ;-) > 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. 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? > > 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. What, this would be a smaller problem if the first JVM implementation were GPL'd? > > 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 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." [snip] > 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. 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. [snip] > > 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. > 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. > > 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. 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, 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. [snip] > > 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. > > 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. > >>Now, if you wanted to use Lexmark v. Static Control or Sega v. Accolade > >>in the context of AIM servers previously requiring authentication in the > >>form of pieces of the AIM binary, then it applies perfectly there. > > > > To argue that, I think you'd need more than a footnote in Sega. You > > need the more sweeping rationale in Lotus and Lexmark, and a court > > that is willing to proceed on that rationale without the "de minimis" > > crutch. It would also take you off in the direction of punishing > > deliberate attempts to abuse the copyright monopoly -- alluded to in > > Lexmark, but not essential to its logic -- which is somewhat different > > from clarifying the ground rules for building atop software > > components. > > The issue of the functional nature of the TMSS initialization code was > far more than a footnote. Furthermore, I wish you'd stop using terms > like "abuse the copyright monopoly"; the issue at hand is the current > extent of copyright and of the GPL, not whether we approve of any > particular use of it. Terms like you are using are perfectly > appropriate when arguing to reduce the scope of copyright, and I would > gladly support most such efforts. 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. The bulk of the Sega decision is about claims of copyright infringement during the reverse engineering process. The bit about unlock codes is in a footnote, which begins: "We therefore reject Sega's belated suggestion that Accolade's incorporation of the code which 'unlocks' the Genesis III console is not a fair use." It only briefly addresses Atari v. Nintendo to forestall a claim of inconsistency and leans heavily on "de minimis". 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? > > 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. > As for the second half, license incompatibility is obnoxious, and we'd > be better off if all Free Software was GPL-compatible, but it isn't, so > we deal with it. "GPL-compatible" is not the definition of Free, for > ourselves or for the FSF, nor should it be. License incompatibility is more than obnoxious. It is a major limitation on "Free-as-in-speech". It is not something to be complacent about. Most other Free Software licenses are notable for being "not-the-GPL", and the biggest reason for this is concern for the continued usability of a component in exactly the linked-from-proprietary-application scenario we are talking about. > > What is so great about the FSF and ASF > > both insisting on copyright assignment before code can be contributed, > > so the only way to share code between GNU and Apache projects is to > > put it in the public domain? > > That's not a licensing issue, just a policy decision of two different > organizations; take it up with the FSF and/or ASF. It most certainly is a licensing issue. The ASF requires this not least because they can't reuse any code that has appeared previously in a GPL context without a serious audit trail back to explicit release into the public domain by the original copyright holder. Anything previously assigned to the FSF isn't available to them. They're willing to bend over backwards to make their license compatible with the GPL anyway. Other license authors are not so generous, and retaliate with GPL-incompatible clauses in order to make their work unavailable for inclusion in GPL projects. This is freedom? > > And what is so great about raising the > > barriers to porting commercial applications onto GNU/Linux so that we > > get nine different half-assed free-software Excel clones instead of a > > Lotus 1-2-3 port that actually works well enough to fill out and send > > in an expense report? > > As a -legal participant and as someone generally concerned with nitpicky > details (I don't mean that as a bad thing), you should know not to > equate "commercial" with "proprietary". Generally I don't. In this context I really do mean "commercial"; it may well not stay proprietary in the process of porting, or the proprietary portion may be minimized (as in the network management example I gave). But if it overlaps with something else that isn't ready to be open-sourced in its entirety (think of SGI's XFS port to Linux, which had to be very carefully separated from encumbered code), then the GPL isn't going to be a prudent choice as long as the agent-provocateur scenario is plausible. > 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. > 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. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]