Collaborative Model to Validate FOSS Packages, Part 2

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

Martin von Willebrand's picture

I first introduced the collaborative model to validate open source packages and the benefits this offers at a Fossbazaar blog, the Part 1. This Part 2 focuses on how the collaborative model can be implemented and how it has been implemented by Validos, a Finnish association formed for this purpose:

  • What common validation work there is and what is company specific?
  • Who decides what to validate in a collaborative body?
  • Why are the databank and the reports not public?
  • Is there any general benefits to the open source community?

To shortly recap Part 1: traditionally validation of open source packages is done in each user company separately. Thus the work is done many times, whereas it should rather be done only once (with due diligence) and the results should be shared. This is how Validos does it: work once, share the result. This approach has many benefits over the traditional, each company does this themself, method: for details, see Part 1.


What common validation work there is and what is company specific?

The management of open source projects is not always optimal, and even if the project had managed all well, they only very seldom provide easily the information required to fulfil the requirements of the applicable licenses. This means that companies need to add the legal expertise the projects might be lacking to each FOSS package. This includes checking of the in-licenses and their compatibility with the out-license(s), excluding or pin-pointing incompatible files or elements (for possible removal or substitution) and gathering the relevant information for redistribution.

There is also company/business-area specific work that is not directly reusable. But many times these issues are typical and the variation can be anticipated. For example redistribution requirements can be fulfilled in an easy way (if storage space is not an issue) or in some other ways, when storage space is limited. But checking a specific customer agreement against provisions on open source software is clearly something that is not re-usable information.

Also, a company's risk preferences vis-a-vis license ambiguities (such as the reach of a strong copyleft provision) cannot be reused in a straight-forward manner. However, regarding this reach of copyleft provisions, we are planning to issue a recommendation of Validos, which the member companies may use directly or use as a starting point for their own policy.


Who decides what to validate in a collaborative body?

This can be solved in many ways: in Validos, each member company chooses what it needs to validate and that work is done based on such request. The results are however added to the joint databank, so that others can use it too. We have found many times already that validation requests have been satisfied with already done validation and since the databank is accessible through an extranet, reusing happens more often than we know of (unless we count each download of reports).

Since we have some public funding and the main service provider (HH Partners) invests in the collaboration, Validos is able to do some additional validation, which is not directly requested by any member, but chosen with other criteria.


Why are the databank and the reports not public?

Due to that Validos needs funding by the member companies, the validation reports are available only to members of Validos. Members have chosen to share the reports with the companies that participate in the costs. They pay a monthly fee against which they acquire validation work and gain access to the joint databank. Members, however, control the association and the databank and they can decide on this as they deem fit.


Is there any general benefits to the open source community?

We believe that Validos contributes to correct use of open source software and, more generally, promotes the use of open source.

However, Validos does something that benefits the open source projects more directly. At times we provide feedback to the projects or ask for some detail. In such connections we also try to suggest corrections to be made by the project itself so that the correction is done at source: we are committed to maintain a humble approach vis-a-vis the projects and we have received good feedback from the projects. E.g. we asked the Apache Tomcat project regarding a certain unclear or odd license information file: the project then removed the file, as they found it misleading and not required. It is clear that we were not the first ones to wonder the meaning of that file.

Also, companies find it many times difficult to directly communicate with projects: Validos is a good tool for this purpose too.

PS. We are interested into developing Validos further and also committed to making the model international. We have actually built the co-operation with this in mind, however, we wanted to concentrate to Finland in the very beginning. Now, we are looking for one or two international members to make sure our implementation of the collaborative validation works well internationally too.