|
|
| About Compatibility and Fragmentation of Java (Oracle v. Google) ~pj |
 |
|
Saturday, May 05 2012 @ 08:39 PM EDT
|
OK, Java guys. Can I ask you another question, please? I've found something I hope you will listen to and tell me then if it doesn't answer the judge's question about compatibility, question 13:13. When discussing use of the SSO in the 37 API packages in Android to achieve “compatibility,” what exactly are the parties referring to? Is it “compatibility” with programmers who write in the Java programming language? Or compatibility with pre-existing programs? If so, approximately what percent of pre-existing programs written for the Java platform are compatible with Android? Is it compatibility with the TCK? Or Java virtual machine? Or java compiler?
I'd like to have you listen to a panel discussion, from JavaOne in 2007. I think it answers the question, at least mostly. It also shows what the real relationship between Sun and Project Harmony was at the time, and it's not at all the way Oracle is presenting it in this litigation.
Oracle is presenting it now that Sun grit its teeth and endured Google's actions and Project Harmony's presence, but that now there is a new sheriff in town, willing to take steps to enforce against anyone "violating" its terms. But was Project Harmony viewed as a violation by Sun?
They were collaborating with Sun in the JCP, and the title of the panel discussion was the "Java Technology Libre Panel", and the moderator, Sun's Tom Marble, identified the panel as representing the "leading voices" from the Open Source Java community, and he said, just before introducing Geir Magnusson of the Apache Harmony Project, "I've quite a distinguished panel of guests."
If Sun viewed them as illegal projects forking Java, why invite them to the panel and introduce them like that?
On that panel were:
- Sun's Tom Marble, OpenJDK Ambassador at the time
- Mark Reinhold, Chief Engineer of Java SE for Sun, whom you recall from his testimony for Oracle in this litigation
- Geir Magnusson, Chairman of the Apache Harmony Project and VP of Joost
- Mark Wielaard maintainer of GNU/Classpath
- Tom Tromey, Lead Developer, GCJ, at Red Hat and
- Dalibor Topic, co-maintainer of Kaffe Virtual Machine community
If you listen to the audio, notice how firmly they all agree that compatibility matters, so programs will actually run, including legacy applications. Specifications are discussed specifically in this context. Sun's Tom Marble is sitting right there, and the Open Source guys talk about just merging the code, so as to provide bug compatibility, so old Sun code that is now deprecated can still work without breakage. "The diversity is below the API level," one panelist says, talking about how important it is that the APIs be the same for everyone. "We collaborate on the spec and then we compete in the implementation," another says. Another contributor says that the blueprint and the as-built are never the same. And the Sun guy agrees. They all seem to me to agree that everyone could and should use the same specs and then implement with their own special touch, specifically to achieve compatibility, for the benefit of users. Sun didn't create those APIs all by itself, you see. And some of the folks that helped were from projects like Project Harmony. Sun was there. It knew. It had to know what was happening with the APIs.
I think that answers one of the judge's questions. But what do you say? I think it also partially answers question 4, about whether Google could have come up with different names and SSO yet still have provided the same functionality as in Android. The issue isn't whether Google could do that; the issue is what would have happened to compatibility had they done that. It's not just Android developers that would have been affected. You have to think about all the world's Java developers.
I mean, why include these independent projects leads as panelists in JavaOne, a conference Sun put on and so could invite whomever they wished, if they didn't approve of what they are doing? In 2008, Sun even hired Dalibor Topic to take over Tom Marble's job. How deeply unfair it is, then, for Oracle to argue now that using Project Harmony APIs, as Google did, can't even be used as a defense. Oracle argued that the jury shouldn't even be allowed to consider that evidence. There may be a new sheriff in town, but does he get to retroactively change the law and start suing people because they acted in harmony with what they were led to believe was the law at the time?
It was reported that the jury was told by the judge in answer to one jury question that Google had no license. But that is false. They did have a license. They had the Apache License, which comes with the code. You don't need to sign a paper to have that license. And to pretend now that all this history never happened -- and keep in mind that in 2007 Google was working on Android and relying on how things were at the time and in fact a Google employee, Zaheda Bhorat, was on another panel at that same 2007 JavaOne and very possibly listened to this panel discussion -- is smarmy. There. I said it. It may be legal in Oracle's eyes, if you dance around in the law's intricacies with great lawyers, but us common folk watch, and we say, Ugh. You know what happens to companies when enough people watch its business practices and say Ugh? Ask Microsoft.
Or the SCO Group. They tried to claim proprietary rights on header files. Remember? Errno.h. Lordy. How many words did Groklaw have to publish about errno.h? Does Oracle really want to act like the SCO Group? SCO tried to change the terms of the deal retroactively too. You saw how that worked out. The entire world despised them in the end.
People are drawn to fairness, not sharp practices, even if they sometimes work in the short term.
It's obvious Sun knew about Project Harmony and not only didn't act like it minded, it included Project Harmony folks on JavaOne panels in 2007 and introduced them with respect. It's too late now to fix that mistake in the answer to the jury's question, I suppose. But there is no reason for the rest of us to be misled.
As for fragmentation, look at this FAQ from the day Sun released Java under the GPLv2:
Q:
Can someone create and distribute an implementation that isn't compatible with the Java specification using this code?
A:
Yes. We do not recommend or endorse that action, however. In addition, they cannot label that implementation with the Java Compatible or Java Powered (for Java ME) brand and logo. These brands are your assurance that an implementation has passed the relevant TCKs.
Q:
Can someone create software that doesn't even implement Java, but uses pieces of the OpenJDK code commons? What are the limitations, if any?
A:
Yes. There are no limitations. But there is an obligation to meet the requirements of the GPL (plus Classpath and Assembly exceptions if appropriate).
Q:
Can I call the resulting software "Java"?
A:
No.
Q:
What must I do to call my software based on code from the OpenJDK or phoneME projects "Java"?
A:
The requirements for the use of the "Java" trademark and name have not changed with the open sourcing of the JDK and Java ME source code. The GPL v2 does not include a trademark license - no OSI-approved open-source licenses do. Sun does not currently have a licensing program that permits the use of the "Java" mark in your product or company name. You can use a truthful "tagline" however associating your product or company with Java technology, according to Sun's standard terms for use for trademarks. Please see http://www.sun.com/policies/trademarks/ for more details….
Q:
What about non-Java language files such as manpages, readme files, scripts, and other elements of the JDK? How are these licensed in the OpenJDK Project?
A:
These components are licensed under GPL v2 only.
Does that sound like Sun was determined to prevent all forks? Obviously, when it came to the release of Java under the GPL, they not only didn't care, because of the license terms, which they freely chose, they had no right to prevent it. So it's a pretense that Sun or Oracle hasn't already fragmented Java and/or enabled it to be further fragmented. They said you can fork if you wish, just don't call it Java, and that's because the GPL won't let you restrict modifying the code and redistributing. Sun was free to choose any license it wished, and this is the license it chose. One with no restrictions on doing whatever you wanted, whether compatible or not with Sun's Java. And look how Oracle has treated other Open Source projects it bought when it bought Sun. OpenOffice, Solaris, MySQL. It's not that there is a new sheriff. There's a new *owner* who disdains Open Source ways, except when it suits the company to just take its code and make money from it.
Why, then, did Sun have a different view? That same FAQ, from 2008, tells us why:
Q:
What is the significance of this announcement to the industry?
A:
This announcement takes open-source, compatible Java from a long-standing dream of developers worldwide, to concrete reality. With the open sourcing of the code base for one of the industry's most significant and pervasive software platforms, the groundwork has been established to foster adoption in new markets, to build broader communities, and fuel even more innovation. With over 5.4 billion Java technology enabled devices, Java technology has already demonstrated explosive growth, appearing in volume nearly everywhere. Now, as free software, the Java platform can address new markets and be the engine of innovation for the next generation of networked applications....
Q:
Why is Sun open sourcing its Java implementations now?
A:
The Java platform is 12+ years in the making. When it was first released it was a radical departure for commercial software, including full source code under a novel license. Sun and the Java ecosystem have been extremely successful at establishing and growing a very large and dynamic market in this time. The Java platform retained its own licensing model even as the open-source model proliferated, because the Java licensing model successfully created a large and open market with many compatible choices. We now see an opportunity to encourage even more possibilities for adoption in places the Java platform hasn't gone before, where Free licensing and open-source development approaches are a prerequisite for consideration.
At the same time, the Free software and open-source communities are now saying that compatibility is a given for any Java implementation. And there is a new spirit of innovation with Web 2.0, SOA and collaboration/participation technologies, and the Java platform is the perfect foundation platform on which to innovate - and open-source can help accelerate this innovation.
Q:
What influenced this decision?
A:
Key Free software and open-source communities have stated that they believe that only Java technology implementation that are completely compatible with the specification can succeed in the market. These communities, which provide thought leadership for the open-source Java world, are now focused on delivering only compatible implementations. In addition, Sun has gained experience in community development with the Project GlassFish open-source implementation of Java EE, with OpenSolaris, with OpenOffice.org and NetBeans, and with the JDK Community on java.net. This experience makes us confident that when we open-source Sun's Java implementations, the platform will benefit, and we can better balance the needs of community with those of customers, end users, and licensees.
Overall, we feel that caution is appropriate for a technology that affects the lives and livelihoods of tens of millions of people around the world. After much reflection we feel now is the perfect time to take the next step with the Java platform.
Q:
Why is this good for Java SE developers?
A:
Because volume wins. Open sourcing Sun's Java SE implementation will lower barriers to adoption in markets where open-source software leads. As new markets adopt Java technology, developers will discover new opportunities. More applications. Innovations that leverage the industrial strength foundation of Java to deliver valuable new products and services. And developers will be able to directly influence the future of the JDK implementation, participating with their peers in an open community. Taking Java where it hasn't been before, and helping to ensure that Java technology remains a central unifying standard for the Internet.
Q:
How does this benefit Java SE customers and users?
A:
Your investment is safe, with multiple independent implementations of Java SE, and the reference implementation from Sun available under an open-source license. An open-source JDK provides peace of mind, plain and simple:
You can adopt Sun's Java technologies with full confidence. Java SE will be freely available - subject to the market forces that drive competition, reduce price and speed innovation.
Whether you value Free and open-source software for philosophical or economic reasons, want more flexibility, appreciate the quality that transparency brings, or want to know you have ultimate control over your investment, you can adopt the JDK knowing that you'll gain these advantages.
With the rock-solid, high performance JDK implementation from Sun under the same open-source license used by GNU/Linux distributions, you can expect Java technology to find its way onto new platforms, be leveraged for new applications and infrastructure, and be the foundation of tomorrow's most exciting new products and web technologies.
Your investment in Java technology will become even more valuable as open-source speeds innovation, spreads adoption, and carries the platform to places it couldn't previously go.
Q:
What markets do you believe this initiative will open up for the JDK?
A:
Several markets are likely to find the JDK to be more suitable for use once it is under an open-source license:
Government, educational, and research markets where open-source software is either mandated, or highly desired.
Enterprises that mandate open-source infrastructure to retain maximum flexibility and drive competitive procurement.
Enterprises and organizations that have selected OS distributions based on GNU/Linux and OpenSolaris as preferred OSs for deployment.
In order to gain the benefits of commercial support, and predictability, these customers may choose to use Sun's commercial distribution of the JDK or JRE in conjunction with a support contract. However, they might not consider the commercial product if the open-source version were not available.
Q:
What impact will this move have on the adoption of the Java SE platform?
A:
The Java platform has been very widely adopted already - it is one of the most important and widely used components of modern web-based infrastructure. But there remain un-tapped or under-served markets. In particular, Java technology is not always included in open-source web infrastructure stacks that are commonly distributed and deployed alongside and included with GNU/Linux distributions. Those that do include Java technology often do not include an up-to-date, compatible runtime and development environment. We continue to work with the GNU/Linux distributions to get the JDK included as part of the free software repositories commonly included with these open-source operating system distros. Once the JDK is easily obtained and installed with these platforms, we expect to see more widespread adoption of Java technology especially outside of North America and Western Europe, as well as in cutting edge web infrastructure deployments worldwide. Since the GPL is a very widely used open-source license (in fact it's the same license used by GNU/Linux), distributing the JDK under the GPL with GNU/Linux distributions should be a good match, making it easier to adopt by those looking for open-source alternatives.
Q:
What are your goals in open sourcing Sun's Java ME implementations?
A:
To remain the number one mobile application development platform*, Java ME needs to grow and evolve. This means engaged developers, accelerated innovation, and a more consistent implementation across devices. [* Evans Data Corp. Spring 2006]
Sun believed that sharing led to broader market adoption of Java and that over time that would work to Sun's benefit. But what about the threat of incompatible Java code? The FAQ:
In addition to the specific steps that we're taking to help foster compatibility, we are convinced that the market will demand compatible implementations, and that incompatible ones won't gain traction. With the billions of dollars of Java applications in the installed base, the community has recognized that a Java implementation that doesn't run the installed base of code won't get very far. That is why both the GNU/Classpath and Apache Harmony projects have stated unequivocally that they're working to build fully compatible implementations of Java SE.
And that too answers the judge's question #4. Yes, Android could rename everything, but then it wouldn't "get very far". [Update: Comments are saying it couldn't get anywhere at all, not just not very far. And another comment says that even if all the names were changed, Android would still violate "this made up thing called SSO" because it "would still be violated because the same classes and their parameters would appear in Android. That is what you just can't get around."] Compatibility matters so much that Sun here commended Classpath and the Apache Harmony projects for "working to build fully compatible implementations of Java SE", and how would you do that without the APIs?
Oracle... well, I don't think it yet understands or appreciates the value Open Source brings. Perhaps, if the UK and the EU decide to require open code and open standards, then Oracle will understand the foolishness of proprietary APIs, because who will then be willing to use Java? It's this history of promises and representations made by Sun, relied upon by many, not just Google, that makes suing Google, who relied upon these very representations, so very unjust. That's what law is for, no? Justice? Next week, the trial will begin the patent phase. I have no idea how that will go. I'm not a patent expert by any stretch of the imagination. I don't know if Google infringed Sun's patents or not. If they did, they'll have to pay. My words are specifically about the copyright phase of this litigation. I continue to hope that Oracle will realize how its claims make it look to the FOSS community and make a change. Actually, it's bigger than just the FOSS community. I've seen article after article decrying Oracle's API claims and warning of damage if Oracle wins. Have you seen any articles defending it, other than by people paid by Oracle? I haven't either. I know they don't listen to me, but they should. If they succeed in damaging FOSS and software innovation, by introducing a new field for copyright trolling in loathsome and destructive API litigation, which is what I believe is at risk with its API claims, they will fill a dark page in the history of software development, and the world will surely react unfavorably to Java, at a minimum.
Does Oracle have no desire to sell or license anything in the UK, where APIs were just found to be not copyrightable? How will it sell or license Java to the UK now, even if it wins this litigation? The EU also is determined to benefit from FOSS. Other countries feel the same way. Does Oracle plan on selling only in the US? The arrow is pointing all one way, in the direction of openness. Even Microsoft sees that much and made adjustments, because its clients demanded it. If countries require open standards and open code, would Java qualify? That's an issue Sun was trying to solve by open sourcing its Java implementation. I wonder if Oracle has thought about that. That's what I mean about painting itself into a proprietary corner. If they've thought of it, I see no indication that they care. But it's never too late to do the right thing.
|
|
|
|
| Authored by: bugstomper on Saturday, May 05 2012 @ 08:45 PM EDT |
Please summarize in the Title box error->correction or s/error/correction/ to
make it easy for PJ or Mark to see what needs to be corrected and for other
people to see what errors have already been noted.
[ Reply to This | # ]
|
- commened -> commended [N/T] - Authored by: bugstomper on Saturday, May 05 2012 @ 08:59 PM EDT
- Corrections Thread - Authored by: Anonymous on Saturday, May 05 2012 @ 09:11 PM EDT
- First FAQs, last answer needs linebreak - Authored by: Anonymous on Saturday, May 05 2012 @ 09:13 PM EDT
- becaues -> because n/t - Authored by: Anonymous on Saturday, May 05 2012 @ 10:06 PM EDT
- "Java Technonology Libre Panel" --> "Java Technology Libre Panel" n/t - Authored by: Anonymous on Saturday, May 05 2012 @ 10:12 PM EDT
- The issue isn't whether Google could do that; the issue is what would have happened to compatibi - Authored by: Gringo_ on Sunday, May 06 2012 @ 12:10 AM EDT
- "Yes, Android could rename everything" --> Wrong, they could not. - Authored by: Gringo_ on Sunday, May 06 2012 @ 12:12 AM EDT
- it's never too late > it's almost too late - Authored by: Anonymous on Sunday, May 06 2012 @ 10:09 PM EDT
| |
| Authored by: bugstomper on Saturday, May 05 2012 @ 08:50 PM EDT |
Please stay off topic in thee threads. No Java, unless it is coffee. Perl,
Python, Pascal, or PL/I are ok. Lisp is always fine.[ Reply to This | # ]
|
- Tablets... what size to they start at? - Authored by: Anonymous on Saturday, May 05 2012 @ 09:23 PM EDT
- The MagPi is a community led monthly online magaizine aimed at all things Raspberry Pi - Authored by: Anonymous on Sunday, May 06 2012 @ 03:35 AM EDT
- interesting... - Authored by: SilverWave on Sunday, May 06 2012 @ 07:28 AM EDT
- Judge Alsup's discretion - Authored by: AMackenzie on Sunday, May 06 2012 @ 09:07 AM EDT
- Avengers - Authored by: Anonymous on Sunday, May 06 2012 @ 09:47 AM EDT
- Waiting for Panasonic to sue Nokia - Authored by: Anonymous on Sunday, May 06 2012 @ 03:55 PM EDT
- Hick Deputies Fill in Blanks on FBI Warrant - Authored by: Anonymous on Sunday, May 06 2012 @ 04:01 PM EDT
- LG backs off Windows Phone - Authored by: Anonymous on Sunday, May 06 2012 @ 06:31 PM EDT
- The most astounding fact... - Authored by: Anonymous on Sunday, May 06 2012 @ 07:00 PM EDT
- Kroes Throws in Towel on ACTA - Authored by: Anonymous on Monday, May 07 2012 @ 03:59 AM EDT
| |
| Authored by: bugstomper on Saturday, May 05 2012 @ 08:54 PM EDT |
Please put the title of the News Picks article in the Title box of your comment
to make it easy to scan through the comments. Also please include the link to
the News Picks article in the body of your comment, preferably as a clickable
link posted in HTML Formatted mode for the readers' convenience once the article
has scrolled off the News Picks sidebar.
[ Reply to This | # ]
|
- Nokia takes steps to troll - Authored by: Anonymous on Saturday, May 05 2012 @ 10:26 PM EDT
- ...Designed by lawers - Authored by: mtew on Sunday, May 06 2012 @ 12:33 AM EDT
- Defining Property - Authored by: Anonymous on Sunday, May 06 2012 @ 12:58 AM EDT
- Nokia defends strategy to exasperated investors - Authored by: Anonymous on Sunday, May 06 2012 @ 04:57 AM EDT
- Nokia needs cell phone carriers, period. Can't do it with MS OS and Skype (they hate both). - Authored by: Anonymous on Sunday, May 06 2012 @ 07:14 AM EDT
- Nokia jumps up and down on a frozen lake - Authored by: Ian Al on Sunday, May 06 2012 @ 08:41 AM EDT
- When Nokia's cash flow reaches a crises point... - Authored by: Gringo_ on Sunday, May 06 2012 @ 09:57 AM EDT
- Possible alternative - Authored by: Ian Al on Sunday, May 06 2012 @ 10:56 AM EDT
- Fjord?. - Authored by: Anonymous on Sunday, May 06 2012 @ 11:34 AM EDT
- Fjord?. - Authored by: PJ on Sunday, May 06 2012 @ 12:40 PM EDT
- Fjord?. - Authored by: Anonymous on Sunday, May 06 2012 @ 01:29 PM EDT
- Canadian Bugs - Authored by: Anonymous on Sunday, May 06 2012 @ 02:24 PM EDT
- Canadian Bugs - Authored by: PJ on Sunday, May 06 2012 @ 02:31 PM EDT
- Canadian Bugs - Authored by: JamesK on Sunday, May 06 2012 @ 05:13 PM EDT
- Canadian Bugs - Authored by: Anonymous on Sunday, May 06 2012 @ 06:28 PM EDT
- Canadian Bugs - Authored by: Anonymous on Sunday, May 06 2012 @ 06:31 PM EDT
- DEET - Authored by: argee on Sunday, May 06 2012 @ 11:55 PM EDT
- Hurrmph - Authored by: Anonymous on Monday, May 07 2012 @ 08:50 AM EDT
- DEET - Authored by: Anonymous on Monday, May 07 2012 @ 09:21 AM EDT
- Southern Hemisphere bugs - Authored by: Anonymous on Sunday, May 06 2012 @ 06:21 PM EDT
- Wild Finnish mosquitos - Authored by: Anonymous on Sunday, May 06 2012 @ 07:07 PM EDT
- Fnord?. - Authored by: Anonymous on Monday, May 07 2012 @ 02:52 AM EDT
- Nonsense. It is a perfectlh good item. - Authored by: argee on Sunday, May 06 2012 @ 12:53 PM EDT
- Then, MS has to buy out a cell phone company? Or their friends do it for them? - Authored by: Anonymous on Sunday, May 06 2012 @ 01:17 PM EDT
- When Nokia's cash flow reaches a crises point... - Authored by: symbolset on Sunday, May 06 2012 @ 01:32 PM EDT
- Judge Alsup: how to drive from San Francisco to Monterey - Authored by: Anonymous on Sunday, May 06 2012 @ 01:57 PM EDT
| |
| Authored by: bugstomper on Saturday, May 05 2012 @ 08:58 PM EDT |
Please post your transcriptions of Comes exhibits using full HTML markup but
posted in Plain Old Text mode so PJ can easily copy and paste your work.
[ Reply to This | # ]
|
| |
| Authored by: feldegast on Saturday, May 05 2012 @ 09:08 PM EDT |
| https://twitter.com/#!/Feldegast -
--
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use. [ Reply to This | # ]
|
| |
| Authored by: pem on Saturday, May 05 2012 @ 09:16 PM EDT |
Is it “compatibility” with programmers who write in the Java
programming language? Or compatibility with pre-existing programs?
Programs often have to be "tweaked" for a new environment.
If you're lucky, that tweaking can be done in such a way the program still runs
fine in the old environment. Gnu autoconf is a system for doing this sort of
thing for C/C++.
But Sun's premise that Java itself is write-once/run
anywhere is obviously false. Even pure Java non-Android programs will often
have code in them to "discover" their environment and configure themselves. How
big is the screen size? Is there audio? Making a program that "just works"
without any effort on the part of the programmer has been realized -- if all you
want is a simple text interface.
To the extent that new environments exist,
it's good to make them as similar as possible to the old environments. This
results in less effort spent porting existing programs, and less effort writing
new programs that work in both environments, and less rote memorization of
stupid niggling little system differences for the poor programmer.
Good
software is all about reuse. Software is different than building a physical
product. With a physical product such as an iPhone, there might be a few
hundred designers and tens of thousands of production people. With software,
the designers and production people are often the same. They can be infinitely
more productive if they have preexisting concepts and implementations of those
concepts at their fingertips.
Open source software, in particular, is a
promise that you can reuse an implementation without fear, as long as you follow
the license. If you don't like it, build your own and license it the way you
like. It was long assumed that the concepts were reusable in any case, but
Oracle seems bound and determined to change that. Half of what they are suing
over is a reimplementation of tried and true functionality they borrowed from
other languages.
[ Reply to This | # ]
|
| |
| Authored by: jbb on Saturday, May 05 2012 @ 09:21 PM EDT |
| Here is a very simple solution for Judge Alsup. If you have a
list of
unprotectable things and the order of the things in that
list does not matter
then the list itself is unprotectable even
if people use the same or similar
order.
I think this might be the core of the problem. I realize it
might
be too late for this trial but IMO Google should take a simple API with
less
than 100 declarations and present those declarations in different
orders
such as alphabetical, by length, etc. and show those to a
witness and ask the
witness if those are the same API or not and
if they would all be infringing if
there was a copyright on one
of them.
The judge could call it his "order
order". I think he would like that.
---
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 | # ]
|
| |
| Authored by: Anonymous on Saturday, May 05 2012 @ 10:20 PM EDT |
From comment by Anonymous in the Corrections
thread
...make me wonder what would happen if Oracle did
wi(n)
the copyright case because it would give IBM a clear road to shut them down for
using SQL without a license and that would truly be a sweet
victory.
Really? Was the SQL API designed by IBM? [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, May 05 2012 @ 10:34 PM EDT |
Compatibility is a marketing word. For instance, I used it a lot when nine
years back I converted the small company I worked at from Office to
OpenOffice.org. What I meant then was that for the types of things my
co-
workers
did, OpenOffice.org opened and produced files that were close
enough so that
our clients wouldn't know that we didn't use Word. I used
it because I
was asking
them to do something new and somewhat different and
these things fail unless
you get buy-in which you do by minimizing the
inconvenience and emphasizing
the positive. And deliver in a proximate
ratio. I note that Judge Alsup
was asking the parties to the suit
for
some clarification as to how
they were using the word. Within the context of
what I understood
Google to be doing with Android, I think their use of
compatible would mean
that were I a software company, I'd be able to hire
people who
had a background that was useful for the Android development
environment,
and who could focus on what was new, since they had a fundamental
understanding of
the java idioms and metaphors. This might give Android a
first look from me as
java folks are easier to find than Objective-C folks for
the going like
gangbusters iOS platform. Having folks who knew java would
reduce my time
to market, and mean I could pay my developers less, because of
supply and
demand. That
said, I suspect the ability to use Eclipse (java IDE
from IBM) for Android
development and Android growth curves about month 18
would be more eye-
opening to me than Google's launch rhetoric. As to
whether
the source code we develop is TCK, jvm, or java compiler compatible,
that
would matter very little. Reuse of library code is nice, but at the end of the
day,
the goal is to make a profit from revenues after subtracting development
and
marketing costs for this year's product. Future reuse of the new code is a
bird
in the bush.
Disclaimer: I am not a professional developer, though
I have gotten paid for
software writing and maintenance. With regards to
Sheriff Oracle, I
don't know if it matters if Sun was cringing in the saloon's
corner or pouring the
drinks (unless there is a real point regarding estoppel
that Google didn't launch
or was told wouldn't fly). The new Sheriff is
enforcing the law that members
only are drinking in private clubs on Sunday.
Apologies for the sloppy metaphor
and pun. Think of all
the Court's time saved
(and savings to Oracle's shareholders) if on the day
Schwartz's blog hit the
webs, Google had called up and gotten a signed piece of
paper to codify what
Schwartz implied. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Saturday, May 05 2012 @ 10:35 PM EDT |
> 13. When discussing use of the SSO in the 37 API packages in Android to
achieve “compatibility,” what exactly are the parties referring to? Is it
“compatibility” with programmers who write in the Java programming language? Or
compatibility with pre-existing programs? If so, approximately what percent of
pre-existing programs written for the Java platform are compatible with Android?
Is it compatibility with the TCK? Or Java virtual machine? Or java compiler?
Yes, it helps the programmers. It also helps people porting pre-existing
programs. They can't use the TCK due to licensing nonsense, so I'm not sure
that has ever been a concern, though if it was, they would need to use the
names. Dalvik uses its own VM and compiler, so I'm not sure what
"compatibility" means there. Insofar as it means that Google's
compiler can be fed the same source code, then yes, it's for compatibility there
too.
I have no idea what percent of programs work, but if Oracle owns even the name
java.lang.Object, I know that nothing would work at all, unless perhaps someone
can find some incredibly contrived example to the contrary of no real world
importance. I suspect that a lot of programs need modification, depending on
the environments they've come from. Google has tried to make the amount of
modification small, or even zero for as many programs as possible in the name of
keeping compatibility. But the incompatibility would be the fault of the new
environment (e.g. smartphones have tiny screens), something outside of the
control of Java itself, rather than because of some choice Google made in naming
something.
There simply wasn't any reasonable way for Google to avoid using these names
except to avoid using Java entirely. Personally, I'd like to see a ruling that
this was fair use, but it looks like the jury has to decide that part and who
knows what they're thinking.[ Reply to This | # ]
|
| |
| Authored by: jbb on Saturday, May 05 2012 @ 11:05 PM EDT |
| I borrowed some of this from a previous post
here.
Compatibility with Existing Code
If
you look at entire applications then, sure, the amount of usability between
Android and other Java applications would be near zero. But 99% of the time,
that is not how existing code is re-used. Blocks of code that perform certain
tasks are what get re-used most of the time. There would be a HUGE amount of
overlap with these blocks. This is close to the essence of good programming.
Code is made up of blocks within blocks within blocks.
This layering is
usually achieved with method (function) call just like the method calls in APIs.
A single API method call in an application program will substitute for hundreds
or thousands (or more) lines of code from the API library. This same thing
goes on inside the application itself. Methods (functions) that contain many
lines of code (and other method calls) are created and then used with a single
line of code elsewhere that calls the method. Experienced programmers will
often have their own little libraries that they have developed over the years.
The big promise Sun made was that as long as you only used the "core APIs"
then your personal library of code would be able to run on any system that ran
an official version of Java. This was one of the main attractions of Java. The
exact APIs included in this promise are specified in Sun/Oracle's own TCK. This
is a large number of APIs and it includes all the accused
APIs.
Compatibility in Future Programs
Going forward,the key
thing with API compatibility is
developer head space.
Good developers hold the
APIs they are using in their heads. The API calls can just stream from their
fingers. Forcing them to use two different APIs to do exactly the same thing in
very similar contexts would violate one of the most fundamental rules of
programming. It would not make things 2x harder (because you now have to keep
twice as much in your head), it would make things 100x harder or worse because
of the tremendous risk of confusing a call in one set of APIs with the matching
call in the other set of APIs. Even worse, if Google only changed the names so
the translation between the two system was easy and could even be mechanized
then the SSO of the Anrdroid APIs would have to be the same as the SSO of the
Java APIs. I don't know what the SSO of an API is but the judge has already
ruled that it doesn't include the names because names aren't protected.
Imagine what would have happened if in 2007 Google did exactly what Oracle
is now insisting they should have done: release new, totally incompatible core
APIs in Android. Sun would have screamed bloody murder and rightly so.
Releasing incompatible core APIs would have truly fractured the Java community.
It would have been very difficult for developers to switch between using
Sun-Java and using Android-Java. There would be almost no code reuse between
the two systems. Anyone who tried to switch from one to the other would
generate tons of bugs as they tried to get their fingers accustomed to the new
system. It would be like changing around the keys on the keyboard. You could
eventually get used to the new layout but the transition would be difficult and
your productivity would plummet every time you switched from one to the
other.
If Google had released incompatible core APIs then Sun would have
pointed to Harmony and OpenJDK and GNU Classpath as examples of open source
implementations of the core APIs that were compatible with standard Java.
Google's move would have been seen by everyone in the tech community as
extremely hostile. They would have been called out for violating their motto
"don't be evil". Even if there was only a sliver of a chance for success Sun
would have instantly sued Google over making non-compatible core APIs. Many
people would say that Google was being worse than Microsoft. These people would
have been correct. Releasing incompatible core APIs on the Android platform
would have been the meanest, nastiest, most deadly attack Java ever encountered.
Oracle is now insisting that Google pay them tons of money for not launching
this possibly fatal attack on Java.
---
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 | # ]
|
| |
| Authored by: Anonymous on Saturday, May 05 2012 @ 11:34 PM EDT |
Q: Can someone create and distribute an implementation that
isn't
compatible with the Java specification using this
code?
A: Yes. We do not
recommend or endorse that action,
however.
In addition, they cannot label that
implementation with the
Java Compatible or Java Powered (for Java ME) brand and
logo. These brands are your assurance that an implementation
has passed the
relevant TCKs.
Which is in fact how Android itself basically
works:
http:/
/source.android.com/faqs.html#what-does-
compatibility-mean
[ Reply to This | # ]
|
| |
| Authored by: Gringo_ on Saturday, May 05 2012 @ 11:38 PM EDT |
I think that answers one of the judge's
questions. But what do
you say? I think it also partially
answers question 4, about whether Google
could have come up
with different names and SSO yet still have provided the
same functionality as in Android. The issue isn't whether
Google could do
that; the issue is what would have
happened to compatibility had they done
that. It's not
just Android developers that would have been affected. You
have to think about all the world's Java developers.
"the
issue is what would have happened to compatibility
had they done that" - That
is incorrect. You are missing the
point completely here. Google could not have
come up with
different names and SSO, because you simply couldn't use
Java
anymore. It wouldn't compile even if they changed just
one letter in each name,
not alone the SSO. You haven't been
following the discussion on this point, and
I think it is
essential we be clear on this, because the fudsters will be
saying "Google could have used their own names and SSO, but
they chose to
steal Oracle's instead!" Make no mistake about
it - change the names and/or SSO
is not an option. The only
option is what they did, or write a whole new
language.
Without its libraries, Java is not a language - it is
nothing -
there is nothing there. Without the "Class",
without "Object", you can't write
any code.
And that too answers the judge's question #4.
Yes,
Android could rename everything, but then it
wouldn't "get very far".
Compatibility matters so much that
Sun here commended Classpath and the Apache
Harmony projects
for "working to build fully compatible implementations of
Java SE", and how would you do that without the
APIs?
"Yes, Android could rename everything" No - they
could
most definitely not! The only choice is - use Java, or use
some other
language. There is no such thing as Java without
its libraries - its
API.
It has been suggest that maybe you could rename the
classes and
methods in Harmony, then could use some kind of
interpreter to connect the Java
classes to Harmony. However,
if you examine this system as a black box, it
looks exactly
the same as before - with the same names and SSO no matter
what
you do.
I just think it is so important that everybody understand
that
for reasons I cannot fully articulate. For example, we
don't want the judge
thinking Google could have done that
but chose not to. This would not bode well
for Google or the
future of software development. [ Reply to This | # ]
|
| |
| Authored by: artp on Saturday, May 05 2012 @ 11:45 PM EDT |
Not only does Oracle want to have their cake, eat it, and
sell it to the highest bidder, but it wants to tax the rest
of us for watching the auction.
It sticks in my craw that the 9 lines of duplicated code (I
really will get back on topic shortly) were written in two
different places for two different employers by the SAME
PERSON!
There is a unanimous agreement among corporate bodies to
believe that they own the skills of the people that they
hire. I can't take a skill that I learned at one company to
another and use it. I have to pretend that I don't know it,
even though it was my previous abilities that allowed me to
learn it in the first place. In the engineering field, it is
almost always the case that the innovation came from the
employee.
Corporations drone on about best practices and reusable code
and doing more with less (my personal favorite meaningless
slogan!). Yet when we take it to the logical conclusion,
they make a fuss.
To get back on topic, I haven't heard anyone talk about
reusable code, about the right of an employee to practice
his trade, about the necessity of having talented employees
who can learn and innovate, or any number of things that are
important to how WE do our work. As we write code, or
practice any other technical skill, we learn what works,
what doesn't, and where we need to use each one. We develop
an arsenal of specific applied skills that we can pull out
when a common problem pops up. That is the definition of a
craftsman -- knowing when to use each tool in the best
manner possible.
These things were far more important back when the
Constitution was written, because the US was a nation of
tradesman, craftsman and freeholders. Today, so many people
are employed by corporations that these freedoms are at
great risk of fading away.
I really do wish that SOMEONE at the two attorney's tables
had mentioned the right of an a employee to practice his
trade. It would not have gained any traction, but that is
the tragedy that I am concerned with. We have become a
nation of employees instead of a nation of free men. Nobody
wants to take any risk.
When someone can't use 9 lines of code that they wrote, then
freedom is truly gone.
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 12:26 AM EDT |
It is important to recall that 'Java' is two things. It is both a language, and
a JVM specification. It doesn't work like C or C++ -- you do indeed create a
text file that calls an API, but that does not get compiled into ELF format
(binary), but rather into class files, which are rather more byte oriented.
Thus, talking about APIs and compatibility may be a bit misleading, if your core
paradigm is native C/C++ and execution means loading ELF. It's rather closer to
the ABI -- application binary interface.
The JVM governs how classes are stored in the class file, and how they are
loaded. The most basic form of compatibility is a method call that looks up an
'mangled' class name (C++ concept, not Java, but similar and specified) in a
string table at the start of the class file. The string has, textually and byte
by byte, the package and class name, and codes representing the signature type,
including *their* string representations, if they happen to be classes.
Unlike 'symbol tables' in a C compiler, these are strings that actually must be
the same at run time, and have the same signature, to 'match'. The reason is
because cross-language calls are not contemplated, and the JVM spec takes the
easy route and uses language control to avoid the indirection of a symbol
table.
It is possible to hook this loading mechanism and provide a custom class loader
that does not just 'look up the name in the string table' then go looking for a
class with that name on the class path. There are other very common cases where
more than just invoking a class by the most straightforward JVM mechanism is
done. Thus, it might be worthwhile to enumerate 'use cases' and discuss how
compatibility is affected in each case.
However, basic Java compatibility was always meant to be a the *byte code*
level. If the class names and signature types, including the class names of any
invoked classes, do not match, something fundamental about compatibility, which
is part of how the Java language and the JVM are intended to both work and work
together, has been broken.[ Reply to This | # ]
|
| |
| Authored by: maco on Sunday, May 06 2012 @ 12:46 AM EDT |
Apparently Oracle way overpaid for Sun.
Oracle have dumped Open
Office.
Oracle are dropping a lot of Sun hardware.
The supposed star,
Java's phone IP, is proving worthless as
well because of Sun's previous
actions.
Oracle is in court trying to recoup what it thought it had
purchased from sun. Who would have led Oracle to believe
other than Ellison's
good friend, McNealy.
So of course McNealy is lying. He's the one
who
helped
con persuade his "good friend" into
purchasing
Sun. Who knows what he claimed, and now, what is
forced to "substantiate" in
court.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 12:47 AM EDT |
Google has actually not done a very good job of explaining the necessity
for
compatibility to the
judge.
Apache Harmony isn't the only project at
the Apache Software
Foundation. In particular, Apache Commons is quite popular
with Java
programmers. Without basic API compatibility developers on Android
would
have either
- had to create Android specific versions of all the
Java open source
projects they would like to use or
- create a tool to
change the names
of the system APIs in the jar files before they could be
used.
Of
course, I'm sure some sort of tool could have been included
with Android to
do this but it would have likely created a mess
A second
consideration are the Interactive Development Environments
(IDEs) developers
use. They understand the Java language and understand
that java.lang.String
does not have to be imported into a Class. It would have
created a barrier to
acceptance if Android's packages would have to have been
named
android.lang. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 01:47 AM EDT |
Compatibility with the Java API on Android, even if only an important subset, is
less about allowing Java programs to work on Android without change (which is
what Oracle wants in addition to the extra cash they need to make shareholders
happier). But more about allowing the hundreds if not thousands of pre-existing
Java based class libraries to be compatible with Android (which is what Google
wants in addition to making it easier for people who were familiar with Java to
pick up Android application development). These class libraries are not owned or
developed by Sun. These class libraries are developed/own by other companies
(including Google, IBM, ... etc), organizations (including Apache) and
individual developers.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 02:10 AM EDT |
The primary reason for maintaining compatibility with the Java API's were to
allow Java programmers to port their existing applications over to Android
fairly quickly without having to change every API call. Additionally, have
familiarity with the Java API's also allowed you to develop more quickly, but
this is debatable as adjusting to new API's isn't really that difficult nowadays
with the code completion tools most IDE's ship with.
Google doesn't call their version Java so how does Oracle even have a leg to
stand on? Had Google called their implementation Java then there would have been
an issue, but they don't so why are we here again? This is simply a last ditch
effort from Oracle to try and extort money from Google by preposterously
claiming that method declarations fall under copyright. This is not only a
despicable maneuver, but it goes against the moral conscience of every
programmer. Any programmer that works for Oracle must truly be disgusted with
what they're trying to do.
Oracle is trying to do what SCO did and they failed miserably. History shall
repeat itself again. It does make me wonder what would happen if Oracle did win
the copyright case because it would give IBM a clear road to shut them down for
using SQL without a license and that would truly be a sweet victory.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 03:15 AM EDT |
>because who will then be willing to use Java?
>How will it sell or license Java to the UK now, even if it wins this
litigation?
This would only be significant if someone else wanted to *re-implement* the Java
API's would it not? Of course most users of Java do not re-implement the API's.
I can (do in fact) use Oracle's Java in the UK - I can't see this litigation
(which I actually strongly oppose and hope Google prevail) having any effect on
that particular aspect.
[ Reply to This | # ]
|
| |
| Authored by: reiisi on Sunday, May 06 2012 @ 03:58 AM EDT |
If and only if Java had a macro-preprocessor like C, you could define a set of
macros that mapped Dalvik APIs to Java APIs. And you could give Dalvik a
macro-preprocessor, and write a set of macros to reverse the mapping, from Java
APIs to Dalvik.
Of course, that not only fails to answer the question, but it also opens a whole
new can of worms.
If you do such macro conversion, the combination of macro-preprocessor and the
macro definition files will be just as infringing as the current Dalvik
implementation is.
That is, if the jury says 10%, then the conversion macro-preprocessing stuff
would have to be 10% infringing. Dalvik itself could be separated from the
infringment arguments, but the macro-preprocessing stuff could not be.
But then there is that other can of worms, that I sometimes complain about.
Lawyers would notice that the macro wall appears porous to them. They would miss
the point of the conversion, and assume that macro-coated Dalvik infringes
because Dalvik (even with deliberately different APIs) itself infringes, and
pretty soon Oracle's lawyers would come after Ruby, Lua, and any other language
more recent than Java, because all such languages can (in theory) be
mechanically converted back and forth. One successful conversion, and it's offf
to the races.
The reason software and other literature/fine art were supposed to be kept out
of the patent pool is precisely this possibility of conversion. When you start
abstracting things out to this level, everything becomes everything else. The
patent with highest precedence is the dictator of the world, and, I'm not
speaking metaphorically, I do mean the Constitutions of all Constitional
government be damned.
Why am I suddenly talking about patents? Precisely because the argument about
copyrighting APIs destroys the barrier between copyright and patent. Yeah. I
mean that if you can claim and enforce copyright on APIs, in a few years some
lawyer is going to twist that to the plots of novels, and so it goes.
If and only if we could get the lawyers to forever agree not to try to expand
their patents, we could allow source code to be patented on the condition that
changing one variable name must be considered equivalent to changing the shape
or composition of one physical component, and that changing the compiler or
run-time library would be equivalent to changing the physical implementation
framework, and that changing the language would be equivalent to a complete
re-implementation of the device in different technology, and completely beyond
the claims of the patent. And the entire source code would have to be registered
and published, just the same as the blueprints have to be registered in
physically implemented patents.
Otherwise, you absolutely will open the door to abstracting away all barriers to
frivolous litigation, and it's just a matter of time until the entire economy
comes grinding to a halt under the burden.
And, now that you think about it, copyright is always a better fit for software
than patents, when you place the proper requirements on software patents. The
only real issue is how to protect a combination of software and machine, but
even that is going to require a lot more specificity than is currently
practiced, because a CPU can be used as a basis for arguments abstracting the
patent out of the physical implementation.
Symbols are inherently abstract.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 05:42 AM EDT |
Reading there is further evidence in the referenced recording showing Oracle and
some of their witnesses should have known better that to make big
misrepresentations to the court about Sun's view back in 2007/8, where is the
justice by not allowing these recordings into evidence at this stage? What law
stops it's inclusion or a mistrial? And what's to stop the court/dpp also
bringing charges against those that falsely testified knowing the correct Sun
viewpoint as indicated by these recordings back in 2007/8 during the java
conference?
Where is the justice? Or is the law so far removed from the concept of
justice?
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 05:50 AM EDT |
| It makes it clear that there is no case. [ Reply to This | # ]
|
| |
| Authored by: Ian Al on Sunday, May 06 2012 @ 06:30 AM EDT |
13. When discussing use of the SSO in the 37 API packages in Android
to achieve “compatibility,” what exactly are the parties referring to? Is it
“compatibility” with programmers who write in the Java programming language? Or
compatibility with pre-existing programs?
My reply has been
delayed by the need for Zen meditation... and a search through the comments. The
meditation lead me to the comments... it was the meditation that was important.
Brain the size of a planet and I have to consider Oracle's twaddle! I'm so
depressed.
dcs channelled my meditative thoughts when he
wrote:It's not so much compatibility with existing programs as
with existing libraries and frameworks.
I'll give two simple
examples.
The situation is such that if you ask any experienced Java
programmer about how to do something with dates or times, he
will most likely
tell you to use JODA Time...
Unless Android supports Java's API for
Date and Time, someone writing a program for Android cannot
use
JODA.
For Java, one tool, called a "testing framework", got so
popular that not only alternative tools had to provide *APIs
compatible with
it* (never thought about that until now),
but it inspired similar tools for
other languages. This tool
is called JUnit.
If the API used by
Android was different than the
API used by Java, one could not test code
written for
Android using JUnit in a reliable fashion, as the libraries
used
by JUnit and the tested code would be different.
Like these two, the
are many more examples. One of the
greatest advantages brought by Java over
previous language
was precisely how easy it was to use libraries provided by
third parties.
Then there is the evidence given to the jury by
Scott McNealy. He referred to the swing APIs. They could not work without a good
number of the 51 APIs in Java SE and also in Android. In fact, they were so good
they were eventually folded into the Java SE core APIs.
All those
popular third party libraries including those that have been folded into the
core over time (javax?) rely on the core APIs being available. It is not
possible to guess in general terms which of those are essential. Google decided
that 51 of them were the best set for Android devices.
It is essential
that large parts of the core are available both for new programming, development
of new libraries to put right the existing faults in Java and the support of
existing third party libraries that have been found essential to make the Java
SE platform in any way a fully functional cross-platform middleware
solution.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | # ]
|
| |
| Authored by: Ian Al on Sunday, May 06 2012 @ 08:11 AM EDT |
If Sun had kept the Java SE Specification secret, only Sun could program in the
Java language. They could have licensed out the Specification, at a price, and
then third parties could program.
The only way to make a market for
that product was to give away (free as in beer) the Java Runtime Environment to
allow John Doe to run those paided-for third-party programs. They could not have
been free. The third party needed to recover development and licensing
costs.
A third party who did not want to pay Sun for a licence could
legally deduce the API Specification from the operation of the proprietary
program and use it to write their own programs. Mind you, that would only be
feasible if someone also published books like Java in a Nutshell to explain the
use of the APIs and the syntax of the Java language. There are limits to what
you can deduce from the operation of a program.
If Sun decided to
expand the walled garden in the face of this legal avoidance of its licence, it
could have published the Java SE Specification and the Java Language
Specification. Both documents would have been functionally necessary for program
and programming compatibility and would also be a statement of fact about
language and API. They would be no more copyright protectable than the third
party derivation of the same.
That third party derivation was direct
from the functionality of the program compiled code. By definition, it could not
contain any creative expression fixed in a media and copied by the third party.
Copyright of a document could not, by definition, be infringed because there was
no document to copy. The compilable code could not be infringed because the
compilable or compiled code was not copied. Only the functionality was
deduced.
Could inheritance have been visible in the deduced API? No,
because the API does not include any inheritance processes or functionality. If
you create a programming object in any class, it acquires the properties of that
class. It does not hunt through senior classes to collect its property
set.
Could the fact that the language is OOP be determined from the
API? No. Programmers might use their knowledge, skill and judgement to come to
that conclusion, but they could not see that in the API. The same applies if Sun
publishes the Java language syntax. It is only apparent to language experts. Sun
would have to add explanatory text to tell programmers that oop was in play.
Programmers would only be able to use their knowledge of earlier oop to know
what this meant.
Oracle are suing over something not apparent in a
deduced API. A deduced API cannot, by definition, copy creative expression. The
judge has decided that this something is available to be copied from the
documentation included in the compilable code written against the
API.
The legal principle that this discloses is that both a deduced and
a published API are legally untrammelled by copyright in order to make third
party programs compatible with a proprietary program.
Oracle are
claiming that copyright prevents that same API from being used to implement a
replacement to the proprietary program. However, their argument boils down to
copying of the creative expression included with the proprietary code. Because
the published API Specification is both totally fact and totally functional,
they cannot base their claims on it.
The reason that Oracle's claims
fail and that all such comparable claims will fail is because Oracle never
published the proprietary source files from which the included creative
expression could be copied.
Which just leaves the Sun endorsed, free
and open source, third party implemented version of their proprietary,
compilable, API library code. Harmony only had access to the API Specification -
fact.
No, fact, functional and unprotectable by copyright law.
They did not have access to the proprietary compilable code files that
included the protected creative expression. They, absolutely, would have refused
such access even if it was offered by Sun, at the time. The only way that they
could claim full copyright on their work is by clean-room
implementation.
Oracle proved that all 51 of the API implementations
used by Google were completely free of accusable copying. The implementations
used Harmony's API documentation code with Harmony's compilable code. The only
additions to all the help documentation on the Android website that related to
Java was ideas copied from Java in a Nutshell and other publications as
testified by Dan Bornstein.
Google: How did you go about
learning how to program in Java?
Dan Bornstein: Read books. "Java in a
Nutshell," and "The Java Language Specification" (James Gosling and Bill
Joy).
Do you remember reading all those Dalvik help files on the
Android website? Dan was the lead author for that lot.
Didn't I tell
you that Oracle were blowing smoke! Oh, no I didn't tell you
that.
Oracle are blowing smoke.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 08:53 AM EDT |
>> I don't know if Google infringed Sun's patents or not.
Of course Google infringed Sun's patents. Software patents
are designed to be infringed upon regardless of the
programmer knowledge or intention. One can say that Oracle
has infringed Google's patents.
In the mind of the software community the question is not
who infringed on a software patent but rather who has, with
straight face, brought up such a claim for offensive
purpose.
'nough said.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 09:17 AM EDT |
"SCO tried to change the terms of the deal retroactively too."
You claimed to be able to change the license that comments had been posted under
some time after the event.
Why are they wrong and not you?[ Reply to This | # ]
|
| |
| Authored by: feldegast on Sunday, May 06 2012 @ 09:53 AM EDT |
sun document still accessable saying java forks are ok
http://sosc-
dr.sun.com/software/opensource/java/faq.jsp#g24
Q: Can someone
create and distribute an implementation that
isn't compatible with the Java
specification using this
code?
A: Yes. We do not recommend or endorse
that action, however.
In addition, they cannot label that implementation with
the
Java Compatible or Java Powered (for Java ME) brand and
logo. These brands
are your assurance that an implementation
has passed the relevant
TCKs.---
IANAL
My posts are ©2004-2012 and released under the Creative Commons License
Attribution-Noncommercial 2.0
P.J. has permission for commercial use. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 10:14 AM EDT |
1. Google wanted Android to be compatible with Java programmers head space
2. Oracle want Android to implement all 166 packages, be called Java, and pay
the toll. Compatibility in this sense means "to be Java".
It doesn't really matter what anybody else thinks "compatible" meant
for Java.
Compatibility is a spectrum, Google and Oracle are at two different places on
it.
My pen writes on paper and on cloth, but it does not write on glass
Oracles pen is a different pen that writes on glass as well as paper but not on
cloth.
I do not need to be able to write on glass, so I don't care one jot about
Oracles pen.
I do concede that our pens look very similar, they perform similar functions
they have the same interface.
They are not the same pen.
The pens could be said to be compatible, in the paper domain, yet Oracles pen
is not compatible with my cloth writing pen, also looked at from another
perspective, my pen is not compatible with Oracles Pen, it does not write on
glass.
If we restrict forms of expression to paper, I could freely interchange my pen
with a (say) Chinese person who had an Oracle pen.
We can both write on paper. There is clearly compatibility.
Our writing however is not compatible, despite using similar devices and the
same interface, no communication is possible because the symbols used are not
the same.
(A subset of) Java Language is compatible with Android
Android is not compatible with Java(tm) Programs
Oracle could choose to port Java to Android in the same way that it has been
ported to Windows/MacOS/Unix/Symbian
(it is made considerably easier by the fact that Android is already compatible
with ~400 java classes)
And then Android(+Java) would be compatible with Java.
Or Oracle could dissemble and use the law to force somebody else to do it.
As for Q4(SSO), It is related to the question of compatibility, but there is too
much nitpicking going on, the judge is actually (almost) factually correct in
the question that he asks (I am ignoring the Spring part)
first the question again...
"4. Could Google have come up with different names and SSO yet still have
provided the same functionality as in Android? Android users would have had to
learn a new vocabulary and a new outline but the methods would all still have
been resident in such a modified Android. True?"
The key part is in the second question, "Android user would have to learn
a new vocabulary".
Yes, this is software, Google [still] could have re-implemented every one of the
400 classes('thing' concept) with different names in one great bloated
package(library concept) with no hierarchy(tree concept) called...
UsefulStuffDevelopersExpect2BeThere (USDE2BT for short)
Some vague similarity in names would still exist at the class level, after all
an Array is an Array (and is a well understood concept) and a Buffer is a Buffer
(and isn't what you think it is, it's another concept), and you wouldn't call
Zip anything else, any more than you would call your Toyota a
FourWheeledRoadBasedTransportSystem for fear of stepping on Fords idea of 'Car',
and is why names are not protected, but there would be no sign of the
insubstantial concept of the/Oracles SSO.
Android Users would not be affected in the slightest, they would not know the
difference.
Android developers would indeed have to learn a whole new vocabulary in order to
program for Android, and any existing code that was written in Java that a
developer wanted to reuse would have to be ported to the new vocabulary in
exactly the same way that Python code could/would be ported to Java if you
wanted it to run on Android (ignore the NDK for now).
It would be necessary in such circumstances for Google to change the way the
virtual machine works for the new vocabulary and they would also need to develop
additional tools along the tool chain.
e.g. javac compiles <source-code>.java files into
<source-code>.class files which are processed by dex tools for Android to
<source-code>.dex (I assume, this part is opaque to me, in part because I
can't be bothered to look,IJW)
Obviously javac does not have the vocabulary for our new USDE2BT package, and
javac expects certain things like quoted "Strings" to be exactly
something special and so would probably no longer do anything terribly useful.
Writing an AndroidC(ompiler) to process <source-code>.android files that
use the USDE2BT vocabulary is entirely possible and just a piece of work
(think: if you can do it for perl/java/basic/ruby/C/C++/C#..ad nausea then it
follows...).
In this instance you'd probably end up skipping the <source-code>.class
step and go straight to the <source-code>.dex with AndroidC.
Writing a tool to convert existing Android <source code>.java files to
<source code>.android files would be relatively trivial and contrary to
various assertions made, it would not infringe any mythical SSO that Oracle may
own, it would only need a map of unordered names, it is conceptually no
different to a text editor/word processor search and replace function.
At this point, you now have an Android system that is independent of Java and a
pile of (relatively) unhappy programmers. Android programmers now write software
in a new language which is 'java like' in its syntax and awkwardly not 'java
like' in it's vocabulary.
Anybody who has programmed regularly in both C++ and in Java knows how awkward
this is. Anybody who has switched between Battlefield 3 and CoDIV(?), or a PS3
Controller to Xbox Controller knows how awkward this is.
You have to switch to a different conceptual framework and you will make
mistakes.
<wild speculation>
2 Days after the SSO has been removed someone will port DalvikVM to
Windows/Unix, the whole world switches to Android and ASUS releases a PC that
boots to Android and runs Win7 in a VM and Java is belly up in the water with
it's eyes pecked out.
</wild speculation>
This is software, everything is possible (with access to enough processing power
and storage), some things however are just not sensible.
When an Englishman steps of a boat and meets a Native American, they do not
invent a completely new language to communicate.
When a Spaniard rocks up to join the party, they do not throw away well
established communication symbols and invent another new language suitable for
everyone.
When they are joined by a German, they do not start all over again with yet
another new language.
When a Frenchman turns up and declares that everyone is doing it all wrong and
the only way is his way and his language should be the one used, you would not
likely everything and switch to his language.
The correct response is to give him the wrong directions so he ends up lost in a
forest in Canada and promptly ignore him.
The Native American is Android
English happens to have absorbed a few French words
Oracle are playing the Frenchman
Android can switch to Italian (if it has to)
And that is the conceptual context for the compatibility question.
(With apologies to any French, Canadians or French-Canadians and Native
Americans reading)
[ Reply to This | # ]
|
- Wrong - Authored by: Gringo_ on Sunday, May 06 2012 @ 12:48 PM EDT
| |
| Authored by: IMANAL_TOO on Sunday, May 06 2012 @ 10:58 AM EDT |
James Gosling, the creater of Java recently criticized
Google who 'totally slimed SUN'. In another interview Gosling (JG)
said:
EA Our audience consists of practitioners. Should
they be thinking about writing interpreters instead of just writing the
code?
JG The performance of many situations when people use these
interpretive languages is actually not a big deal, mostly because the individual
atomic operations in some of these languages are themselves fairly heavyweight.
There are things like filling a polygon or drawing a string, and on top of that
adding a few instructions to interpret the invocation of an imaging operation,
that’s relatively low cost. But there are other ways to do it. For example, one
technique that people use to get really good performance, rather than writing
their own interpreters, is leveraging off one that exists already.
A
common one to use is the Java Virtual Machine. There are things like Jython,
which is a Python compiler that instead of compiling for the Python virtual
machine actually generates Java bytecodes. That way they get a more
dynamic-feeling language, but it sits on top of the Java Virtual Machine, and so
they get to leverage off all the work that gets done in that
optimization.
EA Do you know if any other languages have done the same
thing?
JG There are several hundred of them. People have done things
like ML compilers that compile down to Java bytecodes. You can even find Fortran
and Lisp compilers that do the same thing.
EA I’m curious about your
opinion of some of the other languages that in some sense overlap Java. Notably,
C#.
JG They did such a job of copying Java, it’s hard to criticize
them. Imitation is the sincerest form of flattery.
What? There
are hundreds of other platforms doing the same thing? And many of those overlap
Java? But here it is flattery? Ok...
But, I had never heard of
Jython.
Reading Wikipedia
on Jython:
Jython, successor of JPython, is an
implementation of the Python programming language written in
Java.
Jython programs can import and use any Java class. Except for
some standard modules, Jython programs use Java classes instead of Python
modules. Jython includes almost all of the modules in the standard Python
programming language distribution, lacking only some of the modules implemented
originally in C. For example, a user interface in Jython could be written with
Swing, AWT or SWT. Jython compiles to Java bytecode (intermediate language)
either on demand or statically.
On 3 March 2008, Sun Microsystems
announced they had hired Ted Leung and Frank Wierzbicki to work on Jython and
Python, similar to Sun's hiring of two JRuby developers.[2][3] Development
progressed steadily,[4][5][5][6] and Jython 2.5.0 was released on June 16,
2009.
Hhhh?! It can import and use any Java class? And it is based
on Java classes instead of Python and it compiles to Java bytecode either on
demand or statically.
And SUN even hired people to promote
it!
Didn't the Judge hear about
this?!
---
______
IMANAL
. [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 01:52 PM EDT |
Being a sensitive soul, I find myself moved nearly to tears just thinking about
the spare creative beauty of the Java API.
My simple mind struggles to imagine what it must have been like for Java's
creators on the day when java.lang.Math, for instance, first saw the light of
day. How ever did they make the incredible perceptual leap that enabled them to
take Java's disparate mathematical functions, heretofore drifting aimlessly in
the Void, and give them blessed order by placing them together them under the
heading of "Math"? Seeking understanding, my thoughts inevitably drift
to the opening movement of of my favorite symphony, Mahler's 1st. It opens with
an air of expectancy, builds tension while moving through moods ranging from
light to ominous, then releases it all in a triumphal burst of brass and trumpet
calls that exalts the soul. I imagine the birth of java.lang.Math must have been
like that.
And what of java.io? Think about it: just two simple vowels, 'i' and 'o', to
encapsulate the mind-bogglingly abstruse concept of data flowing and in and out
of a computer. The beauty of its spare simplicity fairly takes one's breath
away. And its member functions are documented in...wait for it...alphabetical
order! How does one account for such sheer creative genius?
It doesn't stop there. There's java.net for networking functions, java.text for
text-handling functions...it just goes on and on.
Such tremendous breakthroughs in computer science! Before the Java API, the poor
souls who programmed in C, for example, had to struggle along with such
unintuitive things as, um...hmmmm...math.h and stdio.h. Gosh, those don't really
look so different.
How about Python then? Gee, Python has a library named "math". But it
doesn't include a max() function as java.lang.Math does. Instead max() is built
into the language--how pedestrian. And Python's "io" library deals
only with files, while again many of the functions java.io are language
built-ins.
With sarcasm turned off, the fact is that the organization of an API is simply a
taxonomy of library functions. It's a functional classification for the benefit
of the programmer, that will vary with the purposes of the language. Python, for
example, was created for scripting, so many functions are language built-ins to
make them available to the programmer with minimal code.
I think it important to point out that Java is itself highly derivative. I've
often seen it characterized--fairly, I think--as "C without pointers".
Java's creators used (in Oracle-speak, "stole") C syntax essentially
verbatim. They also "stole" the modular nature of C, in which most
functionality is located in libraries that are accessed through a standard
interface. And they "stole" the concept of organizing those functional
elements into files that are given descriptive names.
If memory serves correctly, Java was based on C in no small part to make it easy
for C programmers to become Java programmers: the same syntax, similarly-named
libraries, etc. That's why Google decided to implement the Java language for
Android: to make it easy for developers to code for the new platform. For Oracle
to argue that it was okay for them to do what they did with C, but illegal for
Google to use Java, seems to me to be the height of cynical prevarication.[ Reply to This | # ]
|
- sweet thought - Authored by: Anonymous on Sunday, May 06 2012 @ 03:44 PM EDT
| |
| Authored by: sk43 on Sunday, May 06 2012 @ 04:12 PM EDT |
In his Opening Expert Report [Oracle-397-1, par. 140], John Mitchell writes:
"Based on my understanding of copyright law, it is my opinion that multiple
ELEMENTS of the Java API specifications contain COPYRIGHTABLE EXPRESSION. These
elements include the selection, coordination, and arrangement of the Java
packages; the class names and DEFINITIONS, fields, METHODS, and method
signatures contained in each package; and the English prose TEXT that explains
each of the above elements."
Got it. Let us examine the prose TEXT that EXPLAINS the Java libary class
"java.lang.StrictMath":
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/StrictMath.html
"The Java math library is DEFINED with respect to fdlibm version 5.3.
Where fdlibm provides more than one DEFINITION for a function (such as acos),
use the 'IEEE 754 core function' version (residing in a file whose name begins
with the letter e). The METHODS which REQUIRE FDLIB semantics are sin, cos, tan
[...etc]"
What is "fdlib"? Here is how Oracle describes it:
"... the package 'FREELY DISTRIBUTABLE MATH LIBRARY', known as
'FDLIB'"
"... available from the well-known network library NETLIB ..."
That's right - the METHODS in java.lang.StrictMath are DEFINED in a third-party
package, fdlib. You can find it here: http://www.netlib.org/
Copyrightable expression. Infringed by Google?[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 08:24 PM EDT |
Not directly on point, but perhaps relevant; a quote from
the "100% Pure Java
Cookbook" (c) 1997 Sun Microsystems:
Any implementation of the
Java core APIs will include
classes and packages that are not part of the
documented API
interface. Portable programs must not depend on these
undocumented classes, because they might vary among
different Java platform
implementations. This is true even
if the classes in question are undocumented
parts of the
reference Java platform implementation from Sun
Microsystems.
Those interfaces are not part of the Java
platform definition, and they are not
checked by the Java
tests for compatibility, so they might be absent or might
behave in subtly and dangerously different ways on different
Java platform
implementations. They are not documented
because they are not intended for
client use.
-- R Hayes
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 08:50 PM EDT |
Apparently according to this Apache Foundation's Harmony Project
page, Java's API's were used freely under a "public license" in
their "Independent Implementation":
http://harmony.apache.org/subcomponents/classlibrary/compat.html
""The Reference Implementation (RI) is used to resolve issues that
are not adequately addressed in the specification. In such cases we
use the RI as a guide to the compliant and expected behavior;
however, developers must ensure that the behaviour of the RI is
determined soley through exercising the 'PUBLIC' Java APIs --
specifically we avoid any notion of reverse engineering or
exposition of the RI's implementation by exercising non-API types
and methods.""
Copyrighted does not mean they were not Free to Use with a Pass-
Through Publically Licensed "Independent Implementation". Such as
what Apache Harmony was and Android is!
So now which Public Java SE Specifications License did Apache for
Harmony use and which one was Google going by? Oracle's currently
posted Public Java SE Specification License? ....or the Final Public
Java Specifications License posted for SE 5 or maybe SE 6 available
at these links below (copy/paste to address bar)!
(Public) Java SE 5 Specification License:
http://java.sun.com/products/ejb/license/ejb-2_1-fr-spec-
license.html
(Public) Java SE 6 Specification License 2006 (notice how this
license is much more clearly defined and written too):
http://java.sun.com/javase/6/jdk-6u21-doc-license.txt
There is a distinct difference between using a Copyrighted Public
Specification to develop Applications or an "Independent
Implementation" and possibly ripping the Whole Spec off, posting
them online (partially = Fair Use), claiming them as yours, etc. But
using individual API's (or a portion as in Google's case 37 of them)
in an "Independent Implementation" shouldn't be a problem. At least
under "Fair Use". Just because an API begins with "Java"
trademark
(java.lang = Provides classes that are fundamental to the design of
the Java programming language.), doesn't mean you're violating "Name
Space" or "Trademarks" under Fair Use either!
Warning!!! Specifications as a whole are Copyrighted... Yes. But if
individual API's within that Specification are made Copyrightable
(Protected without possibility of Fair Use or API's held separable),
then we have a major problem and the World is in for a whole lot of
hurt including Oracle themselves!
http://www.decryptedtech.com/index.php?
option=com_k2&view=item&id=700:what-if-all-of-the-java-apis-were-
not-free-how-many-applications-could-no-longer-be-sold&Itemid=139
Therefore this is why the EU Court of Justice has properly declared
API's separable from the Specification... Un-Copyrightable!!!
OTHERWISE... you will have NO Compatibility with the Java Language
itself and ultimately Fragmentation to the 9th Degree on all
resultant "Independent Implementations" rendered worthless by API
Copyrightability!
[ Reply to This | # ]
|
| |
| Authored by: rsteinmetz70112 on Sunday, May 06 2012 @ 10:16 PM EDT |
This goes back to the broken metaphor between API's and programs.
I am an Architect ( licensed in 10 states) to design buildings. Early in my
career one of my mentors told me, "no one ever drew a perfect set of plans
and no one ever built a perfect building".
During construction there are always minor and sometimes major changes in
construction from the original plans.
---
Rsteinmetz - IANAL therefore my opinions are illegal.
"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, May 06 2012 @ 11:27 PM EDT |
Especially after Sun basically flipped them off on dropping
Open Source Required lack of any "Field of Use Restrictions".
Although Compatibility with the JCK was Apache's Objective as a
member of the JSPA, it was primarily driven by their desire to
not have "Field of Use" restrictions as well. That go against
FOSS and their own Apache licensing. Here's a link below for
the Apache Foundations Open Letter, concerning their's and
Sun's main disagreement. Having to do with those Field of Use
Restrictions that run contrary to the FOSS community at large,
including GPL'd Open Source License. It had nothing to do with
money either, as Apache is a non-profit. Here's the web address
of that Open Letter and be sure to visit that JCP link on it:
http://apache.org/jcp/sunopenletterfaq.html
JCP page where Sun JCP representative Robert A. Gingell commits
to bringing the JCK/TCK in line with Apache's "No Field of Use
Restrictions" requirements for Harmony under Apache's own Free
Open Source License (not GPL). I think Mr. Gingell would have
been a great witness for Google. Too bad he left Sun before
Android was created!
http://jcp.org/aboutJava/communityprocess/announce/LetterofInte
nt.html
Google after battling with Sun on these same "Field of Use"
restrictions abandoned their efforts to fully license their
Android Implementation and obtain JCK/TCK Compatibility to use
the Java Trademark for this very same reason. Thereby forcing
Google to create their own non-compatible implementation w/o
the use of the Java Trademarks, Licenses and IP protection the
JCK would bring them. In a way you could say Sun forced them to
Fragment Java by not allowing them to reject those "Field of
Use" restrictions and control Sun was demanding.
Sun brought this whole Android/Java debacle on themselves. By
refusing to relinquish control via "Field of Use Restrictions"
to both Apache and Google. That's why to this day, both Apache
Harmony and Google Android remain Non-Compatible. Even if
Apache had fully completed Harmony (99% complete) Sun still
wouldn't made their the JCK (Java Compatibility Test Kit-TCK)
for them as promised by Robert A. Gingell Sun Fellow and Vice
President in the JCP. So Google rightly believed they too would
be fighting a losing battle and the only thing they'd gain is
the ability to use the Java name and coffee cup logo!
In other words, Google on seeing how Sun was treating Apache in
it's supposedly JCP co-operative creation of Harmony Open
Source Implementation, decided to give up fighting with them
(mostly due to McNealy). Then decided to create from scratch
their own Non-Compatible Java Implementation using Harmony's
Clean Room created Open Source Libraries in their own Clean
Room Implementation running w/ their own Dalvik VM creation! [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 07 2012 @ 03:18 AM EDT |
Some thing have been overlooked in the context of interoperability,
compatibility.
Google and Sun/Oracle java is used by a lot of people or corporate
entity.
They work and produce soft and library on their own.
Not following specs or following specs and not using the SSO bar
standard developer from using third party library/API developed
under paid or free term closed or open term. This preventing easy
reuse of code but mainly of code using existing third party library for
which a "sed refactoring" is not an option...
Oracle don't even contest the right to reimplement a function, they
contest the right to use their patent in some reimplementation.
Coming soon :)
So, if Oracle copyright claim are found valide the only thing this will
provide to Oracle, and other in the same position, is right to lock out
a competitor from third party tool/lib/API by the meen of a single
inherently and fonctionaly worthless SSO.
No other gain there and plenty of pain for other.
This will give oversight to a hudge body of work over which Oracle
has no right and no control. This will hinder third party
right to enjoy the fruit of THEIR hard work.
API/lib/SSO around a langage/system, whatever you call them, are a
common ground where consumer/producer of an entire market meet,
share, sell and build amazing things :)
In this case Oracle want to monetize the third party java ecosystem at
no cost, no pain and prevent other from doing the same thing.
Non native english writer. Try my best to speak my mind many thing
left behind.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 07 2012 @ 05:30 AM EDT |
Sun was right about linking the success and grow of Java to openess.
Their is nothing so marvelous/original/distruptive/unique about java
language and API which can prevent doing same usefull work/soft on
other platform with other API and other language. Or prevent the
building and usage of language/API/platform really open.
The grow and relevance of java and it's ecosystem is directly linked to
this well understood premiss/promise which attracted many
contributor/user from major AND minor field.
Even if Sun failed to finally gain from this, other were successfull at it.
Someone can think of Oracle :)
And that's why contributor keep coming in. True competition on the
merit front with no lock-in or lock-out.
Beside that, I don't think Sun have failed on the java front.
From Oracle testimony the most import thing they bought with Sun
was Java...
It is my feeling that without Java Sun was really doom to fail and
sooner.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, May 07 2012 @ 03:50 PM EDT |
I'm probably a bit late but I've written a clone of an OS so here is some
technological background about "compatibility".
The term means "so similar that a computer program can't tell the
difference"
Examples: illegal and iIlegal look the same to the human eye (depending on which
font you're using in your browser) but the second word begins with two letters
'i'. For a human, these seem similar and if you're reading fast, you probably
wouldn't have noticed unless I told you about it.
For a computer, the two words are different. It's a hard task (= needs a lot of
code and experience) to make a computer "understand" (= mimic or make
it appear to a human) that two words are similar. Basically, for a computer,
"aaa" is as different to "aab" as is "xyz". A
human would think that the last one is much more different but this concept is
alien to a computer - unless you write a program for this specific case. The
computer wouldn't be the wiser, but it could behave as if it did understand. It
would look as if it knew what it was doing but only to a human. For the
computer, it's still just moving bits around in it's memory. No program can ever
make a computer "understand" what the bits mean in any way that is
similar to us humans "understanding" something.
When a software developer starts a new software, they have to begin somewhere.
Everyone starts in a place they feel comfortable with. My guess is that Google
started to write Android code in Java because that seemed to make sense at the
time.
But them, the license deal "failed" (whatever the legal term for that
is or the reasons).
Now Google had a technical problem that it had to find a solution for. Every
class (= molds for the building blocks that make up the "living" form
of the software) has a name. In theory, the name doesn't matter but there are
two important factors: 1) A human should understand what the class does/means by
looking at the name and 2) when you use the class, the computer will try to find
the mold by name.
#1 is a product of the limitations of the human brain. A class should have a
meaningful name. Almost every programmer will use the word "Window"
for a class that works with windows on a computer display/monitor. That's a
technical term and if you write a program which uses windows to communicate with
the user, that's the word you will be looking for in the documentation. So the
mold for classes will be "Class". For objects, it will be
"Object" and for strings of text, it will be "String".
That's just a good way to avoid bugs by reducing the amount of information the
developers have to juggle in their heads.
#2 is different. As we have seen above, even small changes in the code (like
using an upper case "i" for a lower case "l" or a zero for
upper case o) make a computer fail to recognize a word. It doesn't look at the
letters on the screen, it looks at bit patterns in memory. And in memory, the
bit pattern for o and for 0 (zero) is very, very different. If you convert the
bit pattern into a number, you'd get 48 for "0" and 117 for upper case
"o". No one would think that 48 and 117 are similar.
So we have the following situation:
Google had a lot of code already written. It was using many names from the Java
language (think English grammar) and the Java runtime (= English words). In
theory, you could change all the names to new ones. But you'd face a couple of
challenges:
1. Software developers would expect the molds under different names. No software
developer likes to spend their time looking for the classes which solve their
problems. Using different names is a good way to kill enthusiasm or to slow down
development. It's like replacing any piece of furniture in a house with
something similar and moving things around. It drives people crazy, especially
control freaks.
2. Computers don't understand what code means. When I write "Object"
in a source document, that can mean different things, depending on where I write
it. It's not always easy to see at first glance what it means, even for a human.
So if you start renaming stuff, you never know if you really, really got it
right in all the places. If you miss one (and you always do), you have a bug. If
you rename lots of things, you have many, many bugs. Software with a lot of bugs
doesn't get a lot of love.
3. If you rename something that is rarely used and has an unusual name, that is
pretty easy to handle. If you rename something that has a common name and it
used in a lot of places, that's begging for trouble. In our case, Oracle asks
that Google should rename "java.lang.Object". This string (and I mean
this exact string, see above) is used *everywhere*. It you don't mind the
reference but it's a bit like saying "Yeah, you can print The Bible but you
mustn't use the letter 'e'. Oh, and good luck selling it!".
4. There is a lot of code - databases, helper frameworks, literally billions of
lines of code - that use the Java API. If you start changing core names, then
all this code becomes useless. As I said above: Computers don't understand the
concept of similarity very well. You can't tell them "my language is a lot
like Java". When it looks for molds, the names must match exactly, letter
for letter, dot for dot.
5. In Java, unlike other, older languages, you mix API (that is the interface
that you should use to talk to a part of the software) and implementation (this
tells the computer what to do when a method of the API is invoked). Example:
String.length() gives me the length of a string. "hello".length()
would yield 5. In source code, this could read like so:
[code]
public int length() // This is the "API" - What you can do
{ // Anything between the braces is "implementation"
// How to do the actual work
int count = 0;
... somehow count the number of letters in the string ...
return count;
}
[code]
In the API (often called "header files") of older languages, you'd see
only "public int length();" which means "the class 'String' has a
method 'length' which returns a number without decimal places".
If I want to call this method, I use the code above. If someone renames the
method to something else, my program suddenly fails without being changed. The
API basically defines the words in the dictionary that my program can use. If
you start to rename words in the dictionary, the result isn't English anymore.
So what Oracle wants is to force Google into creating a product which can't use
anything related to Java. Billions of lines of code and the work that went into
them would be useless to Android and its developers. Everything that Java
already has would have to be invented again from scratch. It would take years to
rebuild the thriving Java ecosystem. All the apps on the Google market today
would be digital waste overnight. Every Android developer would have to learn
the new grammar and the new words.
Some things you asked:
> [...]what percent of pre-existing programs written for the Java platform
are compatible with Android?
That depends on what you call a "program". The H2 database is both a
program and a framework which you can use to build software that uses a
database. The program (the H2 database server) doesn't work as such on Android
but you can use the framework to add a database to a program that you write.
The key here is that not all Java code works on Android but that you can reuse a
lot of the code that was written for Java. It's a bit like building a car from
iron ore that you still have to mine or building it from pieces that you found
on a junkyard and in existing cars. Of course it's possible to build a car from
scratch, starting your own mining company and everything. But it's also a pretty
sure way to fail.
Which is why most new programming languages are compatible to something that
already exists: You don't have to dig up your own iron. Without writing a lot of
code, you can have a database because you can use the one which already exists.
There will be drawbacks (like design compromises which you'll have to make) but
it will help enormously spreading your new thing because you and everyone else
doesn't have to start from nothing.
It's obvious that Oracle would like Google to pay for their
"parasitic" use of the huge amount of work that went into Java. But
I'd question that stance:
1. What did Oracle do for Java besides buying Sun and selling a commercial Java
VM? Yes, they spent a lot of money but that doesn't mean the universe has to
make sure the investment pays off.
2. A lot of code in the Java universe is open source; you can see how it works,
you can change it and often even use it for free (it's free as in freedom and as
in beer!) I'm not sure how this came to pass but I'm sure Oracle wasn't part of
it. Java was always about sharing and Sun, no matter how many other mistakes
they made, did eventually understand this. Google depends a lot on this part of
the Java world; the language and the runtime are only the basic blocks.
3. If Oracle gets their way, I want to own the word "the". Sounds only
fair.
Hope this helps.[ Reply to This | # ]
|
|
|
|
|
