Re: [kaffe] Re: kaffe's license
Jim Pick wrote: The GPL license is somewhat undefined in terms of how it interacts with other code. I'd somewhat disagree on that, in my opinion the GPL wisely defers to copyright law terminology for many things, rather than getting mired in specifics of yesterday's techniques for creation of derived works and/or trying to invent new terminology to go with it. It's a pretty nice, good read as far as software licenses go. See my blog for various critiques of badly written licenses. :) It's not a license I would have chosen for a virtual machine. Some people say if you run an application on top of the VM, you would have to make that application GPL-licensed too. Some people say that's nonsense (I tend to agree with that viewpoint). My impression is that the GPL works pretty well, and allows GPLd projects to easily integrate a lot of other, GPL-compatible software. I am actually pretty happy with it, I think it has worked quite well so far, as it sits on top of the licensing food chain. There is a great article by David A Wheeler at http://www.dwheeler.com/essays/gpl-compatible.html on the benefits of using the GPL and making code GPL compatible, so I am putting some of my energy into working with the Apache Software Foundation and the Free Software Foundation to help bridge the misunderstandings, and incompatibilities in their licenses. I've spent a lot of time discussing licensing in various venues, and the 'you must run only GPLd software on a GPLd interpreter' claim is invalid, for all I know about the GPL and copyright law. See FSF's FAQ on a GPLd interpreter for details.[1] As another explanation of why the claim is bogus, the freedom 0 of the Free Software definition gives anyone the freedom run a GPLd program for any purpose, even if the GPLd program is used for ethically questionable purposes, like designing death stars, hunting ewoks or running non-free software. To my knowledge, I'm not aware of any cases where somebody has been sued for running non-GPL code on a GPL'd virtual machine. It's not a common scenario. I think Transvirtual actually came to regret re-releasing the VM under the GPL, since they saw that people were actually using the GPL'd version for commercial developments, and were not coming to them for the proprietary version. I think Transvirtual would have had a valid claim on people distributing native binaries compiled against their commercial KaffePro offering using their gcj fork, as in that case the actual binaries would have contained copyrightable, verbatim sections of the class libraries. (And/Or against people distributing gcj-ed versions of old, GPLd kaffe class libraries). They would also have had valid claims against people using non-standard extensions of Kaffe, and otherwise creating derived works of the VM or the GPLd extension libraries. In case of bytecode using standard Java APIs, a copyright infringement claim would not really have a chance of succeeding, as the bytecode files would contain only references to class files, and not contain any coprightable parts of the GPLd (or GPL+exceptioned) class libraries, and as bytecode using standard APIs is by definition VM independant, any derived work claims would not work, as long as the works are clearly distributed as separate works. If someone really wanted to claim copyrights on strings like java.lang.Object and try to enforce the GPL that way, they'd have a hard time showing the copyrightability (for which originality is a precondition) of those strings in face of the prior standardisation of the exactly same strings by Sun Microsystems. The major benefits of the linking exception in GNU Classpath are that it allows ahead-of-time compiled use of class libraries without requiring that the works incorporating those natively compiled class libraries are licensed under the GPL, and that the exception makes the aforementioned explanations about copyrightability, freedoms, and all that unnecessary. In particular the latter is a pretty good reason to finish the class library merge sooner, rather than later :) However, I cannot 100% guarantee that the whoever holds or buys the rights to the old Transvirtual stuff might not someday demand compliance with their interpretation of the GPL, and threaten to sue if that does not happen. I suspect that this scenario is somewhat unlikely, since it would cost a lot of money to sue, the legal case probably isn't very good, and the amount of damages that they could get would probably be minimal. I suspect the current owners of the old Transvirtual IP are aware that they own it, but they also realize that it would be extremely difficult to extract any value out of it using this method. I doubt that would happen, as whoever ended up owning the Transvirtual copyrights has not made any threats in the last three years since Transvirtual went bankrupt, so I wouldn't assume that they would do so now. There are also various counterexamples in the FSF
Re: [kaffe] Re: kaffe's license
Jim Pick wrote: I mention it because that was Transvirtual's old position. Yes, I believe it to be FUD too. :-) Transvirtual had a valid claim regarding ahead of time compiled code, as the resulting ahead of time compiled binaries would have incorporated copies of GPLd classes. Compiling the class library down to native code made a lot of sense for some embedded targets, I guess, which were Transvirtuals main market, and they probably wanted to keep competition (i.e. internal forks of gcj) out of those markets by requiring them to write their own class libraries with GPL+linking exception rather than reusing Transvirtual's GPLd code directly. Back in the days, Transvirtual's product was the only one to offer AWT support on many platforms, while gcj didn't have an AWT implementation, and licensing Transvirtual's code under the GPL prevented proprietary software developers from creating non-GPLd binaries from Transvirtual's GPLd AWT code using gcj rather than using Transvirtual's KaffePro products. I didn't even mention the messy situation with software patents, particularly in the U.S., and possibly Europe, soon... Who knows what patents companies like Sun, IBM, Microsoft and others are holding that might apply to our implementation? Again, I suggest doing as Linus does, and ignoring software patents as long as noone is there making such claims. In some jurisdictions (like USA), patent infringement damages can be higher if you knowingly violate patents, so the best advice, afaik, is *not* to go out there looking for patents one may violate. The same page also says that subclassing a GPL'd java class is creating a derivative work. Kaffe's class libraries were GPL'd. We've almost completely moved over to using the Classpath projects class libraries, which are GPL+Exception, so hopefully that will provide some more license insulation. :-) In general, subclassing a GPLd Java class is creating a derivative work. For example, if Kaffe had a GPLd, Kaffe-specific Java class for jitters to plug in, than all jitter implementations for Kaffe extending that class would necessarily be GPLd. With respect to programs using standard APIs with multiple implementations, though, those programs are written to the API specs, rather than to a particular implementation of it. So a HelloWorld source code that uses System.out.println(HelloWorld); is an independant work from any VM it can be executed in, and therefore can be licensed independently of the license of the GPLd VM. The resulting binary class file looks exactly the same no matter which class library it was compiled against, and works in the same way, VM independantly, so whatever interface names end up being in there from the GPLd implementation of java.lang.System, are there because of the requirements of the bytecode format, and are not copyrightable in themselves (don't meet requirement for originality, as one would always come after the JCP, and for the sake of compatibility have to have exactly the same strings). As the bytecode is exactly the same with either class library, and there is nothing specific to GPLd code and copyrightable that ends up in the resulting binary, the resulting bytecode is an independant work that can be licensed as one wishes, as long as no other constraints on its licensing exist, of course. That's the difference between using a GPLd, unique class library: in that case, the bytecode and the source code both contain strings that are copyrightable (since original) by the authors of the unique GPLd class library, and the resulting work directly depends on incorporating the unique GPLd library: it is clearly not an independant work. That being said, the final switch to GNU Classpath will also make the licensing situation a bit clearer, making such long elaborations hopefully unnecessary. :) Nevertheless, I'd like to encourage people to publish their code under the GPL or GPL-compatible licenses, even if they are not required to, as David A Wheeler's article[1] shows that the benefits of participating in the GPL pool are huge. cheers, dalibor topic [1] http://www.dwheeler.com/essays/gpl-compatible.html ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: kaffe's license
Jim Pick wrote: ... The GPL license is somewhat undefined in terms of how it interacts with other code. It's not a license I would have chosen for a virtual machine. Some people say if you run an application on top of the VM, you would have to make that application GPL-licensed too. Some people say that's nonsense (I tend to agree with that viewpoint). That is clearly FUD. GNU explicitly says that is not the case, and if it were the case then any non-open source application running on Linux would be in violation. http://www.gnu.org/licenses/gpl-faq.html#PortProgramToGL The lack of undue dependency for VM's made clear here: http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat The poster's original question is also answered by GNU: http://www.gnu.org/licenses/gpl-faq.html#TheGPLSaysModifiedVersions Jim White ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: kaffe's license
Jim White wrote: Jim Pick wrote: ... The GPL license is somewhat undefined in terms of how it interacts with other code. It's not a license I would have chosen for a virtual machine. Some people say if you run an application on top of the VM, you would have to make that application GPL-licensed too. Some people say that's nonsense (I tend to agree with that viewpoint). That is clearly FUD. I mention it because that was Transvirtual's old position. Yes, I believe it to be FUD too. :-) I'm just trying to lay out the situation and the history so that people can make an intelligent decision themselves as to whether or not there is a legal risk for them. I would love to be able to say there is no risk that somebody using Kaffe would ever be sued, but I'm not a lawyer (and I doubt you could ever get a lawyer to say that either). Remember, companies like SCO will sue people even if they have no legal basis for a case. I didn't even mention the messy situation with software patents, particularly in the U.S., and possibly Europe, soon... Who knows what patents companies like Sun, IBM, Microsoft and others are holding that might apply to our implementation? GNU explicitly says that is not the case, and if it were the case then any non-open source application running on Linux would be in violation. True, and the Linux license also adds a clarification to make that very clear. http://www.gnu.org/licenses/gpl-faq.html#PortProgramToGL The lack of undue dependency for VM's made clear here: http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat The poster's original question is also answered by GNU: http://www.gnu.org/licenses/gpl-faq.html#TheGPLSaysModifiedVersions The same page also says that subclassing a GPL'd java class is creating a derivative work. Kaffe's class libraries were GPL'd. We've almost completely moved over to using the Classpath projects class libraries, which are GPL+Exception, so hopefully that will provide some more license insulation. :-) Cheers, - Jim ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: kaffe's license
Kiyo Inaba wrote: toodulli wrote: I wondering kaffe's license. After I modify kaffe's source code for commercial distribution, I want to use for kaffe virtual machine in digital television settop box. And then, Have I a duty to give money? Where? Good to hear someone is trying to deploy the usability of kaffe :-) Since kaffe is licensed by GNU General Public License or GPL, you need not to pay money at all. The main obligation for you is if you modify some part of kaffe, you also have to make this modified portion open. See more detail in http://www.opensource.org/licenses/index.php I hate to add FUD (fear, uncertainty, doubt) to our own project, but I think some history of the licensing of the project might be illustrative. It's all a bit unclean, unfortunately. We should right a FAQ on this... In the early days, Kaffe was released by Tim Wilkinson under a BSD style license. When he started a company (Transvirtual) to commercialize the technology, they started doing newer releases under the GPL, which was supposed to discourage people from using it in commercial products, so they could sell their proprietary version. That business model didn't actually work very well, and Transvirtual eventually closed down. The GPL license is somewhat undefined in terms of how it interacts with other code. It's not a license I would have chosen for a virtual machine. Some people say if you run an application on top of the VM, you would have to make that application GPL-licensed too. Some people say that's nonsense (I tend to agree with that viewpoint). To my knowledge, I'm not aware of any cases where somebody has been sued for running non-GPL code on a GPL'd virtual machine. It's not a common scenario. I think Transvirtual actually came to regret re-releasing the VM under the GPL, since they saw that people were actually using the GPL'd version for commercial developments, and were not coming to them for the proprietary version. The Kaffe project never demanded copyright assignment, so the intellectual property rights for the various bits in the virtual machine still reside with the authors of those parts (similar to how the Linux kernel is owned). This means that the parts of the virtual machine contributed by Transvirtual are still owned by whoever has acquired the assets of Transvirtual. The company at twincom.net looks like they may have acquired the assets, but I don't know what sort of legal agreements they have signed. Also, other contributors to Kaffe, eg. the people on this mailing list, own the parts they have contributed. Personally, I would never sue anybody over using Kaffe for any purpose, and I'm sure most of the other contributors feel the same way. I would like to see users comply with the spirit of the GPL, and contribute their modifications to the virtual machine back to the project. However, I cannot 100% guarantee that the whoever holds or buys the rights to the old Transvirtual stuff might not someday demand compliance with their interpretation of the GPL, and threaten to sue if that does not happen. I suspect that this scenario is somewhat unlikely, since it would cost a lot of money to sue, the legal case probably isn't very good, and the amount of damages that they could get would probably be minimal. I suspect the current owners of the old Transvirtual IP are aware that they own it, but they also realize that it would be extremely difficult to extract any value out of it using this method. So, if you absolutely can't take any legal risks, you might be better off just prototyping with Kaffe, and then choosing another Classpath-based virtual machine to actually put in your product. If somebody was motivated, we could attempt to track down all the IP holders that have contributed to Kaffe, and attempt to relicense the project or get copyright assignment. That may be difficult though, especially since some of them have died. It would probably just be easier to direct efforts to some of the other virtual machine projects out there with cleaner licensing, especially since they now share so much with Kaffe (eg. the Classpath libraries). That said, I personally don't think that Kaffe's somewhat unclear licensing situation is much of an obstacle for most uses, so I don't see any reason not to keep the project going. Cheers, - Jim ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
