> 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...
On Tue, Jan 25, 2005 at 05:33:39PM -0800, Michael K. Edwards wrote: > 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). That's a functional issue. The cited cases were cases where copyright was held to not exist on the materials in question because they were functional materials instead of copyrightable materials. For cases where the interface definition is not protected by copyright, I'd agree with you. However, I doubt that this could be generalized to "all public interfaces". > 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. In lotus, the functional aspects of the interface were copied, but nothing else was. In lexmark, the same thing holds. Where the library itself is copyrighted under the same copyright as the interface, you have a different situation, with respect to copyright. It's not just the interface which is being copied, but the entire library. As an aside, "industry standard practice" as far as libraries go tends to fall into one of two categories: [a] The libraries are freely redistributable to everyone, with no restrictions whatsoever, or [b] The libraries are very heavily restricted with extremely high costs associated with each copy. The GPL doesn't precisely fit into either of those categories, and I don't see any reason why either form of industry practice should take precedence. > Encouraging competitive interoperation is a valid public policy goal, > pursued fairly consistently by the courts in the case law that I've > read. If the courts hold that all libraries are purely functional, despite their licensing terms, that could indeed be seen to satisfy a valid public policy goal. I don't think that's going to happen, however. > 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. And I think that for cases where that's all that's being copied, that it's likely that the courts would agree with you. However, I don't think that you can argue that this is a relevant precedent when the entire library is being copied. > What's murky about this way of thinking? The implications. And, thus, the semantics. > > > 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). Or the high-end-but-published camp. What Joel Spolsky calls the "Dear" price range. http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html > 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. It's unique in its price range, but it's hardly unique in its terms. Have you ever looked at some of the older AT&T Unix source licenses? > > 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? There's a paragraph at http://www.free-soft.org/literature/papers/gnu/pragmatic.html which mentions this issue. The NeXT is pretty much ancient history, at this point, but I'm sure that if you search around enough you'll be able to find more specifics. > > > 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. The modification issue I was referring to is only significant because the GPL contains more restrictions for the case where the GPL code is modified than for other cases. Copyright law is applicable to libraries when you're including a copy of the library. Or... are you trying to claim that a copyright license may not make non-copyright requirements? For example, would you say a license which requires the payment of money is invalid, since money is not copyrightable? > 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. I think you're confusing the requirements imposed by terms of the GPL with the issue of what is protected by those terms. > > > 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 Lotus case only involved copying of non-copyrighted material. Same holds for the Lexmark case. > > > 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. I see these issues as largely the same. > > > 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? Exceptions include: * Users of the GPLed software, * Developers of GPLed software who are not involved in commercial projects (education and government are two significant examples). * Developers of software who update the GPLed software either tangentially (they use GPLed tools, which they might enhance, but they get paid for something else) or complementary (superficially, the same, but increased distribution of the GPLed software increases the financial viability of their business). For example, many ommercial software projects use linux. In some cases they've gained a development platform. In other cases they've gained a deployment platform. In some cases (beowulf based rendering studios, maybe), they've might have gained access to a system qualitatively more powerful than what they'd be able to buy under the standard commercial model. Or, take my brother-in-law. He's a biophysicist who uses the linux real time kernel in his work. I talked him into using it after he'd spent a couple years using microsoft device drivers in the same basic context, and was stymed by some of the issues of that environment. He literally gained the ability to do research that he was unable to perform before he made the switch. I think you were trying to limit the universe of consideration to "commercial projects which make their money off the sale of software which would incorporate GPLed components if they could figure out how to make money off of it". My contention is that this is a relatively narrow slice of commercial projects, and of the use of GPLed software. You might also be trying to make the point that the "keep the software in-house" model doesn't contribute anything to the generally available body of work. But in a very similar sense, the "distribute the software under a proprietary license" doesn't advance the generally available body of work. So in that respect, as well, I think you're probably trying for a rather insignificant benefit. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
