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? > On Tue, 25 Jan 2005 19:11:27 -0500, Raul Miller <moth@debian.org> wrote: >>Michael K. Edwards wrote: >>>There doesn't seem to be much case law in which a court has been asked >>>to apply sanctions against "unauthorized use of a published API" under >>>a copyright theory. >> >>Right, because people generally pay attention to the license on the >>components they'll be building on and don't bother to make an investment >>in any area where they're likely to have problems. > > There's some truth to this; but I think it's a bigger factor that most > software component business models fall squarely into either the > unpublished camp (with access only granted by negotiated contract) or > the no-fee-to-redistribute camp (with revenues based on toolchain > sales, technical support, and sometimes end-user purchase of hardware > and/or software platforms). Both models provide more practical ways > of pursuing freeloaders than prosecution for copyright infringement. > The GPL, as interpreted by the FSF, is unique in going after > commercial users' intellectual property rather than their cash. 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.) >>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.) >>>As far as I can see, this attitude goes against the legal trend in >>>the US and in any other jurisdiction which looks to the US judiciary >>>for reasoned analysis of the public policy issues. >> >>For contexts where the treatment of copyrighted material is an obstruction >>to hardware compatability, sure. > > 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. 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. >>>Moreover, together with the FSF's bizarre insistence on a "non-contract >>>license" interpretation of the legal basis for the GPL, it discourages >>>established software players from publishing mature software components >>>under the GPL, since they fear that allowing a patch from a competitor >>>to leak into the GPL component will provide a lever with which to open >>>up their entire code base or to obtain crippling injunctions under >>>the generous copyright standard. >> >>The FSF apparently has some analogous fear. Last time I checked, they >>insisted that they be given copyright on code before they accept it into >>their code base. > > I think that has more to do with freedom to tweak the licensing terms > without relying on the dubious "version 2 or later" clause than with > fear of competitive leverage. 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.) >>>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. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature