Re: Incoming question for our project!
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 😉
Von: "christian.paterson@..." <christian.paterson@...>
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
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
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.