Michael K. Edwards wrote: > On Tue, 25 Jan 2005 18:37:03 -0800, Josh Triplett <josh.trip@verizon.net> wrote: >>Michael K. Edwards wrote: >>>Encouraging competitive interoperation is a valid public policy goal, >>>pursued fairly consistently by the courts in the case law that I've >>>read. Of the theories that have been applied to disallow the use of >>>the copyright monopoly to block interoperation, I think situating >>>published interfaces firmly in the realm of the >>>functional-and-therefore-uncopyrightable is easiest to apply >>>consistently and operates at the right stage of analysis. Even the >>>Supreme Court seems to agree, judging from the transcript of oral >>>argument, although they appear to have been split on the question of >>>whether a decision of this scope ought to be left up to Congress. >>>What's murky about this way of thinking? >> >>What's murky is that you are focusing solely on "encouraging competitive >>interoperation", and ignoring the fact that it is quite possible for >>proprietary software to compete with Free Software *without* using Free >>Software in the process. When was the last time you read a case, apart >>from your frequently-cited Lexmark case (which does *not* apply if the >>code in question has any purpose other than as data that is directly >>verified for authentication purposes), in which one competitor was >>actually *distributing* another competitor's product as part of their >>own, building upon that product? > > 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. > 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. > 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. 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 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. If you believe the copyleft in the GPL is weaker than expected, perhaps you could provide some constructive suggestions on how to strengthen it. > 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. > 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". 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. >>You might keep in mind that redistribution agreements for proprietary >>software components *often* include provisions that address issues other >>than money; for example, redistribution agreements often prohibit >>reverse engineering, prohibit creation of competing products, require >>adherence to some standard, or even require limiting your product to >>only support another product by the same company that provides the >>redistributable component. (For an example of the last of these, see >>the DirectX redistribution agreement, which requires that software using >>DirectX be licensed only to run on Windows.) > > This is true, but doesn't explain the dearth of "unauthorized use of a > published API" cases. Anybody can write clauses like that into a > license. Getting a court to enforce them is another matter. As with > the GPL, the mere threat of enforcement usually intimidates the > licensee, especially when she values the vendor's goodwill. Yet even > when both parties are plenty sophisticated and the contract is fully > negotiated and executed, courts take their own tack on license > interpretation (see the Sun v. Microsoft saga for examples); and when > the evidence of "meeting of the minds" is rather weak, ancillary > clauses are frequently tossed. You seem to be inclined to ignore anything that isn't proven in court to be valid. I'm inclined *not* to ignore anything unless it is proven in court to be invalid. To quote http://www.gnu.org/philosophy/enforcing-gpl.html: > ``Look,'' I say, ``at how many people all over the world are > pressuring me to enforce the GPL in court, just to prove I can. I > really need to make an example of someone. Would you like to > volunteer?'' 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. >>>>In this context, the handling of objective c and gcc is probably relevant. >>> >>>Could you expand on this comment? Is there any history of legal >>>activity or discussion there? >> >>Quoting from http://www.gnu.org/philosophy/pragmatic.html: >> >>>Consider GNU C++. Why do we have a free C++ compiler? Only because >>>the GNU GPL said it had to be free. GNU C++ was developed by an >>>industry consortium, MCC, starting from the GNU C compiler. MCC >>>normally makes its work as proprietary as can be. But they made the >>>C++ front end free software, because the GNU GPL said that was the >>>only way they could release it. The C++ front end included many new >>>files, but since they were meant to be linked with GCC, the GPL did >>>apply to them. The benefit to our community is evident. >>> >>>Consider GNU Objective C. NeXT initially wanted to make this front >>>end proprietary; they proposed to release it as .o files, and let >>>users link them with the rest of GCC, thinking this might be a way >>>around the GPL's requirements. But our lawyer said that this would >>>not evade the requirements, that it was not allowed. And so they made >>>the Objective C front end free software. >> >>(Potential bias of source duly noted.) > > 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. 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. > 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. >>>Nothing about the reasoning of Lexmark is hard to translate to a >>>purely software context, and Lotus didn't involve hardware >>>compatibility. >> >>The reasoning of Lexmark does not translate to *any* context in which >>the software has any purpose other than as a string of bytes that must >>contain particular values in order to interoperate. The same precedent >>is well-established in Sega v. Accolade. > > 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. > 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. >>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. > 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. 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. > 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. > 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". 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? 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.) - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature