On Wed, 26 Jan 2005 09:38:19 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: [snip] > Because "all public interfaces" is too general a concept.
Too general for what? Not too general for the precedents and public policy imperatives to be applicable. Not too general to describe clearly. Not too general to expect expert witnesses to agree on which bits of a program are its public interface. > > Doesn't the chain of reasoning, from Computer Associates to > > Lotus to Lexmark, apply just as well to any other published interface? > > It's not that these plaintiffs weren't trying to copyright their > > interfaces, it's that the courts ruled that the necessity of > > duplicating them in order to interoperate warrants their exclusion > > from the portion of the work that is considered copyrightable > > expression. > > When I see MS Word or Powerpoint being distributed for free, because > they constitute functional implementations of publc interfaces, I'll > agree with you. I never said, and don't mean, that the implementation internals are not copyrightable. Perhaps you obtained this from my references to Lexmark, where the factual situation happened to be that the entire program was used as a lock-out code and so the entire binary was ruled uncopyrightable due to its functional aspect. But that's not the importance of the legal precedent from my point of view. I am interested in the criteria used to find which bits are functionally necessary, not the particular outcome of applying those criteria to the Lexmark facts. So let's lay this poor straw man to rest, OK? [snip] > The GPL coverse both derivative and collective works. I don't think > that a claim that <<in A+B, A is not a derivative of B>> is sufficient > in all cases. The GPL's hold on collective works turns out on inspection to be quite tenuous; see below. To the extent that they are mentioned at all, this mention weakens rather than strengthens a claim that most of the GPL is intended to cover them. > Of course, there are cases where A+B is a collective work, or a part > of a collective work, and the GPL's terms allow its distribution. > But equally obvious, that's something the GPL specifically allows, and > it doesn't provide a basis for generalizing this permission to other > cases which the GPL disallows. What "case which the GPL disallows" are you talking about? What relationship between A and B, other than sharing copyrightable material, is discussed in the text of the GPL? > > It is of course possible that a court won't go so far as to rule that > > a given published interface isn't copyrightable. But supposing that > > this generalization does hold, what grounds do you find in the GPL for > > retaliating against the commercial application vendor by denying it or > > its customers license to the library? > > It seems to me that you'd be engaged in activities where you need the > permissions described in the first sentence of section 2, but that you > would not be satisfying the associated conditions. What activities? > And I don't see the GPL denying its customers license. I do see grounds > to have the commercial vendor cease and desist from distributing the > library (whatever "distributing the library" means in that context). What grounds? [snip] > > I referenced "industry practice" to suggest a likely source of > > consensus about what constitutes an interface definition in any given > > technical context (header files for C libraries, interface definitions > > extractable from class files for Java, etc.). > > Note that these are very different cases. > > The interface definitions from class files for the system libraries > for Java are (if copyright applies) owned by Sun, and distributed under > their license. Authors of GPL'd java systems can't claim ownership of > that specific content. > > In the C universe, no such guarantee applies to system header files -- > they're system specific. What do these statements have to do with the question of which bit is the public interface? > > > 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. > > > > Hopefully it is clear by now that I think that: > > the bulk of a library is usually copyrightable; > > its published interface is arguably uncopyrightable according to > > US case law; > > permission to distribute it depends on the terms of its license; > > US courts are somewhat unlikely to enforce anticompetitive > > constraints in standard-form licenses; and > > anticompetitive constraints in the GPL are in any case limited by > > its language to the scope protectable by copyright? > > As stated, I agree with these statements. > > You also appear to think that where a GPLed work has functional > components, the license protecting the rest of the work no longer engages > when it the work is incorporated in a program which only modifies the > functional components. No, I don't think that. I think that the PEOTL and the library remain separate works for copyright purposes because the only text that they share is uncopyrightable. The fact that A was created using an understanding of the ideas in B and fragments of uncopyrightable text from B doesn't make A a derivative work of B, nor is there a plausible way of interpreting the phrase "mere aggregation" in the GPL's copyright-centric context to disallow A + B but permit B + a banana. [snip] > > Do you still think it's murky after clearing up the distinction > > between copyrightability of libraries and of their interfaces? > > I think I've focussed our point of disagreement to one > specific implication (that of scope). OK. So with the straw man gone, are we on the same page? > > OK, "unique" was an overstatement. But the FSF has an axe to grind > > that discomfits many decent people who would otherwise be willing to > > share in the maintenance and expansion of the commons. AT&T's > > attitude back in the day is an interesting parallel, given that it > > helped contribute to the decline of the original Unix commons. > > And the FSF's attitude has helped contribute to the subsequent growth > of the Unix commons. How? The FSF's activities have certainly contributed, and I am very happy to be a beneficiary of their efforts. But what aspect of the growth of GNU are you attributing to the "linking is forbidden" stance? > > > 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. > > > > Have you read anything about it other than RMS's summary? > > Yes, quite a bit, many years ago. Unfortunately, I didn't save the > material for this conversation. Fair enough. :) > > Is there > > any reason to think that NeXT or MCC didn't just decide that fighting > > the GCC team wasn't prudent? > > Yeah: we're talking about Steve Jobs. > > Take a look at some of the legal actions Steve Jobs has instigated. > As a general rule, he'll take things to court if that would mean gaining > control of something, and would only avoid taking things to court if he > thought he'd lose control. What possible use is "control" in a legal sense -- i. e., a court's blessing to go on shipping an Objective C compiler built on GCC without releasing its source code -- if continued engineering development becomes impossible due to the hostility of the GCC team? Steve Jobs may be a control freak, but he's not a complete idiot. You're imputing inhuman consistency to him and to the whole legal system if you think that the lack of an FSF v. NeXT in the appellate record proves that using a GPL library from a closed-source application can't be successfully defended in court. > > > 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? > > > > As I never seem to tire of repeating, a copyright license is a term in > > a contract and may be exchanged for any other legally valid promise. > > But the text of the GPL as written almost fetishizes the bounds of > > copyright in an attempt to persuade the reader that it is a pure > > artifact of copyright law. > > The FSF might make such expressions in philosophical articles, but > I don't see this in the GPL itself. > > > It's not so much that it can't attempt to > > fight on other turf, it's that it doesn't choose to. > > The only thing in the GPL which I see that might justify this statement is > the scope of protection thing -- where combined works are not restricted by > the GPL if they're not copyrighted works. > > But I don't see the sort of fine-grained "copyright law is the only issue" > logic which you seem to be arguing is present. <quote doc="GPL" clause="0"> ... a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. </quote> So no derivative work, no "work based on the Program". The attempt to clarify the term "derivative work" is imperfect, conflating collective works and leaving out various limitations on copyrightability; but it doesn't really matter because saying "derivative work under copyright law" incorporates the legal history by reference. Right? <quote doc="GPL" clause="2"> 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work ... </quote> So the scope of the modified work is limited to the "work based on the Program" and hence to the scope of the derivative work. Right? <quote doc="GPL" clause="2"> These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. </quote> So the scope of the "whole" is that of the "work based on the the Program", which is that of the derivative work. The obvious way to construe the intent of this clause is to say that one doesn't lose the right to use a code fragment elsewhere just because one has also contributed it to a modified GPL work. Right? <quote doc="GPL" clause="2"> Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. </quote> This is the only reference to "collective works" in the whole GPL. I think it's a stretch even to argue that it overrides the derivative-work-centric language that it precedes it. And in any case: <quote doc="GPL" clause="2"> In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. </quote> This nullifies any attempt to reach collective works, unless you try to argue that "mere aggregation" is defined via a standard totally unrelated to copyright law, in which the use of uncopyrightable interfaces and knowledge about B when creating A somehow makes A ineligible for mere aggregation with B. This is where the general copyright-centric tone of the license comes in; given that no attempt is made to define "mere aggregation", it would be absurd to construe it as extending to some collective works but not others. > > > I think you're confusing the requirements imposed by terms of the GPL > > > with the issue of what is protected by those terms. > > > > No, I'm pointing out that the "bright line" between interface and > > implementation inevitably gets fuzzy when one is looking not at > > libraries but at languages and toolchains, and therefore toolchain > > licenses should be fairly explicit about the ground rules for the use > > of their output. > > I have no disagreement here. But I think those rules need to be specified > on a per-tool basis (estoppel seems to be a frequently used mechanism > for dealing with this on a per-tool basis), and sometimes even a per-case > bases (section 10). ACK. [snip] > > What users of GPLed software have benefited by disallowing the use of > > GPLed libraries from non-GPL code? > > What software has been released under the GPL which combines with > other, pre-existing code which was only available under the GPL? Good question. Qt, maybe, but it's more a case of GPL applications using it than the other way around. Same with XForms, eventually. Arguably the development of decent free widget libraries would have taken even longer if the FSF hadn't militated against using Motif from GPL applications. Do you have other examples in mind? > > > * Developers of GPLed software who are not involved in commercial projects > > > (education and government are two significant examples). > > > > If they are not commercially motivated, what skin is it off their nose > > if there is a commercial alternative that also uses GPL components? > > If they're the authors of that GPLed code, they might care. For instance. OK, so you're arguing that some people only want to GPL their code if they are assured that the evil software hoarders and their misguided customers/victims will have to keep their grubby mitts off of it. Hey, I've felt that way at times too, and I'm willing to consider their preferences legitimate. But when a principal contributor to a rapidly evolving project takes that stance, no one in her right mind would build a commercial product atop it, whether or not the FSF takes their side. So the "library linking ban" doesn't really matter to full-on activists, either, unless they're relatively minor contributors attempting to sabotage a less radical stance held by the active maintainers. That opening for FSF-assisted sabotage is one big reason why the GPL isn't the natural license under which to release almost everything. > > How do they benefit from the lack of commercial involvement in the > > maintenance of the components on which they depend? > > It's commercial involvement that they likely benefit from -- more > specifically, commercial contributions to the GPLed code base. That's a good argument for the GPL's terms regarding derivative works, which have very demonstrably contributed to healthy evolution of GPL programs. To extend the argument to "contributions of applications that had to be GPL because they used GPL libraries", you're going to have to give me some examples. > Commercial decisions are made on economic terms, not philosophical terms. > The GPL plays a part in shaping those terms. Right. The great majority of the time, it discourages commercial participation in GPL projects. The big counterexamples -- GCC, the Linux kernel, MySQL -- are precisely those where there's a defensible boundary between contributed code and proprietary applications that use it. > This isn't "hostage taking" any more than [or any less than] charging > for distribution is "hostage taking". Not my phrase. I just don't see anyone benefiting. > > > * 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). > > > > Again, what do they gain from the linking ban? No one is arguing that > > it's OK not to release the source code for derivative works. > > They don't have to study the programs which use the GPLed code to > determine which parts they're allowed to use and which parts are off > limits. I don't understand this assertion. Are you saying that it's smart for users of a GPL component to borrow from any code that's floating around that contains calls to that component, trusting in the FSF's no-link stance to protect them from infringement claims? "You can't ticket me, officer -- my mom says that slipstreaming behind an 18-wheeler can't be speeding 'cause they have to obey the speed limit too!" > For complementary developers, they don't have to worry about some other > company snapping up their code and taking it off the market through some > kind of embrace and extend. I don't understand this one either. Whose code is getting "snapped up" and how, and what does the no-link stance have to do with it? > > > 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. > > > > Right. But if any of these use cases ran into the GPL linking ban, > > they'd be out of luck. As it is, they rely on Linus's perpetuation of > > the syscall fudge and on a belief that the exemptions in the glibc, > > gcc, and binutils licenses effectively protect them from the FSF. > > So? So the no-link stance isn't doing any of these people any good, and would in fact harm them if it weren't neutered. > > > 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. > > > > What does he gain from the linking ban? > > To the degree that the tools are available in a useful form from the > linking ban, he gained those tools. Other than that, nothing that I'm > aware of. What evidence is there that this degree exceeds zero? [snip] > > Suppose one could remove the barriers to merging good bits from all > > over the commons, retain the obligation to release the result under > > the GPL, but permit its use from a commercial application that sells > > on its other strengths. That might make it worth someone's while to > > do a really good job of analysis and refactoring. And in the process > > they might clean out their closet and toss lots of good bits into the > > commons that they don't consider to be core competencies but might > > want to reuse later. > > If you want to argue that specific case, I don't have any immediate > problems with it. I've not looked at the non-GPL copyrights any time > recently, and I need to get off the computer soon, so I'm not in a > position to say anything more in depth on this right now. > > But please don't try to overgeneralize this one case into something > that tries to apply to "everything". Beats over-generalizing zero cases. :-) But seriously, do I have to tell debian-legal that a huge amount of effort goes into limiting the harm done by the Balkanization of open source licensing terms? Under the circumstances, there are both legal and resource obstacles to the kind of systematic overhaul of the rest of the core libraries that the kernel, gcc, and parts of glibc have gotten in the last couple of years. This kind of work takes great skill but is rather tedious, so most people who are competent to do it would want to get paid for it. That's not going to happen if it creates a commune instead of a commons. [snip] > If I understand you correctly, you could address all your company's > concerns by licensing the headers and build files needed to compile your > libraries under BSD (or maybe LGPL) and license the rest of your content > under GPL. > > Or is there some other concern? As long as the legal precedents are imperfect and it is the FSF's declared intent to pursue copyright infringement across interface boundaries, it would be folly to accept any third-party contribution under the GPL, without copyright assignment, to a project that has any relationship to a proprietary code base. So, like the vast majority of working programmers even on GNU/Linux, I have to go on shoring up a mountain of crap instead of persuading my employers to focus on the few bits that genuinely make sense, at least for now, as proprietary components. This is freedom? Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
