Collaborative Model to Validate FOSS Packages, Part 1

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

Working as an outside counsel, it has happened to me more than once that our firm has been asked to legally validate an open source /FOSS package that somebody else already asked us to validate.

While preparing for an open source training session destined to (corporate) lawyers in tech firms, I decided to cite one critic against open source development model: according to the critic the cost of FOSS management in companies is often overlooked and grows over time.

So, with these in mind, I realised that companies should actually co-operate in the validation effort. Instead of each company validating each component separately, this could be done together, only once. This method provides several advantages. To describe the most obvious ones:

  • Reduced costs of FOSS development management, since the generic part of the validation is done only once.
  • Easier and faster decision on whether to use FOSS, own development or third party product. When you don't have to wait for a validation process to return a value (the value can be directly gotten from the database of the collaborative body), you do not rely on your own development that often any more.

We have actually pushed this initiative forward and formed a (Finnish) non-profit organisation together with a number of tech companies to manage such collaborative validation model and work. We were also happy to get some public funding for the initative.

I told Martin Michlmayr about our iniative at OpenMind conference in October last year and he asked me to blog on the initiative at Fossbazaar. Many thanks to Martin on bringing Fossology (which we are using, since December) to my attention and also for the valuable introductions he made.

It's now almost a year since the idea struck me, the organisation was formed in November and we have several people working on this (currently only one person full-time, me ~half-time and some other people - I expect the amount to grow). We have a decent methodology for validation in place and the database of the collaborative body is growing each week. Amount of members is growing (albeit we haven't really publicised this yet - plans are to publicise it rather in weeks than in months - that's why no webpage link or name etc.).

The body will be looking to have international members (well, all current main contacts are in Finland, although the existing members are definitively also very international) - but first with those who want to be involved in the development of the model itself. If this raises interest, please let me know.

I will try to cover several further aspects of the idea and our implementation in a further note. I hope also to be able to report on the work of the collaborative body.

Edit: The collaborative body is Validos ry - a Finnish registered association - published in the first week of February. The info there is still only in Finnish, but we will add articles in English (all the reports are and other cumulative work is done in English - the site will switch to English as the main language after some months).

 

tbm's picture

What common validation will there be?

Can you give some more detail as to which validation you will do that all companies are interested in compared to special validation questions only a few companies may have (or that are specific to a company). I assume your validation effort will form a common ground and then individual companies can do additional validation, as they see fit.

Can you elaborate on this some more - or will this be in your part 2 posting?

Validation Common to All Businesses

Yes, this division is something that we have needed to look into. Our answer is two-folded. 1) We try to add to FOSS projects the legal expertise that they might lack (technical validation to some extent is also planned). Or if they did everything fine, we just record that. On the legal side, we check that open source project has done in-licensing well and out-licensing is clear and in compliance with the in-licensing requirements. We draft simple instructions combining all the licenses' requirements. Then this is reported in a unified manner that should be easy to access and understand. I also would like to add here a way to record and report the software interfaces in a given package (this would be an element in handling the requirement in strong copyleft licenses). The joint effort does not include checking of an individual member's customer agreements/business models or their open source policies against a FOSS component. 2) But we can do something member spesific too. E.g. we are developing a filter, by which a member can apply their preferences. Say, a member wants to have all non-FOSS projects tagged with "possible risk" - then their view to the joint database of reports reflects this (to be honest, the filter probably gets set more often with copyleft licenses being tagged with "possible risk"). This possible risk tag then indicates that the FOSS-component must be looked at in more detail by e.g in-house or outside councel. This doesn't say that we can't learn people reagrding open source policies and customer agreements (on the contrary), but the joint effort doesn't currently cover that. (But I'm on the lookout, since there are many similarities in customer contract questions too and we are continuosly developing the model.) I didn't cover the different risk preferences that companies have and which also affect the validation effort (this is less significant, since costs of validation play a smaller role here, due to the collaborative approach).