License questions
Hi, There is some nice code here: http://www.scannedinavian.org/~pesco/ When asked about licensing, the author replied that he doesn't like licenses and refused to create one. But: pesco It's mine, but if you manage to get your hands on it, keep it for Christ's sake! ... Heffalump the key point is that we need documented and irrevocable consent to use and copy it. Heffalump I believe that This is in the public domain is sufficient for this, but CosmicRay seems to disagree. pesco Oh! Why didn't you say that. Of course you can copy it, feel free! ... pesco This is all mine! Take it and your soul shall be damned forever. But you can keep it and do with it whatever you want. Heffalump I think that's good enough. Heffalump unless damnation of souls is a violation of the social contract somehow. So, what do you all think? :-) -- 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: handling Mozilla with kid gloves [was: GUADEC report]
On Thu, 27 Jan 2005 02:12:58 + MJ Ray wrote: Mark Brown For what it's worth I'd noticed that the summaries had vanished - Francesco Poli So did I. Thanks for that You are welcome! :) and the comments off-list. What would the period summaries have done to help you with the Eclipse thread? Or did you mean the long licence summaries? Well, I was personally referring more to long license summaries than to period ones (how can I call them? debian-legal weekly news? ;-) What would they have done? When the summarizing practice seemed to be going to get established, I had the opportunity to skip long threads while learning their conclusions by reading the summary. Of course, it was a sort of emergency exit in case of lack of time to keep up with long and fast paced discussions. This solution wasn't obviously meant to replace my partecipation in list discussions: it was only useful when a) one thread growed above my following possibilities (due to lack of time) b) the topic was one I could not contribute much to (due to lack of knowledge and/or strong opinion) IF a AND b THEN discard_and_wait_for_summary := yes Please note that it was a *AND* b and not a *OR* b I would have probably behaved in such a way (discard and wait for a summary) with the Eclipse-related threads, if I could have hoped to actually see a summary... And, please, do not misunderstand me: I'm not in any way implying that such threads should not have taken place or that their topic was uninteresting. On the contrary, Java is an interesting language to me (even though I'm absolutely ignorant about it, which implies b) and trying to understand how licenses interact in the case of JVMs, JNI and Java programs was worth doing. Those threads have been a bit too long and flamy (that implies a), but I can understand that the reason is a strong disagreement between the opponents... Personally, I've been ignoring that thread because it's very large, I dislike Java and it didn't seem to be heading towards consensus yet. I have less time now, so I changed from period summaries, which are interesting statistics to me but not much practical use, to making notes that help me with a real problem: how do I answer when asked whether I think some software is free software? That is another important use of (long) license summaries. The first one is the emergency exit thing I explained above. The second one (not necessarily in order of importance!) is keeping track of past debian-legal discussions. Let me try to explain what I mean. When I find out some useful or interesting piece of software (i.e. program or documentation or music or ...), I try to determine its (DFSG-)freeness. Some cases are easy enough (e.g. Expat license with no strange inconsistencies), but life is seldom easy! :-( Thus having a collection of past discussion summaries *is* useful, IMHO. Moreover, when my conclusion is non-free! and still the software seems to be *very* useful, I try to approach its copyright holders and persuade them to change license. This is very difficult (I succeded in some cases, but more often failed...), since it requires diplomatic abilities. In order to be more credible when I point out the issues that makes a license non-free, I usually cite them briefly and then refer to some summaries and position statements (written by other people) for further details. I hope the copyright holder will read at least one of the bibliographic references and thus see that I am not the only one who thinks the license actually *has* problems. I think that referring to long threads full of legal technicalities (in absence of summaries) would not work at all. Rather, it would probably be counter-productive. Hence, I feel that summaries are useful. Do the long licence summaries do much besides fuelling the project red-top's debian-legal hate campaign? I think that the absence of summaries is even worse, because, I suppose, debian-legal hate campaigners are often not very interested in legal details: as a consequence, long (and difficult to follow) threads with no summarized conclusions would seem even more obscure and opaque to them. As soon as someone starts drafting one, it runs reports about -legal ruling on a licence. Successes are rarely reported, as good news is not news. Perhaps they don't undertand that moving a package to the section where it belongs (from the SC standpoint) *is* a success. Of course, it is surely better when a non-free package becomes free and stays in main (where it was erroneosly placed before the license change). Really, you're better off reading planetdebian if you want to know what's going on. Really? -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
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: Eclipse 3.0 Running ILLEGALY on Kaffe
Raul Miller [EMAIL PROTECTED] wrote: Section 2 is about the restrictions which come into play when you build a modified form of Kaffe, which is not the case for Eclipse. Eclipse involves no modifications of Kaffe. On Wed, Jan 26, 2005 at 09:50:17PM -0500, Walter Landry wrote: Debian modifies Kaffe and distributes Eclipse with it. If Debian did not modify Kaffe, then this section would not be relevant. First: There is no such legal entity as Debian which is doing such things. Debian is a trademark of SPI, and there are people who use that trademark, but that's not the same thing. You can replace Debian with SPI if it makes you feel better. I feel that you are quibbling about unimportant matters. Second, when a volunteer who associates with the name Debian modifies Kaffe, he or she does not modify it to include Eclipse. So the distribution of Kaffe proceeds unhindered. Third, when a volunteer who associates with the name Debian distributes Eclipse, this is under the terms of the Eclipse license, and this does not in any way violate the Kaffe license. Of course, if someone modified Kaffe to incorporte Eclipse, that would be a problem. To my knowledge, no one has done so, no one plans to do so, and no one is seriously presenting this as an issue. In other words: even if your sentence were legally accurate (which it isn't, given the legal status of Debian), it would still be irrelevant. The volunteers are agents of Debian. Once again, the only relations between Eclipse and Kaffe are Eclipse is aggregated with Kaffe and Eclipse is run by Kaffe. And once again, you miss the point that Eclipse and Kaffe together make a whole work. The make an aggregate work. However, this aggregate work is not the work which is made when Kaffe is modified. Debian distributes a modified Kaffe and Eclipse together. Section 2 of the GPL does not care whether the modifications made to Kaffe are for making Eclipse work better or not. In particular, you can't impost restrictions from Section 2 on cases where Sections 0 and 1 have already granted permissions. Not unless you want to make distribution under the GPL void (see Section 4 for why that is a requirement). Section 0 says that this license only affects copying and distribution, which is what is going on here. Section 0, when taken by itself (as you're doing here), only requires the inclusion of appropriate copyright notices. So we're satisfying that aspect of section 0. Section 1 gives permissions for distributing unmodified versions. Yes. I am talking about distributing modified versions of Kaffe (which Debian does). And we're satisfying the conditions required for the distribution of those modified versions. Those modified versions of Kaffe do not include Eclipse. There is an aggregate work which is also being distributed which includes both Kaffe and Eclipse, but the GPL allows that. They are not an aggregate work, they are a whole work. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Raul Miller [EMAIL PROTECTED] wrote: On Wed, Jan 26, 2005 at 09:53:03PM -0500, Walter Landry wrote: The GPL puts restrictions on whole works. True. Requires to run is a useful heuristic to determine what a whole work is. Kaffe does not require Eclipse to run. So by this heuristic, Eclipse is not a part of Kaffe. You missed the part about Eclipse requiring Kaffe to run. If you have a better heuristic, I am open to discussion. Requires to build. I have serious doubts that only the header files would become part of the complete work. Incorporates content from. That would be an ordinary derived work. As I mentioned, the GPL goes beyond derived works. Designed as part of. So if a GPL'd program can use GNU TLS or OpenSSL, we don't have to actually ship GNU TLS? Are you actually proposing that? I think that if we can agree on what a useful criteria is, then the rest of the discussion melts away. Regards, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
First: There is no such legal entity as Debian which is doing such things. Debian is a trademark of SPI, and there are people who use that trademark, but that's not the same thing. On Thu, Jan 27, 2005 at 09:55:30PM -0500, Walter Landry wrote: You can replace Debian with SPI if it makes you feel better. I feel that you are quibbling about unimportant matters. I'll agree that this is a tangential point. However, SPI has not modified Kaffe, and has no plans for doing so. Second, when a volunteer who associates with the name Debian modifies Kaffe, he or she does not modify it to include Eclipse. So the distribution of Kaffe proceeds unhindered. The volunteers are agents of Debian. Agent: One authorized to represent and to act on behalf of another person (called the principal). Unlike an employee, who merely works for a principal, an agent works in the place of a principal. The main difference between an agent and an employee is that the agent may bind his or her principal by contract, if within the scope of authority, whereas an employee may not unless given express authorization. (See law of agency, principal) The make an aggregate work. However, this aggregate work is not the work which is made when Kaffe is modified. Debian distributes a modified Kaffe and Eclipse together. Section 2 of the GPL does not care whether the modifications made to Kaffe are for making Eclipse work better or not. False. Section 2 specifically says The source code for a work means the preferred form of the work for making modifications to it. No one believes that Eclipse is a part of the preferred form of the work for making modifications to Kaffe. There is an aggregate work which is also being distributed which includes both Kaffe and Eclipse, but the GPL allows that. They are not an aggregate work, they are a whole work. That's easy to assert. What you are unable to do is provide any meaningful explanation of why your assertion is correct. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Kaffe does not require Eclipse to run. So by this heuristic, Eclipse is not a part of Kaffe. On Thu, Jan 27, 2005 at 09:56:34PM -0500, Walter Landry wrote: You missed the part about Eclipse requiring Kaffe to run. The license on Eclipse doesn't make an issue of this. The license on Kaffe explicitly says that running Kaffe is not restricted. So you have no plausible reason for believing that this matters. If you have a better heuristic, I am open to discussion. Requires to build. I have serious doubts that only the header files would become part of the complete work. Irrelevant, until you show some reason for this to matter in the specific case of Eclipse and Kaffe. Incorporates content from. That would be an ordinary derived work. As I mentioned, the GPL goes beyond derived works. Irrelevant, until you show some reason for this to matter in the specific case of Eclipse and Kaffe. Designed as part of. So if a GPL'd program can use GNU TLS or OpenSSL, we don't have to actually ship GNU TLS? Are you actually proposing that? I'm not discussing GNU TLS at the moment. I've not studied that issue. But I should note that I'm not claiming that any of these criteria should stand by themselves. I think that if we can agree on what a useful criteria is, then the rest of the discussion melts away. Ok, if we agree to avoid discussing how the issues relate to the license itself, but have some alternate agreement we hold in its place, we would be holding a different discussion. I don't disagree with this concept, I just think it's irrelevant. -- 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: Eclipse 3.0 Running ILLEGALY on Kaffe
Walter Landry wrote: Raul Miller [EMAIL PROTECTED] wrote: Once again, the only relations between Eclipse and Kaffe are Eclipse is aggregated with Kaffe and Eclipse is run by Kaffe. And once again, you miss the point that Eclipse and Kaffe together make a whole work. The make an aggregate work. However, this aggregate work is not the work which is made when Kaffe is modified. Debian distributes a modified Kaffe and Eclipse together. Section 2 of the GPL does not care whether the modifications made to Kaffe are for making Eclipse work better or not. What is the difference between the following cases? # Mr Foo packages Kaffe, making modifications to better integrate with Debian # Mr Foo distributes Kaffe' to Mr Bar, complying with the GPL (including Section 2) # Mr Bar distributes Kaffe' along with lots of GPL-incompatible java programs, which he wrote and compiled with Sun's JDK. Note that Kaffe' is completely unmodified. # Mr Foo packages Kaffe, making modifications to better integrate with Debian # Mr Foo distributes Kaffe' to Mr Bar, complying with the GPL (including Section 2) # Mr Bar distributes Kaffe' to Mr Foo, complying with the GPL. Note that Kaffe' is completely unmodified. # Mr Foo distributes Kaffe' along with lots of GPL-incompatible java programs, which he wrote and compiled with Sun's JDK. Note that Kaffe' is still completely unmodified. I assert that the GPL does case about the nature of the modifications, because at any point you can distribute a GPLed work to yourself. If the GPLed work is separate from other works under copyright law, it doesn't contaminate them at this point. If the other works are derivative (as they would probably be in the case where you modified the GPLed work to couple more tightly with the other works), then you have obligations under the GPL at this point to GPL them. In other words, modifications to the GPLed work that couple the GPL code to another work /may/ incorporate that work to the GPL's definition of 'a work based on the program'. If they do, then it /may/ not be lawful to distribute the GPLed work alongside the other work if the other work is licensed incompatibly. Modifications that do not couple the GPLed work have no effect on other works, because at any point you can distribute the GPLed code to yourself, to receive a new version that is unmodified for the purposes of section two. -- Lewis Jardine IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
