Re: Incoming question for our project!


Jan Thielscher
 

Thank you Jilayne for pointing that out!

 

It is rather astonishing how often – even for legal counsels - whitelists are meant to be the holy grail of compliance conformity. Sometimes we even find the requirement that all licenses appearing in a bill of materials must have gone through a validation process (we call that enforce whitelist). While the latter might be a good idea, it does not serve the goal as long as the list is companywide but not project specific.

 

Really required is a case specific assessment of the obligations triggered by the licenses involved concerning the context of application _and_ implementation (coupling, modification).

 

A very nice proof of the relevance of circumstances has been produced by OSADL at https://www.osadl.org/The-OSADL-Quick-License-Compliance-Check.conformant-licensing.0.html Give it a try and play with alternative answers. 😉

 

All other approaches (whitelisting, project specific whitelisting or blacklistiing) either bear the risk of being too restrictive and thus preventing the application of powerful components or being too permissive and therefor, not achieving the compliance aspect.

 

There are tools that may help you with this by automating assessments, but I do not want to go into marketing here 😉

 

Concerning the SPDX list, I would rather say it has more the character of a complete catalogue _and_ heritage. We use it for example as a reference base to determine the correct license or ingredients of it in automated license detection. A more suitable (due to length and relevance) entry point might be the list of approved licenses by the OSI at https://opensource.org/licenses/alphabetical .

 

Br

Jan

 

Von: <openchain-bounces@...> im Auftrag von Jilayne Lovejoy <Jilayne.Lovejoy@...>
Datum: Dienstag, 10. Juli 2018 um 23:45
An: Steve Cropper <stcroppe@...>, Shane Coughlan <coughlan@...>
Cc: "openchain@..." <openchain@...>
Betreff: Re: [OpenChain] Incoming question for our project!

 

Hi Steve!

 

It’s been awhile since we worked on SPDX together! A bit of an addition to your comment below:

 

The SPDX License List is quite long, so while it is certainly a good starting point for coming up with a list of licenses that meet one’s own criteria.

 

I whole heartedly agree with and want to stress Steve’s other comments regarding what you consider to be a “white list license” is going to depend greatly on how the software is being used, your business needs, and risk profile. Basically – what does it mean to be “white listed”? This is not necessarily going to be the same for every company or every product within a company. Given the specificity, I’d great pre-made lists with a certain amount of suspicion and contend they can end up doing more harm than good in confusing what the list is to be used for, how it should be used, by whom, and the potential for conflation with different scenarios. If you have legal counsel in your organization who already understands this stuff – being able to see what someone else has done can save some time, but for this kind of thing, my view is that for the legal counsel who already understands this stuff, they don’t need to see someone else’s list, as they can probably just as quick come up with what is OK or not OK for certain use cases within their organization.

 

https://choosealicense.com/licenses/ was created to help developers creating code to choose a license for their project (on Github) – it provides a very high-level description of each licenses, which is NOT tied to a specific use case. That is fine if you are a developer, who does not have access to a lawyer, and just wants to get your code out there and licensed so it can be used by others. But I don’t think it has any bearing on the “white list” purposes that you are probably referring to here.

 

Cheers,

Jilayne

 

From: <openchain-bounces@...> on behalf of Steve Cropper <stcroppe@...>
Date: Tuesday, July 10, 2018 at 1:38 PM
To: Shane Coughlan <coughlan@...>
Cc: OpenChain <openchain@...>
Subject: Re: [OpenChain] Incoming question for our project!

 

Hi Shane

 

I would start with the SPDX license list

 

 

The use cases will depend upon what the company does and its own business models.

 

If it is happy fully disclosing software source and participating fully in the related communities supplying the software they use then the list could be pretty broad. For hosting services but not redistributing then most licenses will work. 

 

Things get dodgy if they are a manufacturer and or have/use proprietary software. Distribution clauses and contamination issues will come into play using GPL as you know.

 

Best bet is to sit down with the SPDX list and their legal team and develop a whitelist mapped to use case.

 

Hope that helps

Steve

 

 

Steve

+44 7982 525 965

 


On Jul 10, 2018, at 09:51, Shane Coughlan <coughlan@...> wrote:

Hello all

I recently received a query regarding where there was any reference material on generating a list of “approved” OSS licenses for use within a company based type of usage. Typical uses may be: internal/testing only, incorporated into products, incorporated into websites, etc.

Any useful links or contacts to suggest?

Regards

Shane


--
Shane Coughlan
General Manager, OpenChain
e: coughlan@...            
p: +81 (0) 80 4035 8083                
w: www.openchainproject.org

Professional profile: http://www.linkedin.com/in/shanecoughlan

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance  

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Join main@lists.openchainproject.org to automatically receive all group messages.