Re: Illustrating JVM bindings
On Fri, Jan 28, 2005 at 12:47:21PM -0800, Josh Triplett wrote: Good luck proving your replacement isn't a derived work after you've studied the GPLed work you are replacing. Actually, he has a point there. There has to be significantly more going on than read the GPLed work for some other work to be a derived work. Remember: copyright protects creative expression, not functionality. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
I'll respond to most of this later (I'll be traveling for a few days), but I just had to say: How is the technical issue of your inability to build a piece of software on a particular proprietary OS remotely relevant? The license certainly doesn't stop you from doing so. I'm on an older MacOS (10.2.x), various prerequisites for the current fink GIMP package don't seem to build with the toolchain available for that edition, and I'm disinclined to harass the maintainers or shell out for an otherwise needless upgrade to a proprietary OS just to bypass this issue. I prefer to use Debian when I can because it Sucks Less (TM), and I think this is a valid example of Free Software cutting off its nose to spite its face. Forget the legalities for a moment. Why don't you think it's legitimate for a maker of camera-related software to protect its investment in the extremely tedious process of calibrating against various lenses, which results in information that if published they could not protect from freeloaders by any other means, by keeping that one fragment closed source while contributing to the usefulness (and probably even the extent) of the GPL commons? Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Wed, 26 Jan 2005 12:33:35 -0800, Josh Triplett [EMAIL PROTECTED] wrote: Michael K. Edwards wrote: [snip] Of course it is possible for proprietary software to compete with free software without employing GPL components. It's also possible for one commercial spreadsheet to compete with another without providing a compatible menu and macro interface. And it's possible for a software game engine to compete with a hardware game console without providing an emulation capacity for existing games. The latter two cases are in no way related to the first. In neither of the latter two cases did the new competitor's software utilize the old software in any way, and no one here is arguing that you cannot write a proprietary replacement for GPLed functionality. If the public benefit of interoperability outweighs the harm done to a copyright holder by permitting competitive use of the interface they created, how can it not outweigh the harm to him of permitting cooperative use? You can argue that there's a completely different kind of public benefit that would result from giving free software a special status, but you're going to find limited legal precedent for that view. In any case, the argument from free speech principles doesn't reduce the applicability of these precedents with regard to the copyright holder's economic interests. But just as Lotus customers had already invested in learning menus and creating macros, and Sony PlayStation users had already invested in game titles, many MySQL users (for instance) have invested in developing MySQL-bound applications and the knowledge required to use MySQL well. Had the Progress Software v. MySQL litigation proceeded far enough, I think it is no stretch to argue that MySQL's attempt to use the copyright monopoly to obstruct Progress's efforts to reach their customers would and should have foundered on the rocks of precedent and equity. I strongly disagree. No one is arguing that you should not be able to develop a proprietary program with equivalent functionality to a GPLed program. The issue concerns the ability to build upon the actual GPLed program in order to provide that functionality. So Sony should have attacked Connectix, not for emulating the PlayStation's interface in order to compete with it, but for building on customers' access to Sony-authored games to make their emulator useful? Or perhaps Sega should have fought Accolade, not for copyright infringement in the course of reverse engineering to create games for the Sega console, but for interfering with Sega's ability to engage in social engineering within the Sega-game-author community? Fortunately for us all, engineering reality tilts the playing field in favor of componentization; where there are interchangeable components, there are opportunities to find new uses for those components, some of which may compete with their originators' interests; and courts properly frown on the abuse of the copyright monopoly to block this competition. There's a legal device designed to control the terms, not merely of copying, but of use; it's called a patent, and (in theory) requires a much greater showing of originality. The same goes for libraries used in desktop applications. Suppose I trust, say, Intuit to do a competent job on a small business accounting application, and would prefer to run it on GNU/Linux rather than one of those other operating systems. If disallowing them from linking to GPL libraries shared with free applications makes their software needlessly expensive in development cost and memory footprint, then I have a legitimate interest in restrictions on the GPL's reach. That's the *point* of the GPL: to create a set of software available for use by GPLed applications, giving those applications an advantage. If GPLed components make it easier to develop Free Software applications (which you inaccurately describe above as making it more difficult to develop proprietary applications), then that's a good thing for Free Software. rant That may be the point of the GPL in some people's eyes, but it ain't there in the text, unless you're relying on the afterthought about the LGPL. The major point of the GPL is to keep free software free. A Balkanized licensing landscape, with most reusable components under temporarily neutered version of the GPL or totally unrelated and sometimes incompatible licenses, doesn't serve that goal. Nor does it make it easier to develop Free Software applications that work well. And it certainly does make it more difficult to develop proprietary applications that can coexist with free software applications on a GNU/Linux system without massive bloat. I can't even run KMail, OpenOffice, and Firefox on the same system without getting nailed for triple the memory footprint (and triple the bugs) in code that provides 95% identical functionality -- let alone, say, Komodo or Acrobat Reader.
Re: Illustrating JVM bindings
On Thu, Jan 27, 2005 at 02:18:48PM -0800, Michael K. Edwards wrote: If the public benefit of interoperability outweighs the harm done to a copyright holder by permitting competitive use of the interface they created, how can it not outweigh the harm to him of permitting cooperative use? Why assume that interoperability is the only benefit from release under copyleft? For example, there's issues like more eyes on the code, easier to make derived works, and enabling literacy. And then there's the whole area of increasing the market for some related product (for example: the hardware which runs the free code, or the training services to help people use the free code more effectively, or the consulting services to help businesses use the free code to improve their processes, or ...). For that matter, what makes you think that competitive use of the interface is being disallowed? Near as I can tell, the only thing being disallowed is use of the implementation and that's only being disallowed in circumstances where the competing use won't comply with the copyright on that implementation. You can argue that there's a completely different kind of public benefit that would result from giving free software a special status, but you're going to find limited legal precedent for that view. Why bring in a special status as an issue? Free software exists under current copyright law. In any case, the argument from free speech principles doesn't reduce the applicability of these precedents with regard to the copyright holder's economic interests. Sure, just keep in mind that free software copyright holders also have valid economic interests. I strongly disagree. No one is arguing that you should not be able to develop a proprietary program with equivalent functionality to a GPLed program. The issue concerns the ability to build upon the actual GPLed program in order to provide that functionality. So Sony should have attacked Connectix, not for emulating the PlayStation's interface in order to compete with it, but for building on customers' access to Sony-authored games to make their emulator useful? The PlayStation is GPLed? Connectix is GPLed? Connectix used Sony's copyrighted code (what was on the other side of the interface)? Unless the answers to one of these questions is yes, you're talking about irrelevancies. Or perhaps Sega should have fought Accolade, not for copyright infringement in the course of reverse engineering to create games for the Sega console, but for interfering with Sega's ability to engage in social engineering within the Sega-game-author community? Irrelevant, again. Fortunately for us all, engineering reality tilts the playing field in favor of componentization; where there are interchangeable components, there are opportunities to find new uses for those components, some of which may compete with their originators' interests; and courts properly frown on the abuse of the copyright monopoly to block this competition. There's a legal device designed to control the terms, not merely of copying, but of use; it's called a patent, and (in theory) requires a much greater showing of originality. You present a convincing case that contributory infringement is likely to be limited in scope. But that's not the same thing as distributing copies of the code behind the interface. rant ... /rant I am, in fact, opposed to the idea that unlimited reach for copyleft is desirable. I don't really care whether the software inside my microwave oven is Free. I do want my government and my cellphone to run on Free Software, and neither will happen in my lifetime if there isn't a commercially viable transition strategy. Don't expect the license to be changed to make it easier for past problems to resurface. Last I checked, some people were arguing against the legitimacy of running Eclipse on Kaffe because this alternate implementation of the JVM interface happens to expose the inconsistency of the linking creates a derivative work stance. What, this would be a smaller problem if the first JVM implementation were GPL'd? As it happens, that's not the case, and probably would never have been the case. On the other hand, it would be plausible to have released the first JVM under LGPL. Use of words like abuse and tricksy to describe copyleft sound about as convincing as those who attempt to label the GPL viral. Courts and respectable commentators do use phrases like abuse (or misuse) of copyright monopoly to describe the conduct of plaintiffs who knowingly push the limits of copyright protection for anti-competitive purposes. Hint: Google for abuse copyright monopoly Lexmark. This is not at all the same thing as the GPL. In Lexmark, the copyrighted material in question served the role of a key in a lock, and was not a work of art or science in any other respect. Agreed. But as I have repeated ad nauseam elsewhere, I am not
Re: Illustrating JVM bindings
On Thu, Jan 27, 2005 at 02:18:48PM -0800, Michael K. Edwards wrote: I do want my government and my cellphone to run on Free Software, and neither will happen in my lifetime if there isn't a commercially viable transition strategy. If you want to work towards a situation where everything is available under a compatible license, consider a project oriented approach: pick a license and put together a project where everything distributed by that project is available under that license or under compatible terms. There are a number of ramifications to this, but I'm not sure if you're interested enough to spend time on them. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
Why assume that interoperability is the only benefit from release under copyleft? On Thu, Jan 27, 2005 at 07:45:29PM -0800, Michael K. Edwards wrote: I'm not assuming that. I'm saying that the public benefit of interoperability, used in a number of the decisions that I've cited to justify permitting competitive use of an interface, is even stronger when the factual situation involves cooperative use. Ok, but unless you take all benefits into account, you don't have a coherent the benefits are better reason for changing the license. For example, there's issues like more eyes on the code, easier to make derived works, and enabling literacy. All of which I agree with. The GPL is a good thing. I would like to see all of the code in the commons under the GPL. I would like to see lots more code gifted from commercial software vendors into that commons. I believe that the FSF's attitude on the GPL and linking boundaries is the biggest obstacle to these goals. I'm dubious, at least for now. And then there's the whole area of increasing the market for some related product (for example: the hardware which runs the free code, or the training services to help people use the free code more effectively, or the consulting services to help businesses use the free code to improve their processes, or ...). Yes, and I've made (part of) my living for the last decade or more, on and off, doing all of the above. One of the BSD projects? None of these benefits go away when the closed-application/GPL-library scenario is also permitted. It's pretty clear to me that the easier to make derived works does tend to go away with BSD style licenses. I'm not convinced that a GPL modified to be more like BSD license would not suffer the same class of problem, over time. It's very obviously the case that those closed-application licenses do not offer GPL's public benefits. For that matter, what makes you think that competitive use of the interface is being disallowed? Near as I can tell, the only thing being disallowed is use of the implementation and that's only being disallowed in circumstances where the competing use won't comply with the copyright on that implementation. Replace won't comply with the copyright on that implementation with won't comply with the FSF's interpretation, poorly supported if at all by case law in any jurisdiction, of the power of the GPL to leverage the copyright monopoly to dictate the licensing terms of software that uses that implementation and we agree. I'm not convinced that your interpetation is correct. Your reasoning is based on precedents which do not involve the copying of any copyrighted material, and on rigidly mechanical logic for how this relates to the applicability of the GPL's terms. Copyright law is not that rigid, so I don't think your logic holds. You can argue that there's a completely different kind of public benefit that would result from giving free software a special status, but you're going to find limited legal precedent for that view. Why bring in a special status as an issue? Because that's what one is arguing for when one argues that a free software license ought to be able to reach across an interface boundary even if case law says that copyright itself can't. I think you've totally misunderstood the concept of what a derivative work is. http://www.copyright.gov/circs/circ14.html In other words, your assertion here is simply meaningless. Interface boundary is a mechanical issue -- one of the facts relating to the composition of the work -- which may or may not be relevant to whether copyright applies in any specific case. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Wed, Jan 26, 2005 at 09:38:19AM -0500, Raul Miller wrote: 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? Or, better yet, include a statement of intent -- a description of what is meant to be protected and what is not. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
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
Re: Illustrating JVM bindings
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. ATT'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
Re: Illustrating JVM bindings
On Wed, Jan 26, 2005 at 03:09:58PM -0800, Michael K. Edwards wrote: Great. Except either this interpretation isn't part of the contract, and therefore doesn't bind other contributors, or else I've created another little almost-GPL fiefdom, and any bit of code that turns out to have been copied from another project with a non-matching GPL exemption gives the copyright holder leverage to sue me with the FSF's help. This is clearly well intentioned, but it's no substitute for a solid legal precedent or a change of heart from the FSF. You can't please everyone all of the time. Alternatively: I don't understand your agenda. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Tue, Jan 25, 2005 at 01:41:02PM -0800, Michael K. Edwards wrote: I'm focusing on a simple case. Pre-existing GPL library, shipped unaltered, or with any bug fixes and enhancements contributed upstream. New application (PEOTL) written to use the library. Tested and shipped together, with no tricksy business to pretend that the application isn't dependent in an engineering sense on the library. Intent: to exploit the market for the application, and to save on engineering cost by not reinventing the wheel contained in the library. Written to use the library, in the simple case, with no trickery involved, means that you are incorporating a modified form of some of the copyrighted code of that library. In the typical case, this would be anything covered by copyright that has to be included when compiling the combined work. Simple legal question: can a GPL library author use the copyright monopoly to ban the vendor from writing, or the end user from running, a closed-source application that uses the library through its published interface? Simplisticly, that depends on on the nature of the published interface. Equally simple ethical question: does releasing code under the GPL create a commons or a commune? That depends on perspective, and intent. Can one choose to share of and share in a pool of competent solutions to well-understood programming problems, without abandoning conventional mechanisms for recouping capital investment in novel creations? In the general case, yes. In specific cases, there might be specific details that make the consequences of such choices easier or harder to deal with than in other specific cases. In particular, you can't incorporate copyrighted concrete expressions of those solutions without paying the price set by the copyright holder. That is, after all, the conventional mechanism for recouping capital investment in novel creations. I think this falls under fair use. The program in the printer cartridge was tiny, and if Lexmark really wanted copyright protection on that program, they shot themselves in the foot by making its checksum a functional issue. The interesting part of the ruling, to me, was that the court didn't use a fair use theory to reach the conclusion they did. The problem with fair use is precisely that it depends on the circumstances and intention of the use; it's an affirmative defense of the behavior, not a property of the material being used. So it's pretty easy for a copyright holder to get a fresh hearing in court based on a new incident of use of the same material. Ok, ignore the first sentence of that paragraph then. The Lexmark court, like the Lotus court, ruled instead that, when prima facie copyrightable material is actually necessary for functional interoperability, it loses eligibility for copyright protection. If this precedent holds, we can stop counting the angels dancing atop an exec() boundary. I don't think this generalization can be made to apply when the only thing that the copyrightable material is necessary for interoperability with is the copyrightable material in question. GPL. Correctly or not, I understood you to have said that having studied a GPL library's internals weakens one's case for being justified in writing a non-GPL application that uses it. Copyright doesn't and shouldn't work that way. I feel strongly that the ideas Ah, reading back, I think I see the problem. I wrote: The GPL intentionally removes the freedom to collaborators freedoms on collaborative works. I meant to write something like: The GPL intentionally removes the freedom to remove collaborators' rights to access and use collaborative works. In other words, it's designed to avoid people claiming full ownership and control over a body of work which they had only partial responsibility for creating. That is the kind of freedom the GPL removes, and I don't see that as a bad thing. But I think you're talking about the same thing from a different point of view. You're talking about someone's control over the part they did write. The GPL doesn't remove their freedom to control that part, by itself. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Tue, 25 Jan 2005 17:19:43 -0500, Raul Miller [EMAIL PROTECTED] wrote: On Tue, Jan 25, 2005 at 01:41:02PM -0800, Michael K. Edwards wrote: I'm focusing on a simple case. Pre-existing GPL library, shipped unaltered, or with any bug fixes and enhancements contributed upstream. New application (PEOTL) written to use the library. Tested and shipped together, with no tricksy business to pretend that the application isn't dependent in an engineering sense on the library. Intent: to exploit the market for the application, and to save on engineering cost by not reinventing the wheel contained in the library. Written to use the library, in the simple case, with no trickery involved, means that you are incorporating a modified form of some of the copyrighted code of that library. In the typical case, this would be anything covered by copyright that has to be included when compiling the combined work. The scope of copyright in external interfaces is the crux of the legal debate. I don't mean to claim that the bright line has yet been firmly drawn, identifying published interface definitions as intrinsically uncopyrightable portions of software works. I do think that's pretty close to industry practice, and not far from the theory articulated in Lotus and Lexmark. 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. 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. 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. 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. 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. 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. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
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
Re: Illustrating JVM bindings
On Thu, Jan 20, 2005 at 08:51:46PM -0800, Michael K. Edwards wrote: We seem to be talking past one another. Maybe it's just that I'm implicitly assuming a separation between library source code and program source code, and saying that the latter is only a derivative work of the former if it contains copyrightable material, which API calls are not. I don't think either of us means to get into a semantic debate about whether the phrase program source code ought to refer to the whole ball of wax. So I'll use program exclusive of the library, or PEOTL, instead. Except I'm holding that this kind of distinction is meaningless in the general case. To meaningfully dicuss this kind of things, you'll have to nail down other details. Intent matters, other activities matter, etc. For example, consider a case where I hire person A to write a propietary compiler. I run low on funds, so I hire person B to make a gcc library, then person C to upgrade that library to include some API features I want, then person D to merge the work of person A and person C. I then hire person E to publish the result. Just for fun, let's say that all this hiring happens in some random countries which haven't signed any of the copyright treaties. Also note that I've not bothered to specify who holds the copyrights on the works I contracted for -- all that matters is that these people don't hold copyright on the original gcc. Am I correct in reading this as agreement that the PEOTL is not a derivative work of the library? In the general case, no, I'm not agreeing. However, I do recognize that there can be specific cases where your generalization holds. And, the same thing goes for the code which uses the library -- if you need to distribute it, or modified forms of it, you still need to comply with the terms of its license. Let's assume that I wrote the PEOTL and intend to distribute it under the following license: You have the copyright holder's permission to use, copy, modify, and distributed modified copies of this code, in source code or binary form, and to relicense the result to others under terms of your choice, as long as everyone pets a cat. This is GPL-incompatible in the sense that a derivative work of both GPL and pet-a-cat code is undistributable. I think a court would treat this as frivolous. For example, if the precedent of lotus v. bourland were relevant in a context where you were distributing the library as a whole, that would be tantamount to saying that the library as a whole was not copyrightable because it was purely functional in nature. While that would be a rather interesting and perhaps exciting development for computer software professionals, I don't believe that's a likely ruling in a copyright infringement case. That's actually very nearly the substance of the Lexmark ruling, given the additional fact that an SHA-1 checksum of the program in the printer cartridge was used by the printer as a lock-out code to reject non-Lexmark cartridges. Lexmark was trying to use the copyright monopoly to criminalize the creation of interoperable cartridges; instead, the appeals court ruled that they gave their entire program a functional aspect and rendered it uncopyrightable. I think this falls under fair use. The program in the printer cartridge was tiny, and if Lexmark really wanted copyright protection on that program, they shot themselves in the foot by making its checksum a functional issue. But this doesn't generalize to all libraries in all circumstances. It doesn't even generalize to all firmware (though I do see it as weakening software protection on firmware). That's not where I was going, though; I was saying that the PEOTL doesn't infringe the library's copyright. But the PEOTL+library combination, like any collection of things containing the library, does constitute copying in the legal sense. If I don't have a license to copy the library, or if I had one and it was rescinded, then I'm infringing its copyright. So far so good? No, not in the general case. Since the GPL restricts distribution of itself at violation time, this idea of function isn't copyrightable isn't going to solve all the problems faced by someone violating the GPL. I don't understand this sentence. Perhaps you are trying to say that for A to study a GPL library to understand how it works, and then write non-plagiarized, non-GPL code that uses it correctly, causes A's GPL rights to self-destruct, even if it is not true that under copyright law the non-GPL code is a derivative work. That's not in the GPL that I've read, and if it were -- this is freedom? That's hypothetical situation is rather narrowly focussed away from the typical cases I was trying to address. You don't seem to be asking me about what I meant to say -- instead you seem to be asking me about philosophy or something. If you have a question about what
Re: Illustrating JVM bindings
On Thu, 20 Jan 2005 11:53:37 -0500, Raul Miller [EMAIL PROTECTED] wrote: [snip] I'd say this differently. The program is not a derivative work of the library if it was written without any of the relevant copyrighted material of that library. No, it's not a derivative work if it was written without _copying_ any of the relevant copyrighted material _into_ the program source code. It's OK to inspect the library source code, comprehend it, experiment with it, work out what undocumented call sequence actually works instead of something equally plausible but wrong, and generally to write a program that wouldn't work without the library and couldn't have been written without reference to its internals. You just can't cut-and-paste, or even plagiarize in another language, expressive content that could equally well have been written differently without losing interoperability. A published functional interface is a easily recongizable and legit way for a program to be written so that the program uses the library even though the program was written without using the library. Here, there's other material under a different copyright (the spec [obviously], but also the library headers and a library implementation). I think you and I are using published differently. You're assuming that it's a standalone specification, probably with multiple independent implementations, with fairly explicit permission to code against it. I just mean published in a copyright sense, so that one doesn't have to deal with trade secrets, fair use reverse engineering, and clean-room standards. The notion of having to get the job done without peeking at the internals just doesn't apply to published source code. [snip] It's probably worth noting that Borland did this without using any lotus library (or headers, and probably without reference to any formal specification), and they certainly weren't being sued for using any such library inappropriately. Actually, they were being sued primarily because copying the menu interface went along with copying the macro language, and both helped users migrate from 1-2-3 to Quattro Pro. So they were being sued for reimplementing a functional interface, part of whose function was very much like a library API. Interestingly, the Supremes appear at first glance to have biffed on the certioriari proceeding (appeal from the First Circuit) for Lotus v. Borland. Justice Stevens was recused or out sick or something, the remaining justices split 4-4, and the cert. result in its entirety is: The judgment of the United States Court of Appeals for the First Circuit is affirmed by an equally divided Court. The transcript of oral arguments ( http://www.panix.com/~jesse/lotus_transcript.html ) tells a clearer story. Judging from the transcript, Borland would have been at more risk of losing on the menu interface (because its layout was arguably copyrightable and could be substantially varied without failing to express the idea) if they hadn't also copied the macro interface. The social benefit of portability of users' macro files appears to have weighed heavily with several justices. Lotus v. Borland hasn't been adopted systematically by other circuits; Lexmark is the only other case I've run across that cites it. That's not too surprising given the borderline certioriari. But the trend towards protecting interoperability seems pretty clear, especially when one is trying not to supplant an existing product but to interoperate from the other side of the interface. Since the GPL restricts distribution of itself at violation time, this idea of function isn't copyrightable isn't going to solve all the problems faced by someone violating the GPL. I don't understand this sentence. Perhaps you are trying to say that for A to study a GPL library to understand how it works, and then write non-plagiarized, non-GPL code that uses it correctly, causes A's GPL rights to self-destruct, even if it is not true that under copyright law the non-GPL code is a derivative work. That's not in the GPL that I've read, and if it were -- this is freedom? Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
Grzegorz B. Prokopski [EMAIL PROTECTED] writes: Your implementation creates a huge loophole in GPL, that I do not believe is there. Let's continue your way of seeing interepter features and see what would be the consequences. An example. I am writing an app. A GPL-incompatible or even closed-source one. I'd love to use this conservative garbage collector library, but it's under GPL, so I cannot. I'd also love to use libreadline, but I can't - for it's GPL. According to what you've just said it would be enough to create own intermediate langauge, and an interpreter that according to its own specification should handle garbage collection and provide readline-like functionality. I would then just take the GPLed code of this GC library, GPLed code of readline, cut out the pieces I need, integrate into my interepreter and call it interepter features. Thus, according to you, my GPL-incompatible program would be able to use GPLed code thanks to the simple virtue of my program being interepted. Yes. Well, you have to distribute the interpreter for this new language of yours under the GPL. So the GPL isn't useless. And your proprietary program then must use the interpreter. But, for example, I *have* such an interpreter -- for the language Python. I have many non-GPL'd scripts for it, even though the Python I use incorporates GNU Readline. -Brian -- Brian Sniffen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
Grzegorz B. Prokopski wrote: I would then just take the GPLed code of this GC library, GPLed code of readline, cut out the pieces I need, integrate into my interepreter and call it interepter features. Thus, according to you, my GPL-incompatible program would be able to use GPLed code thanks to the simple virtue of my program being interepted. Voila! GPL is uselless. GNU Bash (which uses readline) makes GPL useless because it doesn't force all bash scripts to be GPLd? Wow. I'm sure the FSF will appreciate your insight on GNU Bash and the usefulness of the GPL :) Looking through the bash documentation, I can find no statement from the FSF that says 'all your scripts are belong to GPL' or an exception for non-GPLd scripts. I think your reasoning about a hole in the GPL is deeply flawed. The GPL works as it should, it just doesn't work like a click-wrap non-free license, like you think it does, and would presumably like it to do. It would truely be useless if it did work the way you think it does, as then the GPL would not be DFSG-free. There exists java.lang.System.mapLibraryName() pure java method. This method calls java.lang.NativeLibrary.getLibPrefix() and java.lang.NativeLibrary.getLibSuffix() methods, but they are NATIVE methods, and are implemented by ./libraries/clib/native/NativeLibrary.c file, which is part of kaffe, and therefore available under the GPL. Those libraries are *a part of the GPLd interpreter*, so they can not magically let the interpreter impose the GPL on its input. Therefore only the second case mentioned in the FSF FAQ applies. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism. There is no contradition between the first part of FSF's statement about a GPLd intepreter not being able to restrict its input and this part. The part you quote is not about the interpreter, it is about *other* facilities that are bound to interpreted data. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Fri, 14 Jan 2005 22:12:56 +, Andrew Suffield [EMAIL PROTECTED] wrote: [snip] Some of those python scripts may be derivatives of GNU readline. Most are probably not. Those that are must be licensed under the GPL. The rest do not have to be. All this interpreter crud in between is *irrelevant*. If the same program written in C would be a derivative then it's still a derivative even when you insert an interpreter in the middle. I agree completely with Andrew here. I also think that linking crud is every bit as irrelevant as interpreter crud. Plagiarize the expressive content of code, you've created a derivative work. Hence, when I ripped out the internals of a GPL RSA implementation that used a bignum library that turned out to be non-free, replacing every line of the code with implementation against a different (free) bignum, the result was infringing not because it had the same API (that's functional, and hence not protectable under copyright) but because I retained not just the ideas but the style and flow of the original. (It's released as GPL, of course.) But a separate work using that implementation, whether bound to an interpreted OCaml interface, the same OCaml interface compiled to bytecode or native code, a dynamically linked C interface, a statically linked C interface, or a hypothetical template-based C++ interface that flows everything together in the preprocessing stage, just isn't a derivative work under copyright law. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Thu, 2005-13-01 at 23:42 -0500, Brian Thomas Sniffen wrote: Grzegorz B. Prokopski [EMAIL PROTECTED] writes: These facilities include class loading, class instantiation, synchronization, garbage collection (ie. you can trigger GC from within your program), reflection (ie. you can ask VM what are methods that this class have?). Those are features of the interpreter. The fact that the interpreter happens to be written in C as well as in Java doesn't matter here. This is what I meant about you leaning too much on your knowledge of how JVMs tend to be built. But everything you've listed here is an accident of the implementation of the JVM. It is not possible to have a JVM w/o these facilities. Now, the FAQ says: However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. What the FAQ is talking about is, for example, using JNI to access GNU Readline or GMP from a Java program using JNI. That is, it's pointing out that if you want to use the GPL'd Readline library, your application program must be distributed under the terms of the GPL. I'm not convinced the JVM does, but I suspect it's the case without the OS exception (which, of course, Debian can't use). Your implementation creates a huge loophole in GPL, that I do not believe is there. Let's continue your way of seeing interepter features and see what would be the consequences. An example. I am writing an app. A GPL-incompatible or even closed-source one. I'd love to use this conservative garbage collector library, but it's under GPL, so I cannot. I'd also love to use libreadline, but I can't - for it's GPL. According to what you've just said it would be enough to create own intermediate langauge, and an interpreter that according to its own specification should handle garbage collection and provide readline-like functionality. I would then just take the GPLed code of this GC library, GPLed code of readline, cut out the pieces I need, integrate into my interepreter and call it interepter features. Thus, according to you, my GPL-incompatible program would be able to use GPLed code thanks to the simple virtue of my program being interepted. Voila! GPL is uselless. You say I lean too much on my JVM knowledge. Let me show you another very short, but real example of why a JVM is not only an interpter, but also a library (example based on Kaffe code). There exists java.lang.System.mapLibraryName() pure java method. This method calls java.lang.NativeLibrary.getLibPrefix() and java.lang.NativeLibrary.getLibSuffix() methods, but they are NATIVE methods, and are implemented by ./libraries/clib/native/NativeLibrary.c file, which is part of kaffe, and therefore available under the GPL. What these two functions do has NOTHING to do with *interpreting* java bytecodes. These two happen to convert compile-time-defined C strings into java string and return them. And there is also plenty of such methods in whole JVM (I am not Kaffe expert, but I am sure Dalibor could show us more), which are exactly an additional functionality that has nothing to do with the interpretation of the bytecode. So let me just restate: To fullfill specification requirements a Java Virtual Machine provides additional bindings to functionality that is not part of the interpreter, but part of the JVM and its interface to java library. Therefore only the second case mentioned in the FSF FAQ applies. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism. Grzegorz B. Prokopski -- Grzegorz B. Prokopski [EMAIL PROTECTED] SableVM - Free, LGPL'ed Java VM http://sablevm.org Why SableVM ?!? http://sablevm.org/wiki/Features Debian GNU/Linux - the Free OS http://www.debian.org
Re: Illustrating JVM bindings
Grzegorz B. Prokopski [EMAIL PROTECTED] writes: Your implementation creates a huge loophole in GPL, that I do not believe is there. Let's continue your way of seeing interepter features and see what would be the consequences. An example. I am writing an app. A GPL-incompatible or even closed-source one. I'd love to use this conservative garbage collector library, but it's under GPL, so I cannot. I'd also love to use libreadline, but I can't - for it's GPL. According to what you've just said it would be enough to create own intermediate langauge, and an interpreter that according to its own specification should handle garbage collection and provide readline-like functionality. I would then just take the GPLed code of this GC library, GPLed code of readline, cut out the pieces I need, integrate into my interepreter and call it interepter features. Thus, according to you, my GPL-incompatible program would be able to use GPLed code thanks to the simple virtue of my program being interepted. Yes. Well, you have to distribute the interpreter for this new language of yours under the GPL. So the GPL isn't useless. And your proprietary program then must use the interpreter. But, for example, I *have* such an interpreter -- for the language Python. I have many non-GPL'd scripts for it, even though the Python I use incorporates GNU Readline. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Fri, Jan 14, 2005 at 04:42:44PM -0500, Brian Thomas Sniffen wrote: An example. I am writing an app. A GPL-incompatible or even closed-source one. I'd love to use this conservative garbage collector library, but it's under GPL, so I cannot. I'd also love to use libreadline, but I can't - for it's GPL. According to what you've just said it would be enough to create own intermediate langauge, and an interpreter that according to its own specification should handle garbage collection and provide readline-like functionality. I would then just take the GPLed code of this GC library, GPLed code of readline, cut out the pieces I need, integrate into my interepreter and call it interepter features. Thus, according to you, my GPL-incompatible program would be able to use GPLed code thanks to the simple virtue of my program being interepted. Yes. Well, you have to distribute the interpreter for this new language of yours under the GPL. So the GPL isn't useless. And your proprietary program then must use the interpreter. But, for example, I *have* such an interpreter -- for the language Python. I have many non-GPL'd scripts for it, even though the Python I use incorporates GNU Readline. Bwah, you're all *still* doing it! Some of those python scripts may be derivatives of GNU readline. Most are probably not. Those that are must be licensed under the GPL. The rest do not have to be. All this interpreter crud in between is *irrelevant*. If the same program written in C would be a derivative then it's still a derivative even when you insert an interpreter in the middle. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Illustrating JVM bindings
Grzegorz B. Prokopski wrote: I would then just take the GPLed code of this GC library, GPLed code of readline, cut out the pieces I need, integrate into my interepreter and call it interepter features. Thus, according to you, my GPL-incompatible program would be able to use GPLed code thanks to the simple virtue of my program being interepted. Voila! GPL is uselless. GNU Bash (which uses readline) makes GPL useless because it doesn't force all bash scripts to be GPLd? Wow. I'm sure the FSF will appreciate your insight on GNU Bash and the usefulness of the GPL :) Looking through the bash documentation, I can find no statement from the FSF that says 'all your scripts are belong to GPL' or an exception for non-GPLd scripts. I think your reasoning about a hole in the GPL is deeply flawed. The GPL works as it should, it just doesn't work like a click-wrap non-free license, like you think it does, and would presumably like it to do. It would truely be useless if it did work the way you think it does, as then the GPL would not be DFSG-free. There exists java.lang.System.mapLibraryName() pure java method. This method calls java.lang.NativeLibrary.getLibPrefix() and java.lang.NativeLibrary.getLibSuffix() methods, but they are NATIVE methods, and are implemented by ./libraries/clib/native/NativeLibrary.c file, which is part of kaffe, and therefore available under the GPL. Those libraries are *a part of the GPLd interpreter*, so they can not magically let the interpreter impose the GPL on its input. Therefore only the second case mentioned in the FSF FAQ applies. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism. There is no contradition between the first part of FSF's statement about a GPLd intepreter not being able to restrict its input and this part. The part you quote is not about the interpreter, it is about *other* facilities that are bound to interpreted data. cheers, dalibor topic
Re: Illustrating JVM bindings
On Fri, 14 Jan 2005 22:12:56 +, Andrew Suffield [EMAIL PROTECTED] wrote: [snip] Some of those python scripts may be derivatives of GNU readline. Most are probably not. Those that are must be licensed under the GPL. The rest do not have to be. All this interpreter crud in between is *irrelevant*. If the same program written in C would be a derivative then it's still a derivative even when you insert an interpreter in the middle. I agree completely with Andrew here. I also think that linking crud is every bit as irrelevant as interpreter crud. Plagiarize the expressive content of code, you've created a derivative work. Hence, when I ripped out the internals of a GPL RSA implementation that used a bignum library that turned out to be non-free, replacing every line of the code with implementation against a different (free) bignum, the result was infringing not because it had the same API (that's functional, and hence not protectable under copyright) but because I retained not just the ideas but the style and flow of the original. (It's released as GPL, of course.) But a separate work using that implementation, whether bound to an interpreted OCaml interface, the same OCaml interface compiled to bytecode or native code, a dynamically linked C interface, a statically linked C interface, or a hypothetical template-based C++ interface that flows everything together in the preprocessing stage, just isn't a derivative work under copyright law. Cheers, - Michael
Re: Illustrating JVM bindings
Is this relevant to Eclipse? I was under the impression that Eclipse was pure java -- that it did not use JNI at all. If Eclipse does use JNI, would still a question about whether or not Kaffe's JNI implementation constitute some kind of extension designed to work around the GPL or whether they are some kind of implementation of some Java standard. On Thu, Jan 13, 2005 at 06:33:20PM -0500, Grzegorz B. Prokopski wrote: I fail to see anything in the FAQ you cited above about extensions designed to _work around GPL_. Please refrain from creating meanings. I believe the GPL takes precedence over the FAQ. And, no, I will not restrict my use of the english language words to literal quotes taken from a FAQ. If I've provided too much meaning for you to deal with, I feel some mild regret at inflicting such agony on you, but not so much regret that I'll start posting nonsense. This is about the way Java works. You cannot merely interpret bytecode. Sure I can. I've done it. Mind you, I'm not very fast when I interpret bytecode logically, but that wasn't your claim. The program you're interpreting has to be able to call back into the JVM (or if you wish into a JNI library that is bound to a VM) to be able to run at all. http://google.com/search?q=define:jni When a java program uses JNI, you basically have to treat it as a non-java program, because it can use non-java facilities. However, a pure java program doesn't need to use JNI and the presence of JNI facilities in the interpreter is moot at that point. This case is typically simpler than the case of a non-java program, which is why JNI gets special mention -- so that the two cases aren't confused. Or is Eclipse 3.0 using only the facilities which Kaffe provides for arbitrary byte code? There is nothing in the FAQ that would suggest that these facilities have to be provided for a specific program. There is nothing in the FAQ to suggest that a GPLed JNI implementation has to be a problem for arbitrary code, though of course it does point out JNI as a issue that can be a problem. But for problem resolution, the FAQ is saying that certain things need to be released in a GPL-compatible way, not that no release can happen. It says if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. Indeed. But I question whether the phrase these facilities is at all relevant to this context. Until I have some reason to believe that it is relevant, I don't find discussion of the consequences of releasing these facilities to be very interesting. On the contrary. A Java Virtual Machine (Java interpreter) inevitably has to provide such bindings to support Java specification. In other words the interpreter itself has to be extended with a library that provides these bindings to support Java specs. There's plenty of these bindings required to exist in core java.lang.* classes. Hope this clarifies the issue, You seem to be claiming that a JVM has to provide non-standard JNI capabilities or it isn't a standard implementation of the JVM. I am sorry, but where do you see the non-standard is wrriten? I see it written two lines and five lines above this sentence. [You asked.] Now, if you'd have asked a relevant question I'd have made an effort to provide a relevant answer. But relevance has to do with concepts and ideas. A strong devotion to literal quotes won't get you there if you've abandoned the meaning of the material you're quoting. The only part that would suggest somethign like that is when the interpreter is extended to provide bindings to other facilities. Is that the part you're referring to? No. I'm talking about my understanding of the significance of various aspects of computer programming technology within the scope of my understanding of the GPL, as they relate to the context being discussed in that part of the FAQ. While I'm prepared to restate my ideas using different words, if my words are a problem for you, I'm not prepared to pretend ignorance where it doesn't exist. Likewise, I'm not really prepared to pretend that I know about something I don't know about. Finally, while I'm prepared to admit my mistakes, if they're pointed out to me (and I do make mistakes, at times), I'm not going to pretend that something other than literally quoting the FAQ is always a mistake. I am trying to explain, since the very beginning, that it is not possible for a Java interpreter not to provide these facilities that are being called by the program being interpreted. Therefore *every* JVM has to consists of an interpreter (be it JIT or ahead of time) extended with these callback functions. I know that's what you're trying to explain. What I don't see is any convincing reason to believe that you are correct. However, take heart -- I can be convinced. In fact, you're already
Re: Illustrating JVM bindings
Grzegorz B. Prokopski [EMAIL PROTECTED] writes: These facilities include class loading, class instantiation, synchronization, garbage collection (ie. you can trigger GC from within your program), reflection (ie. you can ask VM what are methods that this class have?). Those are features of the interpreter. The fact that the interpreter happens to be written in C as well as in Java doesn't matter here. This is what I meant about you leaning too much on your knowledge of how JVMs tend to be built. But everything you've listed here is an accident of the implementation of the JVM. It is not possible to have a JVM w/o these facilities. Now, the FAQ says: However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. What the FAQ is talking about is, for example, using JNI to access GNU Readline or GMP from a Java program using JNI. That is, it's pointing out that if you want to use the GPL'd Readline library, your application program must be distributed under the terms of the GPL. I'm not convinced the JVM does, but I suspect it's the case without the OS exception (which, of course, Debian can't use). -Brian -- Brian Sniffen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
Is this relevant to Eclipse? I was under the impression that Eclipse was pure java -- that it did not use JNI at all. If Eclipse does use JNI, would still a question about whether or not Kaffe's JNI implementation constitute some kind of extension designed to work around the GPL or whether they are some kind of implementation of some Java standard. On Thu, Jan 13, 2005 at 06:33:20PM -0500, Grzegorz B. Prokopski wrote: I fail to see anything in the FAQ you cited above about extensions designed to _work around GPL_. Please refrain from creating meanings. I believe the GPL takes precedence over the FAQ. And, no, I will not restrict my use of the english language words to literal quotes taken from a FAQ. If I've provided too much meaning for you to deal with, I feel some mild regret at inflicting such agony on you, but not so much regret that I'll start posting nonsense. This is about the way Java works. You cannot merely interpret bytecode. Sure I can. I've done it. Mind you, I'm not very fast when I interpret bytecode logically, but that wasn't your claim. The program you're interpreting has to be able to call back into the JVM (or if you wish into a JNI library that is bound to a VM) to be able to run at all. http://google.com/search?q=define:jni When a java program uses JNI, you basically have to treat it as a non-java program, because it can use non-java facilities. However, a pure java program doesn't need to use JNI and the presence of JNI facilities in the interpreter is moot at that point. This case is typically simpler than the case of a non-java program, which is why JNI gets special mention -- so that the two cases aren't confused. Or is Eclipse 3.0 using only the facilities which Kaffe provides for arbitrary byte code? There is nothing in the FAQ that would suggest that these facilities have to be provided for a specific program. There is nothing in the FAQ to suggest that a GPLed JNI implementation has to be a problem for arbitrary code, though of course it does point out JNI as a issue that can be a problem. But for problem resolution, the FAQ is saying that certain things need to be released in a GPL-compatible way, not that no release can happen. It says if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. Indeed. But I question whether the phrase these facilities is at all relevant to this context. Until I have some reason to believe that it is relevant, I don't find discussion of the consequences of releasing these facilities to be very interesting. On the contrary. A Java Virtual Machine (Java interpreter) inevitably has to provide such bindings to support Java specification. In other words the interpreter itself has to be extended with a library that provides these bindings to support Java specs. There's plenty of these bindings required to exist in core java.lang.* classes. Hope this clarifies the issue, You seem to be claiming that a JVM has to provide non-standard JNI capabilities or it isn't a standard implementation of the JVM. I am sorry, but where do you see the non-standard is wrriten? I see it written two lines and five lines above this sentence. [You asked.] Now, if you'd have asked a relevant question I'd have made an effort to provide a relevant answer. But relevance has to do with concepts and ideas. A strong devotion to literal quotes won't get you there if you've abandoned the meaning of the material you're quoting. The only part that would suggest somethign like that is when the interpreter is extended to provide bindings to other facilities. Is that the part you're referring to? No. I'm talking about my understanding of the significance of various aspects of computer programming technology within the scope of my understanding of the GPL, as they relate to the context being discussed in that part of the FAQ. While I'm prepared to restate my ideas using different words, if my words are a problem for you, I'm not prepared to pretend ignorance where it doesn't exist. Likewise, I'm not really prepared to pretend that I know about something I don't know about. Finally, while I'm prepared to admit my mistakes, if they're pointed out to me (and I do make mistakes, at times), I'm not going to pretend that something other than literally quoting the FAQ is always a mistake. I am trying to explain, since the very beginning, that it is not possible for a Java interpreter not to provide these facilities that are being called by the program being interpreted. Therefore *every* JVM has to consists of an interpreter (be it JIT or ahead of time) extended with these callback functions. I know that's what you're trying to explain. What I don't see is any convincing reason to believe that you are correct. However, take heart -- I can be convinced. In fact, you're already
