Join Brian Fox tomorrow, Wednesday, May 23 at 11AM EDT or 2PM EDT (GMT-0400) for a 30 minute tour of Insight for CI. In this demo, Brian will show how Insight for CI will help you:

• Generate a detailed bill of materials for every build in Hudson and Jenkins.
• Find and fix license, security and quality problems quickly.
• Set rules to notify you of problems, fail builds, or establish workflows.

If you register, you’ll also receive access to the recording after the event. So if something comes up and you can’t make it, you won’t miss out.

Two sessions are available tomorrow, Wednesday, May 23. Choose the best time for you:

Register – 11:00AM EDT (GMT-0400)

Register – 2:00PM EDT (GMT-0400)

Due to high demand, we have added a second webinar presentation next Wednesday at 2PM EDT (GMT-0400) to accommodate multiple time zones. Here are the details for the presentation:

Join Brian Fox this Wednesday, May 23 at 11AM EDT or 2PM EDT (GMT-0400) for a 30 minute tour of Insight for CI. In this demo, Brian will show how Insight for CI will help you:

• Generate a detailed bill of materials for every build in Hudson and Jenkins.
• Find and fix license, security and quality problems quickly.
• Set rules to notify you of problems, fail builds, or establish workflows.

If you register, you’ll also receive access to the recording after the event. So if something comes up and you can’t make it, you won’t miss out.

Two sessions are now available on Wednesday, May 23. Choose the best time for you:

Register – 11:00AM EDT (GMT-0400)

Register – 2:00PM EDT (GMT-0400)

The following post about Meteor, a new, node.js-based approach to building web applications backed by MongoDB got my attention because it highlights some of the tricky integration issues we’ve had to think about when coming up with hypothetical use-cases for Insight. Here’s a quote that captures the complex relationships between Meteor, originally a GPL-licensed Javascript library, and an Apache-licensed library to access MongoDB:

From Olov Lassus’s popular blog post “Meteor meets NoGPL”

“The copyleft (viral, contaminating, whatever you want to call it) aspect of GPL is tricky. Take MongoDB as an example. Meteor uses it by importing the node-mongodb-native package (require(‘mongodb’)). That one is Apache 2.0 licensed, which is a permissive license that happens not to be compatible with Meteor’s GPL (v2) license, at least not according to the FSF. Tricky. Dependency chains, bindings between JS ↔ C and RPC makes it trickier even. I wouldn’t be surprised to see Meteor change to a GPL + a-bunch-of-OSS-exceptions license similar to what Qt and MySQL used to have, to avoid issues like this.”

Don’t get me wrong, I’m not questioning the Meteor team’s right to choose whatever license they want, but I noticed this post because these are the kinds of relationships that we’ve been trying to sort out between different libraries in Central. We’ve encounter libraries that advertise themselves as BSD-style licenses which end up requiring dependencies on GPL components. This highlights the problem of licensing intent versus licensing reality. Just because a particular components is licensed under a particular license doesn’t mean you can actually use it under the terms of that license.

Lots of activity on Olov Lassus’ twitter feed and many opinions on the hacker news threads.  This one was good about the ambiguity of the GPL w.r.t. derivative works.

Note: Meteor has since changed the license to MIT, which makes this very interesting project that much more compelling to a wider audience.

If you consume both EPL and GPL in a Maven POM or another build, and then you subsequently ship that software, you would not be able to satisfy your obligations as a distributor and would therefore be in violation of one or both of the licenses.   As developers, we have enough to worry about already.  This a job best done by the tools we use — in this case Insight for CI and Nexus Professional.  Depending on your circumstances, having your CI system alert upon detecting incompatible licensing constructs at build time reduces risk and costs by catching problems early in the development lifecycle.

Invalid license constructs are similar to conflicting licenses in that they also create a situation where a distributor is not able to meet all of the required license obligations specified by all open source components included.  The difference is that the licenses are in fact compatible, just that they are not valid in the particular direction specified.  For example, you cannot move from nonpermissive to permissive, such as GPL to BSD.  But, using BSD licensed code within a broader GPL work is perfectly acceptable.

An example scenario:

Someone integrates a GPL licensed artifact into their code but (incorrectly) chooses a BSD license for the combined work.  This is an invalid license structure since the GPL is a non-permissive license and BSD is.  The GPL does not allow for a reduction in the rights expressly granted to the consumer, which is what is implied by a BSD license — e.g. as a consumer of BSD, you are not entitled to receive a copy of the source code from the distributor but with GPL you are.  There is no way, under the BSD license, for a distributor to fully satisfy the obligations of the GPL, hence this arrangement is invalid.

As part of developing this product, we’ve consulted with legal professionals who have given us guidance on handling invalid and conflicting licensing.  The short version:

• Sonatype’s licensing products only report factual information.   Our products don’t give specific legal advice.  (In other words, Insight for CI and Nexus Professional are not a substitute for a qualified legal professional.)
• Obligations shown for an artifact must be the set of all obligations of everything in a particular JAR regardless of hierarchy.   This is why you might be surprised every once in awhile by an artifact that advertises itself under an Apache 2.0 license that is listed as a potential LGPL or GPL artifact.    Licensing isn’t about intent, it is about what the end product’s resulting obligations are given a combination of artifacts covered by various licenses.
• Sonatype products effectively identify “invalid” and “conflicting” licenses and highlight these occurrences.   If there is an artifact in your repository that is covered by two licenses that cannot be combined that’s something we will flag so that you understand the potential distribution risks implied.

Such a situation has an element of risk for a customer.  We identify such risks, and call attention to the potentially problematic combinations.   Again, our products are not in the business of rendering legal opinion, we’re just here to report the facts.  It is an exercise for the user to determine the implications this might have given their unique circumstances.

Most developers don’t spend much time thinking about these types of licensing issues.  Who needs more work to do?  Yet, every day, developers consume open source components often without giving these considerations much thought.  This means that when an organization ultimately decides to take a look at licensing they can uncover issues they never knew existed, occasionally nestled deep within their application’s dependency graph.  Often times, there is also no path to remediation since the work in question has already been distributed.   In short, you could be compelled to meet the obligations of hidden viral licensing — perhaps through open sourcing your intellectual property.

• Gain visibility and control at build time in Hudson and Jenkins.
• Find and fix license, security and quality problems quickly.
• Set rules to notify you of problems or to fail builds.

If you register, you’ll also receive access to the recording after the event. So if something comes up and you can’t make it, you won’t miss out.

Reserve Your Seat Here

Here is a list of the Top 10 Utilities from April 2012. Note how Google Guava jumped three places from #15 to #12 with a 2.5% increase in demand from March. While I don’t expect Google Guava to surpass the popularity of Apache Commons components any time soon, it will be interesting to see if Guava becomes a standard that challenges Commons Lang. Guava, like Apache Commons, is a collection of utilities and classes that supplement Java, while they have overlapping purposes, I tend to continue to have both on my classpath whenever I’m coding.

Caveat: I’m comparing utility libraries with the exception of JUnit. JUnit is downloaded automatically by a number of tools (tools that don’t appear to cache artifacts between instantiation). Because of this JUnit downloads are off the chart. If you average out the data, JUnit is being downloaded approximately once a second (across the entire month).

A big thanks to all of you who registered and attended our sneak preview of Insight for CI last week. We had a great turnout and a lot of fantastic questions! If you didn’t have a chance to register, that doesn’t mean you have to miss out. The replay is now available.

Request the webinar recording here.

Thank you!

If you have five minutes and you are looking for something that might convince others in your organization, this video will be of use. Here’s the video “OSS and the Enterprise: How Nexus can Help” followed by a very brief summary:

A summary in four sentences:

• The Enterprise has shifted dramatically over the last decade and OSS has been a major force driving the evolution of Enterprise software development.
• As organizations have adopted OSS, developers have a new interest in consuming OSS and bring some of the practices of OSS in-house.
• Nexus was designed to make is easier for you to support your developer’s interest in OSS consumption while giving you the necessary controls.
• Better yet, Nexus allows you to adopt the same mechanism for collaboration that is used by OSS projects.

In other words, it isn’t just about software.

Here’s an example of a decision you may have to make in the next few months.    Assume you have the chance to use a newer version of Spring, evaluate Hibernate vs. iBatis, and adopt a new REST-friendly web framework.   For each of these new and updated components you are going to have to ask yourself three questions:

• Which version of the library has the largest “install base”?  It often doesn’t make sense to use the latest version of a component, especially if it is a major release.   If you are looking to reduce risk, don’t code on the “bleeding edge” of technology.  Use the most popular version of a component.
• Which version of the library is free of security vulnerabilities?  The only thing worse than getting hacked is realizing that you got hacked because you weren’t paying attention to known vulnerabilities.   If you are upgrading to a new version of a library, make sure it is secure.
• Which version of the library is compatible with your OSS license policy?

Nexus Professional 2.0.4 brings the answer to all three of these questions to the search results.  Here are the search results showing the results for tomcat-catalina.    We’ve combined popularity data from Central with security and licensing information.

Without the popularity data you might have just selected the latest version of the library, version 7.0.27 which has been available for 37d.   If I were selecting components for an application, I would likely stick with Tomcat 7.0.25 based on the relative popularity of the artifact alone.   7.0.25 is, far and away, the most popular artifact of this group.

Sonatype’s Nexus Professional is the only product that incorporates popularity data directly from Central.   If you are interested in using Nexus Professional to evaluate your dependencies, download a copy and start your trial today.

Many of you have requested access to the individual graphics we produced for the findings so you can link to and share individual slides.   Here are the survey results:

Click here to view the Survey Results

We put together a slick little gallery where you can access and share any of the individual images.