Contacting Open Source Projects

Validos adds legal expertise to open source projects

In Validos we aim to add the legal expertise that might be lacking from open source projects to the open source projects.

Normally this is done towards our members but we also aim to be active towards the open source community. It is in our members' interests if unclear licensing issues are solved with the projects, since then OS software can be used even more often. In a larger scale, it benefits the whole open source community and those using OS software, if projects can fix their own licensing issues.

Case: Contacting Apache Tomcat project

Validos has already contacted some open source projects for clarifying certain licensing issues, and by doing so, contributed (for its own small part) to the projects' progress. One example of this kind of contacting was with Apache Tomcat project. We found out with Fossology (fossology.org) that one subdirectory of Tomcat's source distribution contained a license document (apache-tomcat-6.0.18-src/res/License.rtf) which didn't match with other license information provided by the project.

Since Apache projects are typically well organised and the additional document included otherwise undocumented licenses, advertising requirements (or similar) and a third party copyright notice with no license information, we decided to contact the project. The licenses were inconsistent with other information provided in the distribution, and the copyright notice with no license attachment would have been incompatible.

The answer we received from the project confirmed that the mentioned license file didn't belong to the distribution package at all. As expected, Tomcat project was active, they replied to our message and fixed the issue in the software's development tree. Therefore, we could conclude that the software's licensing information was consistent and included sublicenses were compatible with the main license.

How can we be sure? Well, we cannot be totally sure, as this might require interviewing all project personnel and all third parties :-) and still we wouldn't be able to be totally sure. But we can establish a reasonable level of certainty, such that is sufficient for our members (or most businesses in general). Any software project, closed or open, includes always a level of uncertainty for a third party using such software. So in the end, using any software is always a question of reasonable diligence and risk appreciations. As to open source projects, Validos offers reviewing of the project web-pages, the distribution root and the source code with appropriate tools, and also contacting projects for specific questions.

OK, but how do you know that the person replying to you was the correct person? We were replied by a person with apache.org email address and he was also prominently presented as a lead developer for the Tomcat project at apache.org.  Also, he had the rights to make the corresponding changes in the development tree or at least such a change was made at the same time.

What is reasonable level of diligence for businesses? Businesses need to decide this themself. E.g. validos members have different preferences and it depends on their risk preferences, type of business and type of use case at hand. At Validos, the most diligent approach we offer, is extracting licensing relevant information from the project web-pages, the distribution root and the source code. This can be added with questions/comments presented to the project.

You then trust the projects? Yes, we trust the information the projects provide, as long as it is consistent. We look at web pages, distribution root and source files (using mostly Fossology). Sometimes we contact projects. If a project makes a change, such as this one, we trust that the project knows this internally. We, however, need to verify that our contact from the project is such that he/she can represent the project (see above).

We somewhat expected this outcome, since Fossology source code check didn't find any source files under these additional licenses, except for the mentioned license file. As license headers might had been removed from the source files or some code might had been copied between files or file names might have changed, the licensing situation was anyhow somewhat uncertain. Now the developers confirmed that this was not the case and the source tree was correspondingly amended.