That’s copyright law mostly with patent provisions in some licenses for the specific work as is. That leaves patents for how it’s used or combined with other software. Oracle, Microsoft, and IBM in particular like to file lots of those. I dont know if any are on GraalVM because just looking triples the damages. I never look.
If the distribution and/or use of the Program is restricted in certain
countries either by patents or by copyrighted interfaces, the original
copyright holder who places the Program under this License may add an explicit
geographical distribution limitation excluding those countries, so that
distribution is permitted only in or among countries not thus excluded. In
such case, this License incorporates the limitation as if written in the body
of this License.
Seems to me that the patent clause is opt-in rather than required. OpenJDK uses the GPL v2, which lacks the clear patent grants of v3.
In 2004 Dan Ravicher, senior counsel for the Free Software Foundation, warned about the weak patent guarantees for BSD and GPL and recommended attaching patent grants.
Thank you. That is very interesting reading. Sounds like the waters are muddy and we need an actual lawyer to chime in.
I partially side with Oracle on the Google case (excluding copyrighting APIs). Google had plenty of opportunity to licence Java from Sun, or indeed to buy Sun entirely, but they chose to incompatibly re-implement it and developers have been paying the price for that choice ever since. But it looks like Google finally did the right thing in the end:
http://www.fosspatents.com/2015/12/google-switches-to-open-source-license.html
Not all of it. The GraalVM Downloads page makes it clear that there are two versions of GraalVM: Community Edition (CE) and Enterprise Edition (EE). GraalVM EE is closed-source, and it’s the only version with support for macOS and with “additional performance, security, and scalability”.
The developers have stated the only reason for the macos absence is they haven’t gotten around to it yet, and also there is currently no difference in performance.
Oracle does not do things for the benefit of the community; everything it does is for the benefit of its bottom line. This technology looks fascinating, but frankly I’m not going to take the time to figure out what Oracle’s angle is here to get the sales and legal divisions involved, or convince myself that, for the first time in my experience, there isn’t one. (Oracle v. Google was just the last of many straws.)
So this can actually run unmodified CPython and R code, complete with extensions in C/C++/Fortran?
Or is it like the JVM versions of Python and R, which don’t have the same native extension ecosystem?
I think it’s the former, since they say they support LLVM-based languages. They probably don’t run Fortran, which is important for R code. But I think that is a big deal because C extensions are what is holding back PyPy.
Interested in thoughts from anyone who has tried it.
This is pretty damn cool – has anyone used this or had a need? I’m not sure I’ve ever needed to grab a piece of Java and stick it in my python, but maybe now that I know it’s straightforward it’ll come up.
For the rest of the thread, my deleted comment was “This seems like witchcraft. How does it work?” I deleted it because I thought I was being lazy. (Now I am adding it back in because it’s a pet peeve to see answers to deleted questions.)
Here is an article (I have yet to read) on how the Graal VM works:
There are no bytecodes involved. All of the languages share a common AST representation where nodes can be compiled and specialised if they are frequently executed.
This reminds me that we are still light-year away from the simplicity of hypermedia when embedding software. I understand their objective is to “Run Program Faster Anywhere” but once you show the polyglot approach I will ask if it’s possible to do it inline and mix languages. Very sad to see that it’s not possible (yet).
Also the examples are missing a “start from python”, is it possible? Silly me, there is
VMs written on Graal/Truffle effectively do inline by runtime AST specialisation. The various languages share a common AST representation whereby nodes can be specialised and compiled down to native code.
Even the Parrot vm had the same very simple and abstract instructions and you could run every scripting language on top of it. What I was trying to point out is that mixing different languages in the same source code is still not a thing. I was thinking at % magic commands available when using ipython, like %R to call some R code.
It’s not a widespread thing, no. Probably because it comes with some tricky practical challenges (type conversions, performance, grammar composition, …). Nonetheless it can be done efficiently. The paper I linked allows Python and Prolog code from the same file to be JITted. Later we published a paper showing that we can JIT PHP and Python code from the same file.
The real question though is, is that level of granularity useful? Our PHP/Python system allowed cross language closures between arbitrarily deeply nested scopes, but we didn’t find any particularly compelling examples of why that might be useful :P
This is a beautiful technology. It is very sad that many people will ignore this because of Oracle v. Google lawsuit. What a tragedy.
This looks suspiciously like an “embrace, extend, and extinguish” play by Oracle to the observer.
Anything from them potentially is one just due to their legal team. I’m avoiding it specifically for that. Java, too, just in case.
It’s all open source.
That’s copyright law mostly with patent provisions in some licenses for the specific work as is. That leaves patents for how it’s used or combined with other software. Oracle, Microsoft, and IBM in particular like to file lots of those. I dont know if any are on GraalVM because just looking triples the damages. I never look.
I’m not a lawyer, but openJDK, which now includes Graal, is GPL licenced which includes patent protection.
This is incorrect; the patent grant applies to the official OpenJDK builds but not forks of OpenJDK.
Do you have a source for that? That wouldn’t be GPL then under my understanding.
The GPL seems relatively clear on this: http://openjdk.java.net/legal/gplv2+ce.html
Seems to me that the patent clause is opt-in rather than required. OpenJDK uses the GPL v2, which lacks the clear patent grants of v3.
See also https://www.skife.org/java/jcp/2010/12/07/the-tck-trap.html and the lawsuits Oracle fired at Google. (The patent claims ended up getting thrown out because Google has excellent lawyers in that case.)
Edit: more details about the weak language used around patents in v2: https://www.infoq.com/articles/java-dotnet-patents
With further digging it seems that Oracle joined the OIN and OIN explicitly covers the openJDK for patents:
http://www.openinventionnetwork.com/community-of-licensees/
https://www.zdnet.com/article/linux-patent-defense-group-expands-open-source-protection/
Thank you. That is very interesting reading. Sounds like the waters are muddy and we need an actual lawyer to chime in.
I partially side with Oracle on the Google case (excluding copyrighting APIs). Google had plenty of opportunity to licence Java from Sun, or indeed to buy Sun entirely, but they chose to incompatibly re-implement it and developers have been paying the price for that choice ever since. But it looks like Google finally did the right thing in the end: http://www.fosspatents.com/2015/12/google-switches-to-open-source-license.html
Not all of it. The GraalVM Downloads page makes it clear that there are two versions of GraalVM: Community Edition (CE) and Enterprise Edition (EE). GraalVM EE is closed-source, and it’s the only version with support for macOS and with “additional performance, security, and scalability”.
The developers have stated the only reason for the macos absence is they haven’t gotten around to it yet, and also there is currently no difference in performance.
And things like this.
https://www.reddit.com/r/javascript/comments/8d0bg2/oracle_owns_javascript_so_apple_is_taking_down_my/
So, Perl’s Parrot VM system was just ahead of its time?
Oracle does not do things for the benefit of the community; everything it does is for the benefit of its bottom line. This technology looks fascinating, but frankly I’m not going to take the time to figure out what Oracle’s angle is here to get the sales and legal divisions involved, or convince myself that, for the first time in my experience, there isn’t one. (Oracle v. Google was just the last of many straws.)
So this can actually run unmodified CPython and R code, complete with extensions in C/C++/Fortran?
Or is it like the JVM versions of Python and R, which don’t have the same native extension ecosystem?
I think it’s the former, since they say they support LLVM-based languages. They probably don’t run Fortran, which is important for R code. But I think that is a big deal because C extensions are what is holding back PyPy.
Interested in thoughts from anyone who has tried it.
Yup, it can! Sulong indeed supports C/C++/Fortran: https://github.com/graalvm/sulong
There’re discussions about Sulong adding support for languages like Rust, Swift, etc. as well.
In theory, NVIDIA is writing Flang which compiles Fortran to LLVM. I don’t know whether Flang supports Fortran code important for R well enough.
It’s unfortunate that mac support is limited to their enterprise edition.
This is pretty damn cool – has anyone used this or had a need? I’m not sure I’ve ever needed to grab a piece of Java and stick it in my python, but maybe now that I know it’s straightforward it’ll come up.
[Comment removed by author]
Likely some sort of transpiler from one bytecode to another, I would imagine.
Thank you for the response.
For the rest of the thread, my deleted comment was “This seems like witchcraft. How does it work?” I deleted it because I thought I was being lazy. (Now I am adding it back in because it’s a pet peeve to see answers to deleted questions.)
Here is an article (I have yet to read) on how the Graal VM works:
http://chrisseaton.com/truffleruby/jokerconf17/
There are no bytecodes involved. All of the languages share a common AST representation where nodes can be compiled and specialised if they are frequently executed.
This reminds me that we are still light-year away from the simplicity of hypermedia when embedding software. I understand their objective is to “Run Program Faster Anywhere” but once you show the polyglot approach I will ask if it’s possible to do it inline and mix languages. Very sad to see that it’s not possible (yet).
Also the examples are missing a “start from python”, is it possible?Silly me, there isVMs written on Graal/Truffle effectively do inline by runtime AST specialisation. The various languages share a common AST representation whereby nodes can be specialised and compiled down to native code.
Cross-language tracing has also been done with RPython: http://soft-dev.org/pubs/html/barrett_bolz_tratt__approaches_to_interpreter_composition/
(disclaimer, I’m one of the authors of that linked paper)
Even the Parrot vm had the same very simple and abstract instructions and you could run every scripting language on top of it. What I was trying to point out is that mixing different languages in the same source code is still not a thing. I was thinking at
%magic commands available when using ipython, like%Rto call some R code.It’s not a widespread thing, no. Probably because it comes with some tricky practical challenges (type conversions, performance, grammar composition, …). Nonetheless it can be done efficiently. The paper I linked allows Python and Prolog code from the same file to be JITted. Later we published a paper showing that we can JIT PHP and Python code from the same file.
The real question though is, is that level of granularity useful? Our PHP/Python system allowed cross language closures between arbitrarily deeply nested scopes, but we didn’t find any particularly compelling examples of why that might be useful :P
Looking forward to trying TruffleRuby with FreshBSD. Not holding my breath for a FreeBSD build, though.
FreeBSD is stuck on Java 8 for now (the 9 porting work has started but seems kinda abandoned), and all the Graal stuff really wants Java 9/10…