From: Chad Perrin Date: 2012-05-20T06:10:55+09:00 Subject: Re: break down of differences between interpreters? On Sat, May 19, 2012 at 09:44:56PM +0900, Charles Oliver Nutter wrote: > On Sun, May 6, 2012 at 11:20 AM, Chad Perrin wrote: > > * Licensing concerns may come into play. �Rubinius, MIR/YARV, and > > �(surprisingly) IronRuby are all distributed under more permissive > > �licenses than JRuby these days. �This might turn out to be important > > �for some deployment scenarios. > > This is false. JRuby is licensed under three licenses, and you can > pick whichever you want to use: GPL, LGPL, and CPL. The CPL is a more > permissive license like Apache or BSD. > > http://www.opensource.org/licenses/cpl1.0 It is quite different from the Apache License v1.x through v2.x. Similarities include patent license. Differences, at first glance, appear to invovle the fact the Apache License 2.0 (for instance) includes modification notes in all modified files and a limited form of advertising clause, and the fact that the CPL requires notice of where to receive sources if it is distributed in "object code" form (equivalent to the upstream source provisions of the GPL in the case of noncommercial redistribution). Maybe I misread something when I skimmed the license. Meanwhile, the Revised BSD License and Simplified BSD License are both certified as compliant with the Copyfree Standard Definition, and impose no substantive restrictions on recipients of the software apart from the simple requirement to keep the license with the software. To be fair, though, I had never seen any notice of the CPL as a disjunctive multi-license option for JRuby, so thank you for letting me know about that option. > > > > * The fact the JRE is tied to Oracle now, and Oracle has been going > > �around rattling its litigation saber at anyone dealing with alternate > > �Java implementations makes a lot of people wary about using the JRE > > �where it is not strictly necessary. > > Oracle is going after *one* alternative Java implementation (Android, > which Google tries to sell as not being Java) largely because they > (Oracle) failed to successfully come up with a way to recreate mobile > Java and want a piece of this pie. It will likely come to almost > nothing in the courts. Oracle also imposed limitations on its Community Process implementation working group that forced the Apache Foundation to cease development of its Harmony project and drop out of that group. There are also rumors of Oracle demanding that Boeing start paying royalties on contracted deployments of Java software with the Oracle implementation of Java. > > Sun/Oracle has also stated a few times that Android could or could > have used OpenJDK, and they encourage forking and experimentation on > top of the GPL-based OpenJDK codebase. This isn't a fight about the > JRE...it's just politics and greed. What's the "politics and greed" component here? How is reimplementation to better suit the Android platform, rather than using the OpenJDK as distributed by Oracle (which depends on some less-free files for most deployment use cases), a matter of "politics and greed"? It sounds to me like the "politics and greed" characteristics of the fight are over Oracle's desire to keep others from making use of the Java language in a way that does not positively affect its bottom line directly. > > > > * Rubyists in general tend to target MRI/YARV first and foremost, and > > �other implementations are often treated as second-class citizens for > > �purposes of compatibility testing. �My impression is that Rubinius will > > �have the least problem with this long-term, because it will probably be > > �the closest thing to MRI/YARV for purposes of compatibility. �JRuby is > > �an apple that falls rather farther from the tree than that. > > The fact that JRuby falls far from the tree is a good thing. > > Implementations dependent on C extensions are going to always have > that cross to bear, for example, dealing with badly-behaving C code, > reduced parallelism, and GC complications. JRuby + JVM language-based > extensions have no such limitations. If I assume you're talking about the technical benefits of Java, I think that's a matter for the person choosing an implementation to decide. It's also not really relevant to what I said. I'm not sure whether you're trying to dispute what I said with this statement; if so, I think you're off-target, and if not, I don't have a specific opinion on this matter at this time. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]