IP and License Clean for Eclipse Foundation
Over the past couple of months the Hudson community has been working hard to ensure that its source code and libraries are IP and license clean in order to pass the stringent entry requirements of the Eclipse Foundation. I spoke briefly about this at my Hudson session at JavaOne and the response was so enthusiastic that I feel I need to bring the facts to a wider audience through this blog.
The Hudson code that is moving to Eclipse is made up of its core components and plugins for SSH-Slaves, Git and Subversion. The initial upload was made up of around 1700 Java files, 125 XML files, 600 Jelly files and some 3700 property files. The core elements (core, UITest and UpdateCenter) have now been approved and are around 8 of the external libraries but there is still some way to go. Each license is checked by both Eclipse’s automated system and by hand.
There are a number of different areas that are slowing down the progress and causing us to do major rework:
1. GPL/LGPL libraries
Eclipse does not allow any of these libraries in. We have had to make major code changes to remove 5 libraries. One major example is Java Native Access , like many libraries, when we came to a thorough example of the jars we discovered additional libraries that also had to be removed and worked around. You can see the complete list of libraries here. Notice that this list includes Winstone. This was the bundled web container for standalone Hudson, but the version was obsolete and
GPL LGPL licensed so had to be changed to the Eclipse Jetty Container.
Another major code change involved JFreeChart. We have had to abstract this library to a plugin so that it can be provided from outside Eclipse.
2. Obtaining Source Code
Some of the libraries being used in Hudson are so old that obtaining the source code, as required by Eclipse, has proved difficult. One example is the acegi security library. We spent some time trying to procure the source code for the version of this library that Hudson uses. But eventually had to remove it.
3. Forked external libraries
There are a number of external libraries that have been patched within Hudson. These we are having to upgrade to a more recent version and if necessary discuss the patch with the library owner to get it consumed back into the main library . These include jtidy.sourceforge.net, xstream.codehaus.org and others.
4. Duplicate Functionality libraries
Whilst going through the external libraries we have also come across a number that provide duplicate functionality. although not in themselves a problem we do want to analyze and where possible reduce the number of external libraries necessary.
Why is all this necessary? Well, primarily because the Eclipse Foundation require it, and many of our customers are asking for it. But why? And this is really the crux of the matter. Hudson and the Eclipse Foundation are committed to providing a product in which the code and IP are clean, and the process is predictable, stable and open. For some organizations and users this is more important than to others, but for us it is part of our raison d’etre. We believe that if Hudson is to continue along the path of being the de facto standard for CI and to increase its importance to development shops both small and enterprise wide, then it must be absolutely clean. The users, the legal departments, the procurement bods, everyone who has an interest in software and in IP in an organization must be able to categorically say that Hudson is clean, reliable, stable and safe.