Re: Incoming question for our project!

Jan Thielscher

Dear Christian,


thank you for your insights and questions.


Probably I may add a bit from our experiences concerning your first question on how much use AI-models might deliver.


We decided not to follow the AI path – interpreting AI as nowadays typically referred to deep neural nets – due to the complexity of the training data. To train a model you would require a huge amount of cases where you really will know the result but under all kind of different circumstances. Without such data, the net will rather produce wild guesses instead of a real expertise.


So we concluded that it is simpler to use a facts based solver approach to automate this. The rules are much easier to define and to test, thus increasing the confidence of the results. However, you will require a structured approach to reflect the circumstances of the project (commercial use, distribution, IP requirements, etc.) to allow a sound decision.


Besides this with the solver we are always able to determine why an answer is like it is, which also increases credibility 😉


Best regards





Von: "christian.paterson@..." <christian.paterson@...>
Datum: Montag, 6. August 2018 um 09:33
An: Steve Cropper <stcroppe@...>, Jan Thielscher <jan.thielscher@...>
Cc: "openchain@..." <openchain@...>
Betreff: RE: [OpenChain] Incoming question for our project!


Hi all


This is a really interesting discussion branch.

(and more generally, “well done and thank you” to all the OpenChain contributors for making such an informative and dynamic initiative).


At Orange SA we have a compliance process that is very much along the lines mentioned below; mandated expert developers assist project teams within their given domain or ecosystem, legal give final sign-off (and of course, on-going support as needed).


As some of you mention, the structure and sizing need to be adapted to the organization in question. And the guidance given tailored to each specific project.

This is not an insignificant challenge, not least for a couple of reasons:

1/ Expert developers have different levels of experience related to open source licensing.

2/ Legal teams (and named expert developers) have bandwidth limitations.

3/ DevOps and other agile processes demand ever increasing reactivity from the compliance process.


Aside from a fairly high-level, 1st-pass filter, approach, I agree with the shared sentiment that white- (or black-) listing is not well adapted to organizations dealing with projects within different domains.


Given the above points, I have 2 questions for this discussion list:

Q1: What use might AI models be able to play in offloading some of the compliance guidance provided to projects prior to legal sign-off? Might an encapsulation of organizational “intelligence” and history be possible in order to reduce workload on expert developers and eventually legal people? Has anyone tried this?

Q2: Regardless of possible mechanisms that might be employed to alleviate incoming compliance workload, how would you structure an open source “auditor” training program for (non-legal) expert developers? Any examples welcome.


I hope this helps the discussion and, of course, thanks in advance for any thoughts you have regarding my 2 follow-on questions.





Head of Orange Open Source Governance

+33 (0)4 72 35 42 43 / Cell. : +33 (0)6 84 72 94 18


De : openchain-bounces@... [mailto:openchain-bounces@...] De la part de Steve Cropper
Envoyé : mercredi 11 juillet 2018 08:44
À : Jan Thielscher
Cc : openchain@...
Objet : Re: [OpenChain] Incoming question for our project!


Hi Jilayne et al


Yes it is easy to say “create a whitelist” but in practice there is a lot of work involved depending on the size of your organisation.


The Open Chain curriculum will give some good guidance.


The important focus for the teams I worked with in the past was to reduce engineering friction by identifying the most benign licenses first then developing a process where senior engineers with legal support assessed the use case vs the license obligations. We used other criteria such as where the code came from and the trust worthiness of the source.


These engineers had the trust of the legal dept. to judge the less risky use cases accurately. Legal reviewed this work on a regular basis and were called in by the assessor engineers to review more complex use cases or new or high risk licenses (grey listed).

As many of us know, not every open source software package is well documented and you can’t always trust the stated license without reviewing the code base in some detail using commercial or home grown tools.


We then built approval Bills of Material that gave us historical record of who made the approval decisions and, as necessary, why.


Such processes need to be developed with the business focus, size and organisational culture of the Company in mind and may need independent help. Which is something I can help out with.







+44 7982 525 965


On Jul 11, 2018, at 06:07, Jan Thielscher <jan.thielscher@...> wrote:

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 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 .





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. 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.





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





+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?



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

Professional profile:

Get my free book on open source compliance here:  

OpenChain mailing list

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.

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Join to automatically receive all group messages.