What a ridiculous development. Sun Micro-systems was recently acquired by Oracle, and of course, the evil begins! This is why I am so interested in Ebay's acquisition of Magento. Because giant soulless corporations run by power hungry, money grubbing, insane CEO's, think they can do whatever they want. They purchased a language they didn't even develop, that was out under a copy left or GNU license, and now they are changing all that. I mean, I didn't the specifics of the Java license, but I know when I first started using in early 2000's that it was an OPEN SOURCE language. I think its absolutely horrible what is happening to MySQL and Java. How long before PHP is taken over? Quite frankly SAP and Oracle are a bunch of jokers. What they do, an in house team of programmers can do just as well. Only they charge ridiculous fees for their software, import cheap labor, and charge a giant markup for that as well. As a professional, I can do what SAP does with PHP/MySQL and not spend a dime on licensing, keep the jobs in the USA, and deliver a superior product.
Oracle’s lawsuit against Google for Java patent infringement highlights how Android is going to become a big target in court.
Take Oracle’s lawsuit (statement), which alleges that Google developed Android and “directly and repeatedly infringed Oracle’s Java-related intellectual property,” and couple it with Apple’s court battle with HTC and it’s clear the legal armies are amassing against Android. And why not? Android has pretty much been unstoppable and once something gets critical mass it only stands to reason that there will be a fine-tooth patent comb going through the mobile operating system’s code.
The LGPL and Java
by David Turner
This article was written in November 2004, when LGPLv2.1 was the most current version of the license. Since then, LGPLv3 has been published. The main points of this article remain true about LGPLv3, but some of the details, such as section numbers, have changed.
It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as “hereditary.” So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications.
In July of 2003, Slashdot published a story claiming that I had claimed that the LGPL did not function as intended in the case of Java. This story was based on a misunderstanding of a response to a question sent to email@example.com, and many attempts to clarify the issue in the Slashdot story did not get across. I have recieved numerous questions about the story since, via both firstname.lastname@example.org and personal email.
FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution.
If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that—people who modify the library are responsible for making it work.
When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.
The only difference between Java and C from the LGPL's perspective is that Java is an object-oriented language, supporting inheritance. The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.