|
|
|
| Authored by: Anonymous on Friday, May 11 2012 @ 01:02 AM EDT |
Sigh. Can someone just track down who or what this "Spring" company is
and get someone from said company to tell us what in the world is this
"Spring"? Not that I think the court will be interested to hear about
it at this point.
BTW, it took a few minutes before I figured out that "JMOL" =
"judgment as a matter of law". lol. Was wondering what new terminology
was involved in this lawsuit, since I was only familiar with "Jmol"
the 3D molecule viewer before this.[ Reply to This | Parent | # ]
|
- URL - Authored by: jbb on Friday, May 11 2012 @ 01:07 AM EDT
- URL - Authored by: Anonymous on Friday, May 11 2012 @ 01:20 AM EDT
- Companies House Information - Authored by: indyandy on Friday, May 11 2012 @ 02:52 AM EDT
- URL - Authored by: Anonymous on Friday, May 11 2012 @ 09:09 AM EDT
- Spring is in the air! - Authored by: Anonymous on Friday, May 11 2012 @ 09:44 AM EDT
| |
| Authored by: Anonymous on Friday, May 11 2012 @ 01:02 AM EDT |
In Googles filing they specifically discuss this and show that
Springsource copied actual Java APIs. Oracle does not look good after
reading the two different versions.[ Reply to This | Parent | # ]
|
| |
| Authored by: jbb on Friday, May 11 2012 @ 01:06 AM EDT |
| Spring's reliance on the Sun core APIs is a perfect example of why it is so
important that Google be allowed to make their APIs as compatible with the Sun
core APIs as possible. While it might be unlikely that someone would want to
use the Spring application development framework on an Android phone, there are
hundreds, probably thousands of other 3rd-party extensions that are built on top
of the Sun core APIs.
If Oracle prevails in their API claims then they
will have locked out Google and all Android developers from making use of those
existing 3rd-party extensions. If the court gives Oracle copyright control over
the core Java APIs then it is also giving them some de facto control over all
3rd-party software that made use of those core APIs. The only way Android
developers can use the existing 3rd-party Java software is if Google is allowed
to re-implement the core Java APIs.
Sun enticed those 3rd-party
developers to use the core Java APIs with the promise that Java was free and
would always be free. The open source versions of Java, such as Harmony, were
testaments to this promise. The developers were enticed with the promise that
there would be no lock-in. Now, after reaping all the benefits of that
3rd-party development Oracle wants to change the rules by having this court give
Oracle all the 3rd-party lock-in it now desires despite its earlier promises.
Why should Oracle have the right to prevent those 3rd-parties extensions from
working with Android?
---
Our job is to remind ourselves that there
are more contexts
than the one we’re in now — the one that we think is reality.
-- Alan Kay [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 11 2012 @ 01:38 AM EDT |
I was also very confused by the reference to springsource since afaik they never
implemented parts of the java core libraries. What they did however was to
develop and establish an alternative to the APIs of Java Enterprise Edition
(J2EE / JEE).
I don't remember who mentioned spring first, but their alternative API could be
relevant to this case in two ways:
1. Initially, it sort of fragmented the java community regarding the
implementation of web and enterprise applications. However, parts of both APIs
can be used together and many ideas from springs API found their way into newer
JEE standards.
2. It shows that it is possible to create alternative APIs that don't follow the
same structure, sequence and organization, but implement similar features to the
standard.[ Reply to This | Parent | # ]
|
| |
| Authored by: lwoggardner on Friday, May 11 2012 @ 04:09 AM EDT |
| or more correctly as to what Google should have done instead
of Dalvik,
according to Oracle.
The briefing does not make this clear at all and the
fact
that Spring and J2EE (Java 2 Enterprise Edition) are both
built on top of
J2SE further confuses the issue.
But I've been through plenty of quasi
religious discussions
where developers are making a choice between implementing
applications with J2EE vs taking the Spring approach that
I'm almost certain
this is what they are getting at.
So the folks at Spring said - "J2EE is
rubbish, we'll create
our own competing API for building enterprise java apps".
People won't be able to re-use code they wrote for J2EE,
they'll have to start
again. Of course the fact that most
J2EE code wasn't even portable between JEE
certified
containers meant that wasn't much of a barrier.
A quick google found
this
which is comparing them as good as any
starting point to
compare the two. [ Reply to This | Parent | # ]
|
|
|
|
|
