More urgency for CinC & CLR given Oracle's lawsuit against Google?
Seth
anyone else suddenly much more concerned about the states of Clojure
in Clojure and CLR compatibility? I know the former is an important
goal and also that the existence of the latter is due to heroic
volunteer efforts on behalf of a small number of people. Frankly I've
been sitting on the sidelines cheering the efforts on.
But now I'm much more concerned about writing Clojure code that can
only run as Oracle sees fit. I've got a small bit of code which needs
OpenJDK on an Linux Amazon EC2 instance. What will the Oracle scry of
that?
If it sounds like I'm stirring up FUD I apologize, it's not my intent.
Oracle has its fiduciary responsibilities and the patent system is
what it (sigh) is.
Here's my ideal option: a production quality release of Clojure
targeting the CLR before the first anniversary of SCOracle day
(2010-08-12). This would have to be an organized effort since big
meaty chunks like CinC are probably within scope of only a few
Clojurians (i.e. not me).
Just my personal opinion -- questions, comments, and corrections are
welcome.
Seth
Nicolas Oury
The OpenJDK is,I think, a bit protected frompatents by its license and
the fact t has been distributed by the patents' owner.
However, Clojure in Clojure and better support of other platforms
would be great.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
nickikt
should anything change for clojure?
As far as Dalvik goes. Why should Clojure care the lawsuit is about
implementation details (as far as I understand) in the VM the basic
working will be the same.
Befor starting a real effort to support clojure on more VMs (not just
CLR) we should finish Clojure in Clojure first. When Clojure is in
Clojure as far as posible it will be mutch easier to support the CLR
and others. Instead of splitting efforts know our goal should be
Clojure in Clojure.
On Aug 13, 1:40 pm, Nicolas Oury <nicolas.o...@gmail.com> wrote:
> I believe they do not sue over the JVM but over Dalvik.
> The OpenJDK is,I think, a bit protected frompatents by its license and
> the fact t has been distributed by the patents' owner.
>
> However, Clojure in Clojure and better support of other platforms
> would be great.
>
Heinz N. Gies
> Given Oracle's lawsuit against Google for its use of the JVM, is
> anyone else suddenly much more concerned about the states of Clojure
> in Clojure and CLR compatibility?
As far as I understand those things are absolutely not related, oracle isn't suing because they use the JVM but because they are not and rolling their 'own JVM' which, so claims Oracle, violates some of 'their' patents.
Clojure on the other hand is simply using the JVM, as Oracle provides it, and the interfaces they provide, something they of cause will not sue over as it is a entirely different thing.
Also this while 'oracle sues' panic is kind of sad :(
Regards,
Heinz
Brian Hurt
Given Oracle's lawsuit against Google for its use of the JVM, is
anyone else suddenly much more concerned about the states of Clojure
in Clojure and CLR compatibility? I know the former is an important
goal and also that the existence of the latter is due to heroic
volunteer efforts on behalf of a small number of people. Frankly I've
been sitting on the sidelines cheering the efforts on.
But now I'm much more concerned about writing Clojure code that can
only run as Oracle sees fit. I've got a small bit of code which needs
OpenJDK on an Linux Amazon EC2 instance. What will the Oracle scry of
that?
As the good book says: DON'T PANIC.
IANAL, but I don't think this lawsuit has any bearing on Clojure at all. The crux of the lawsuit, as I understand it, is that Google is shipping a non-conforming Java platform with their Android- and since it's non-conforming, the guarantees Sun gave out (and Oracle is still bound by) about not requiring patent licenses for conforming platforms don't apply, so Google needs a license. What I expect to happen is a couple of months of legal maneuvering, followed by Google cutting Oracle a check with a fair number of zeros, and the whole thing going away. Worse case, the Android handset makes all have to cut checks as well. But note- what Google did that opened itself up for this lawsuit was shipping a non-conforming Java implementation. Clojure isn't shipping a Java implementation at all, conforming or not, so the whole issue is moot.
Note that the CLR has all the same patent problems as the JVM- just substitute "Microsoft" for "Oracle". So switching to the CLR doesn't help (to the extent that there is a problem at all).
Patents are a problem for software developers, in that you never know what patents you might be violating or who might sue you. But again, this has nothing to do with what language you implement things in.
So relax. Breathe deep, pop some popcorn, and settle in to your comfy chair to watch the legal donnybrook.
Brian
Quzanti
settled by Google paying some sort of fee. Unless Google can buy
someone with patents that Oracle is infringing then they can cross
license.
The only two implications I can think of are
(1) Hardly helpful for people's confidence in the Java Platform, if
Oracle embarks on these kind of surprise antics. May push people
towards CLR. If Oracle start getting aggressive, then everyone will
start worrying who they will attack next.
(2) As Dalvik is based on Harmony and Harmony is techically non
conforming (as they have never licensed the TCK) does this have any
implications for Harmony. Although I don't use Harmony, it is nice to
know its there as if Oracle un-open source Java (like they are doing
with Solaris) then Harmony is my fallback option.
On Aug 13, 5:29 pm, Brian Hurt <bhur...@gmail.com> wrote:
evins...@gmail.com
>
> The only two implications I can think o
> Oracle embarks on these kind of surprise antics. May push people
> towards CLR. If Oracle start getting aggressive, then everyone will
> start worrying who they will attack next.
meetings in the wake of the Oracle acquisition of Sun, the Oracle
attorneys were salivating over JVM licensing; the issue is Oracle
seeing such lawsuits as an attractive revenue stream, and what effect
that will have on the Java market for the long term.
In the short term, the java market is huge in the server space, and it
looks promising in the mobile space. In the desktop client space it's
essentially dead because Sun killed it by suing Microsoft over a
noncompliant implementation. What Sun got out of that suit was a nice
short-term benefit (a lot of cash from the settlement), and a major
long-term loss, as Microsoft replaced their nonconformant JVM with a
new VM and source language that were just different enough to be
invulnerable to additional suits. Oh, and a thriving desktop client
market in which Java participates not at all.
The concern is that, if Oracle sees lawsuits over technical
noncompliance as an attractive revenue stream, then they'll go about
suing everyone with deep pockets who has any involvement with Java,
with more or less the same effect that the Sun suit against Microsoft
had--or at least sowing enough anxiety and confusion to have a
chilling effect on the Java market, and making the JVM look less
attractive as a platform.
Again, in the short term it's unlikely to have much effect, because
the existing Java ecology is so large and rich. The long term is more
of a crapshoot, though, and the uncertainty there certainly makes it a
good idea to make Clojure as able as possible to survive independent
of any particular VM.
Mikhail Kryshen
likely to sue Microsoft is that Microsoft could do the same to Oracle.
See http://jonathanischwartz.wordpress.com/2010/03/09/good-artists-copy-great-artists-steal/
Mono - the open source implementation of .NET also has uncertain legal status.
I doubt it is possible to create runtime like JVM or CLR without patent
problems.
--
Mikhail
Mike Meyer
Mikhail Kryshen <mik...@kryshen.net> wrote:
>
> I doubt it is possible to create runtime like JVM or CLR without patent
> problems.
Given that virtual machine technology "like"(1) the JVM and CLR have
been around since the 70s - long before even C++ ++ -- was a gleam in
Gosling's eye - I'm pretty sure it's possible to create a runtime
"like" the JVM or CLR that has no insurmountable patent
problems. Sure, Oracle can create problems for anyone implementing a
VM by suing them, but if you started with something like either the
UCSD P-Machine VM or a SmallTalk VM (Squeak, maybe?) - which Gosling
cites as inspirations for the JVM (2) - such suits are clearly
baseless, as the technology is obviously prior art. So it can't
infringe the patent, only invalidate it.
<mike
*) This all depends on exactly what you mean by "like". Gosling and
the Java group at Sun are sharp people, I'm sure they added ideas that
were patentable, and probably even worth granting a patent to. If
"like" includes "having patented feature foo", then foo may be missing
from the VMs that are prior art, so they aren't "like" JVM or CLR. But
just having a portable VM also qualifies as "like" JVM in some sense.
1) http://queue.acm.org/detail.cfm?id=1017013
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Seth
announcement was a shock and quickly followed by waves of grumbling
from devs I follow on Twitter. While it's easy to extrapolate the
future from Oracle's past and this announcement, it's not necessarily
useful or accurate to do so. I never suspected Clojure to be in any
mid-term jeopardy. But it did seem like a good opportunity to stoke
the CinC and CLR topics and see if there was a big change in the level
of interest. Apparently not, and that's probably prudent.
That said, I personally am now more interested in better CLR support
for Clojure. While it's not a strength of mine, I'm sure I will find
some way to contribute to that.
Sorry again for any off topic churning, and here's hoping the JVM will
continue to be a good place for Clojure to be for quite some time.
Seth
On Aug 13, 4:06 pm, Mike Meyer <mwm-keyword-googlegroups.
>
> > I doubt it is possible to create runtime like JVM or CLR without patent
> > problems.
>
> Given that virtual machine technology "like"(1) the JVM and CLR have
> been around since the 70s - long before even C++ ++ -- was a gleam in
> Gosling's eye - I'm pretty sure it's possible to create a runtime
> "like" the JVM or CLR that has no insurmountable patent
> problems. Sure, Oracle can create problems for anyone implementing a
> VM by suing them, but if you started with something like either the
> UCSD P-Machine VM or a SmallTalk VM (Squeak, maybe?) - which Gosling
> cites as inspirations for the JVM (2) - such suits are clearly
> baseless, as the technology is obviously prior art. So it can't
> infringe the patent, only invalidate it.
>
> <mike
>
> *) This all depends on exactly what you mean by "like". Gosling and
> the Java group at Sun are sharp people, I'm sure they added ideas that
> were patentable, and probably even worth granting a patent to. If
> "like" includes "having patented feature foo", then foo may be missing
> from the VMs that are prior art, so they aren't "like" JVM or CLR. But
> just having a portable VM also qualifies as "like" JVM in some sense.
>
dmiller
CLR. :)
- David
Florian Weimer
> CLR also infringes Oracle's patents and the only reason why Oracle is not
> likely to sue Microsoft is that Microsoft could do the same to Oracle.
Microsoft rescued Sun a couple of years ago with a cash injection
(similar to what they did with Apple), and the companies reached some
agreement on patents back then. Those contracts probably remain in
force despite the acquisition.
However, it is unclear to what extent such agreements cover downstream
users of such technology. The best defense seems to be not to become
too successful.