On Tue, 25 Jan 2005 18:37:03 -0800, Josh Triplett <[EMAIL PROTECTED]> 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. 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. 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. 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? 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. [snip] > 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. 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? > >>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. 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. [snip] > > 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. 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". > 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. [snip] > See http://www.gnu.org/licenses/why-assign.html for the FSF's stated > reason behind requiring assignment (namely, that they believe they would > otherwise need to seek out the cooperation of all contributors before > suing over license breaches). Whether that is legally true or not, it > is their stated reasoning. > > (After the GFDL, though, I'd personally be hesitant to perform such an > assignment on any code I cared about.) The strictly logistical concern about there being multiple copyright holders is a lot less important under current US copyright law, which conforms to the Berne convention in largely dispensing with registration-related obstacles to copyright enforcement. But the stated reasoning is perfectly reasonable, and is one way of forcing the issue of who gets to call the enforcement shots early in the game. This also protects the FSF from the awkwardness that might ensue if another copyright holder were in a position to place alternate interpretations before the court. > >>>Arguably, the barriers to adoption of GPL components in commercial > >>>software projects are in the interest of programmers of limited skill > >>>and experience, since the usual alternative is in-house Greenspunning, > >>>which seems to be most of what novice programmers are employed to do. > >>>They might also be in the interest of the egos of the maintainers of > >>>some GPL components which would be overdue for a rewrite if > >>>mission-critical projects depended on them. Everyone else loses out. > >> > >>Everone else, with a few million exceptions, sure. > > > > I'm not sure what you mean by this. Who are those few million people, > > and what have they gained? > > Among others, the millions of Free Software users who benefit through > the creation of more Free Software. Sure, if that's what actually happens, but I consider that far from proven. What I see is that the communities surrounding most of the really useful Free Software components have reached a separate peace with commercial software developers, whether that's a totally non-GPL license or a fig leaf (a special-purpose escape clause here, an exec() boundary there) that renders the FSF's stance moot for practical use cases. In a world where the FSF doesn't hold the copyright on all free software -- and hence the unique freedom to copy a best-in-class implementation from one project to another irrespective of incompatible fig leaves -- this makes for an ugly mess at both technical and logistical levels. Do I really have to tell debian-legal participants this? 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? 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? 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? Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
