> On Wed, 26 Jan 2005 09:38:19 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > > Because "all public interfaces" is too general a concept.
On Wed, Jan 26, 2005 at 03:03:57PM -0800, Michael K. Edwards wrote: > Too general for what? That is indeed a good question. Once we settle what it is that we're talking about, let's come back to it. > > > Doesn't the chain of reasoning, from Computer Associates to > > > Lotus to Lexmark, apply just as well to any other published interface? ... > > 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. You did, however, say that the GPL would not hold in such a circumstance, with the implication that this was because something was not copyrightable. > So let's lay this poor straw man to rest, OK? If by this poor straw man, you mean the chain of reasoning that says that interfaces may be reimplemented, sure. > > 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? Let's take A: the objective C front end, and B: gcc. Or, let's take the MagpieRSS and some commercial effort build on it. Or, let's take ghostscript, and some commercial effort built on it. [This last one is interesting, because it's also available under a different license -- and, in fact, the alternately licensed commercial version gets more immediate support than the GPL'd version.] > > > 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? Building and distributing modified versions of the GPLed program. > > 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? Not satisfying the GPL requirement that people who distribute modified copies of the program, in binary form, make available the source code for the work under appropriate terms. > > 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? They have to do with the nature of those of those interfaces -- in particular, they have to do with the distinction between the "Program" and a "work based on the Program". > > 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. I think that they include functional elements, but I don't think that the text is uncopyrightable. Only the functional elements are uncopyrightable. On the flip side, re-engineering those functional elements and then distributing the combined work (which includes the GPLed implementation) might very well be seen by the court as an attempt to sneak around the terms of the license. Or not... what a court will decide, and why, can be hard to predict -- especially in the general case. > > > 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? I'm not prepared to explain the mechanisms. I only observe that the commons has grown -- significantly. > > > 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? I'm not prepared to explain the benefits of Steve Jobs' motives. > 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. I'll agree that good working relationships might have been a deciding factor -- note that this is an agreement based on ignorance. I'm basically saying that I don't know all his motives and thoughts. > > > 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> I agree that the license says that copyright law is an issue. What I don't see is a statement claiming that copyright law is the only issue. In particular, the statement you've quoted indicates that the GPL does not try to restrict works which are not copyrighted works. In the context of Lexmark, the GPL is saying that it does not cover the functional aspects of the work, when they are taken alone. > 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? Sure, quoting from circular 14: To be copyrightable, a derivative work must be different enough from the original to be regarded as a 'new work' or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes. The new material must be original and copyrightable in itself. Titles, short phrases, and format, for example, are not copyrightable. And as examples of derivative works it includes things like Book of maps (based on public domain maps with some new maps) Drama about John Doe (based on the letters and journal entries of John Doe) Compilations and Abridgements (with a long footnote about cases where these contain new work of authorship, and several specific examples of Compilations and Abridgements). > <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? Sure. Are you claiming that combined works are not derivative works? > <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? Correct. Quoting from circular 14: The copyright in a derivative work covers only the additions, changes, or other new material appearing for the first time in the work. It does not extend to any preexisting material and does not imply a copyright in that material. > <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. I'm not claiming that it overrides the derivative-work-centric language, only that it illustrates what is meant by that language. > 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. That's exactly what I'm arguing. I'm arguing that the scope of copyright law would include cases of "mere aggregation" but that the GPL specifically indicates that those cases are not restricted. > 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 disagree. For example, programs (binaries) are qyite typically collective works. > [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? I think most GPLed code could be classified this way, after a few revisions. > 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. I think you're heavily into the area of opinion and personal value judgements here. I'm not prepared to measure the validity of such opinions. [developers] > > 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!" I think that the problem is much less, with the GPL written the way it is, than it would be otherwise. > > 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? http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish Though, granted, that's more about standards than implementations. However, a dearth of examples involving programs probably says something about the success of the GPL as a model. And, it is possible to find examples if we are willing to go back to before the GPL was firmly established [given what motivated RMS to write the GPL]. > > > > 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. Note that you could express this last sentence of yours as "So the no-link stance did not enrich any of these people in any significant sense, and hypothetically might have deprived them of potential income if this weren't an irrelevant issue." In any event, what you're calling the "linking ban" is based on something that's built into the copyright system. If you'd like to see it removed from copyright law altogether, feel free to lobby for those changes. > [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. You seem to be proposing that the solution, here, is to make it easier to release code which is not a part of that commons. Personally, I think that would increase what you're calling "Balkanization". > > 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. Legal precedents will never be perfect. > 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? This is the closest approximation available under copyright law. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
