|
|
||
Kirill Grouchnikov's BlogOpen Source ArchivesSoftware licenses, the letter and the spiritPosted by kirillcool on June 06, 2007 at 06:00 PM | Permalink | Comments (6)Some of you most probably have heard about the latest round of "Microsoft against open source". It all started here when a developer of a plugin for various versions of VS.NET has decided to vent his feelings over a two-year long dispute with Microsoft over the license terms of free version of the Microsoft IDE and whether his plugin is in violation of its EULA. There's a lengthy e-mail exchange (hopefully complete and unabridged), and it's quite an interesting read. I highly recommend reading it before jumping to any conclusions. The lead product manager of Microsoft has promptly responded here and here, and the comments are interesting as well (coming from both sides of the "fence"). And now it gets interesting. The story was picked up by The Register, providing a highly biased and opinionated view on the subject. The plugin developer is portrayed as the ultimate victim, and Microsoft is portrayed as the ultimate villain. From here, the story was picked by the usual suspects, including SlashDot and others, making its way to JavaLobby as well. I usually don't do this, but i have decided to copy-paste the comment i left on that Javalobby thread to my own blog. So here it is: ---------------------------------- Everybody applauds FSF for making a special clause in GPLv3 that was added because Microsoft has found a legal loophole allowing the deal with Novell. Microsoft didn't break the terms of GPLv2, but they're the bad guys for breaking the spirit of GPL. This guy (allegedly technically) didn't break EULA (although he's the one that provided the correspondence, i guess Microsoft would be very quick to point the legal violation on its blog), but most certainly broke the spirit of EULA. Somehow, Microsoft is the bad guy here once again. The end result - bad publicity for Microsoft, a lot of people suddenly aware of this guy's product (which is sold for some versions), most probably Microsoft won't go to the court (especially since the guy resides in UK), and most definitely the next EULA will have much more verbose clause regarding the limitation, alienating people along the way (anyone complaining that it takes weeks to read GPLv3? all i hear are complaints about Windows licenses and how they go on and on). ---------------------------------- So, what are your thoughts on this? Genuitec, Hibernate and playing nice with open sourcePosted by kirillcool on March 21, 2007 at 08:26 PM | Permalink | Comments (8)It all started on The Server Side where Gavin King accused Genuitec of "skirting waaay to close to an LGPL violation over bundled modifications to Hibernate Tools". Genuitec CEO hasn't addressed this issue, instead choosing to focus on other issues (which sound plausible, but are not relevant to the alleged license violation). Gavin replied by bringing the focus back to the LGPL issue, stating that "Genuitec have decided not to comply with [LGPL] restriction". The ball went back to Genuitec's court and the response is a little surprising, to say the least: Given their history, I cannot help but fault Genuitec for assuming that providing our source code changes to the Hibernate team would motivate them to accept the enhancements and thereby make the changes public. For that poor assumption, shame on us. We provided the source to all our modification, in good faith, directly to them when they were made. However, since they chose to discard our enhancements, our changes are technically not available to others. But insinuating that we don't comply with their license, or haven't attempted to comply by providing the modified source to them, is extremely disingenuous. Here is what i read in plain English:
Now, the first three are regular business practice (doesn't matter if you're an open-source or a commercial vendor). Genuitec's business is to provide one-stop-shop for popular technologies. Obviously, Hibernate is one of the leaders in its space, so it's a good candidate for inclusion in MyEclipse offering. Genuitec obviously tries to minimize its overhead by introducing some kind of generic layer. Having made some changes to Hibernate code, they contacted Hibernate team and offered the code back. Hibernate doesn't owe Genuitec much (all those tens of thousands of calls and downloads served both sides, making MyEclipse one of the leading products in its field, so Genuitec shouldn't use these numbers to picture themselves martyrs). For whatever reasons, Hibernate team has decided to reject the code. It has all the right in the world to do so, there's nothing in the license that requires the original codebase to assimilate any outside change. At this point, Genuitec had the following options:
As far as i can tell, none of this happened up until today. Both parties agree that it has taken between 12 to 18 months, Genuitec acknowledges that the code was sent privately to the original developers (and not shipped with MyEclipse binaries / made available on the public website), and Hibernate even alleges that even the module that has now been released under LGPL doesn't constitute a separate body of work (but that's not for me to say). Somehow, Genuitec tries to shift the blame on to Hibernate. So, you've sent the code and it's been rejected. It's not enough, not according to LGPL. The minute the binaries were available to MyEclipse customers (doesn't matter if they are paying or not), the code should have been made publicly available (at least circa August 2006 when MyEclipse 5.0.1 was released). You can spin it all you want, but for quite some time, the licensing terms have been knowingly violated. I'm not sure how David and Goliath story fits here. Who's David? Who's Goliath? Wasn't David this witty cunning guy who employed a kind of shady apparatus to beat the other guy (who, on the other hand, would have tried to use his physical traits to his advantage)? But i digress. A little disclaimer. I have nothing connecting me to any one of these two parties. I've never used Hibernate (ducks), we have an in-house tool to do that, and i've written my share of ODBC / JDBC. I've never used MyEclipse (ducks) as well. I'm also not a free software zealot, in fact almost all of my java.net projects are BSD (Substance module for NetBeans is under CDDL since it was developped on top of the NetBeans code). But i do understand the reasoning behind moving to GPL in this case. Last thing - it may be only temporary, but at the present time, the download page is not directly accessible from the main MyEclipse page (which also doesn't seem to have a search link, but maybe i'm missing something). In addition, searching for both "Hibernate" and "Open Source" / "Open Source Resources" doesn't seem to produce a link to the above page. Showing licenses for your applicationPosted by kirillcool on August 13, 2005 at 08:46 AM | Permalink | Comments (11)Most of the nowadays open-source and commercial products extensively use other products. Although the "not invented here" syndrome is infective, things such as look-and-feel, layout managers, graph libraries, reporting tools etc. are taken from well-known and actively maintained third party sites. These tools come in variety of licenses, most of which require you to include the corresponding licenses along with the executable version of your own library. Here is a graphical way to organize all licenses in one user-friendly window. Here is a screenshot of license viewer for JAXB Workshop that uses ten other libraries (click screenshot to view full-scale version): The left panel shows tree with all third-party libraries (the root is your own library). Libraries can be grouped (in screenshot above, JUNG library uses three other libraries, which are grouped under it). Each tree entry shows the library name and the license abbreviation. Clicking on a tree entry shows the corresponding license in the right text pane, along with the library name, library URL and license full name above the license. The source for the license viewer can be found in the CVS repository at this link. Sample code for using the license viewer is:
LicenseDialog licenseDialog = new LicenseDialog(
ownerFrame, // your application frame
"JAXB Workshop", // library name
new LicenseDialog.LibraryDetails(
"https://jaxb-workshop.dev.java.net/", // library URL
LicenseDialog.LicenseType.BSD, // license enum
"license/bsd_license.txt")); // resource name for license text
The license viewer comes with about ten pre-defined licenses (such as Apache, BSD, LGPL etc.), which can be referenced using enum value as above. For licenses that are not pre-defined:
licenseDialog.addNewRootLibrary(
"SJSXP", // library name
new LicenseDialog.LibraryDetails(
"https://sjsxp.dev.java.net/", // library URL
"Sun BCL", // license abbreviation
"Sun Binary Code License", // license full name
LicenseDialog.LicenseType.getLicenseIcon("10"), // icon for license entry in the tree
"license/sun_bcl_license.txt")); // resource name for license text
The license viewer provides a helper function for creating standard-looking icon (getLicenseIcon used above). For defining library groups:
licenseDialog.addNewChildLibrary(
"JUNG", // parent library name
"Commons Collections", // library name
new LicenseDialog.LibraryDetails(
"http://jakarta.apache.org/commons/collections/", // library URL
LicenseDialog.LicenseType.APACHE2, // license enum
"license/apache2_license.txt")); // resource name for license text
As can be seen, you are responsible for bundling the license text itself as a resource with your application.
licenseDialog.expandAll(true);
licenseDialog.setLicenseTextAreaFont(
new Font("Tahoma", Font.PLAIN, 12));
These two functions expand all branches in the license tree and set font for the license text pane. Finally, set preferred size and location for the license viewer and show it:
Dimension dim = new Dimension(800, 600); licenseDialog.setSize(dim); licenseDialog.setPreferredSize(dim); licenseDialog.setResizable(false); licenseDialog.pack(); licenseDialog.setLocation(...); licenseDialog.setVisible(true);You can see the license viewer in action by WebStarting this link (requires JVM 5.0+) and going to Help -> View licenses. The next logical step would be to create a new project on java.net that will provide such viewer along with bundled versions of most-popular licenses. Volunteers (a slight chance to win immortal glory is implicitly guaranteed)? Eclipse - the milk cow for the board membersPosted by kirillcool on July 27, 2005 at 07:03 AM | Permalink | Comments (19)My previous entry on IBM's hold over Eclipse has provoked an interesting response from the Executive Director of the Eclipse Foundation. The description of the Eclipse Foundation verbatim is an independent, not-for-profit foundation supporting the Eclipse open source community. Mike provides a few examples of Eclipse projects that have 0 IBM contributors, one of them being BIRT, and another being ECF. The second example is completely irrelevant, having only 5 bugs, but the first one is much more intriguing. Out of 529 bugs, about 95% are allocated to Actuate employees. A quick search on the Internet finds the reason why - for only 95$ a year you can purchase features not available in the free version. Of course, both versions are developed exclusively by Actuate, it's just that the free version that apparently lacks a lot of features is presented as a part of the Eclipse IDE. It appears that Borland will be making a similar move with JBuilder Foundations, providing the additional features as Eclipse plugins for paying customers. Obviously, IBM is not going to lose the money paid to its employees that maintain the bulk of Eclipse. It's much the same way for Sun. As aptly put elsewhere, both companies are planning to increase their revenue by "locking" customers that are looking for free solutions. More and more companies are joining the show: BEA has announced that it will be leading the Web Tools Project (although it has only 42 bugs out of 3348 total, they are much more frequent recently), Oracle, SAP and HP are already on board. Some may argue that these companies are aiming to reduce the cost of in-house development, but they most certainly are continuing to build commercially available-only tools on top of Eclipse platform. Going back to the independent, not-for-profit foundation supporting the Eclipse open source community motto now. It seems that an assembly of highly influential commercial vendors is steering the wheel (independent from what?), hoping to make a lot of money for themselves (not-for-profit for basic functionality?), lulling us into the false sense of the open source community (which finds them bugs instead of paid testers). What's your top 3 open-source choice?Posted by kirillcool on April 10, 2005 at 08:18 AM | Permalink | Comments (16)Open-source libraries abound. Thousands of projects thrive and (mostly) languish at Apache, SourceForge, CodeHaus and right here at java.net. Project directories like FreshMeat, Java-Source and CodeZoo try to make the chaos look less irregular. But above all the rest, there are projects that have changed the field, some of them declining, and some strong as ever. Here are my top three: So, what is your top three*? * Try to choose objectively (I know that even your plumber has wrote a new web framework, but it doesn't mean that it's that good). Entries with more than three names will be subject to removal :( Open source - the curse of the abundancePosted by kirillcool on January 11, 2005 at 03:25 AM | Permalink | Comments (11)As this blog shows, almost every imaginable field of the programming has been covered with open source Java projects, all vying for the same #1 spot. It may seem at first that this can only be a good thing, competition driving the creators forward to create better and faster libraries. However, not all is fair in this kingdom. A recent survey that has been performed on the XML data binding frameworks (available here) has provided me with some interesting insights. In this survey, nine different libraries have been tested for time and memory performance on the same XML input (and its Java representation). The biggest problem? Had to write code for each one of them from the scratch. Even though the JAXB API has been available from 2001, the frameworks have not adopted the proposed approach (each one because of its reasons, i'm sure). The result - each marshalling and unmarshalling class has its unique name, unique signatures for its functions and so on. The bottom line for a developer that wishes to switch implementation - no can do. This seemingly innocent approach of reinventing the wheel (even when the original one is good enough and the only problem with it is that it wasn't invented by you) effectively prevents a potentially successful framework from taking the market lead. Suppose tomorrow a great library comes out, all blazing with performance, with full support of XSD, DTD and Relax. Who will use it? Only the new projects. The cost of switching to a new library and rewriting your code will be too prohibitive for any existing midscale up project. In addition, this also results in libraries that have not been tested thoroughly in production environments. A recent example of this has been discussed at this entry. This particular class has test functions, they just don't cover the buggy line. It has been there since 0.6.0 version (up until the current 0.6.4). The availability of the source code and the testing by the author apparently have not been enough. The data structure market has been divided by so many players that a new player just goes unnoticed (except by Google). Lack of coordination between different libraries (even on the most basic interface level) doesn't allow me as the end user to test the libraries by simply switching the implementation in the configuration file. The result - a really good library is sitting somewhere there languishing. Enjoy Kirill | ||
|
|