On Tue, 25 Jan 2005 19:11:27 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: [snip] > You think the "bright line" which has yet to be drawn is not far from > the theory articulated in lotus an lexmark? That's... a fairly murky > way of thinking...
I think that a "bright line" could be drawn substantially at the boundary between public interface and implementation internals, as the cited cases did in the case of menus and macro languages (Lotus) and pluggable hardware components (Lexmark). The definition of "interface" is going to vary from language to language, but that's what expert witnesses are for. In many cases, industry practice is so well understood that there isn't much room for those expert witnesses to disagree anyway. 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? > > 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. > 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? > > The various cases I have cited are mostly competitive situations > > (creation of interoperable substitutes), and older precedents on > > interface usage from the telecom industry usually hinge on contract > > terms and trade secret status rather than on copyrightability. > > Agreed. > > > Personally, I think that the FSF is swimming upriver when it claims > > that any of the steps involved in implementing and linking against a > > library creates a derivative work. > > You're swimming up the same river when you claim that a binary is a > derivative work of the source. I don't think so. Courts have ruled that the expressive content in the binary is substantially the same as that in (the non-comment portions of) the source code. The fact that the translation can be somewhat lossy doesn't bother them. There's nothing in the source/binary scenario equivalent to the separation between library and PEOTL that can be achieved by denying copyright protection to their interface. Unless, that is, you're concerned that a binary may be a derivative work of the compiler as well; the bright line may be harder to draw there (consider the continuum from an x86 assembler to a C compiler to a Python bytecode compiler + runtime to a compiler for a "little language" implemented entirely in Lisp). That's a job for explicit language in the compiler license. > > 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. > > 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. > > 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? Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
