toggle quoted messageShow quoted text
Dear Shane, dear Alexios,
following your discussion, I get the impression that both of you look at the same but from different angels. The one of you coming from the development the other from the organizational
Finally, we do have a group of software engineers working for/across whatever kind of legal entity(ies) in an arbitrarily formed structure that produces software. Unfortunately, todays
development procedures blur the lines between actively wanted and accidently applied open source usage. Coming from the development perspective, I would doubt, that it will be possible to distinguish an open source program/group or any proprietary development
group anymore, however they will be organized.
Just as an indicator: in 8 of 10 assessed software products claimed as proprietary developments, we have found open source components.
Yes, it possible to have restrictive policies forbidding to use any open source at all. But how well does it work?
As we are here to promote the acceptance and adoption of open source by increasing trust, it should be our aim to push the understanding that open source governance – and thus training
to complete software staff – is inevitable to any software organization.
Whether this is complicated for a large organization with many developers, whether this is achievable or expensive; all this I could imagine to be moved towards different levels of compliance
certification, e.g. a standard cert where it is relevant having understood the requirement up to a platinum cert where an external auditor has confirmed that percentage of randomly picked developers throughout the organization confirmed the skills of an open
Von: <openchain-bounces@...> im Auftrag von Shane Coughlan <coughlan@...>
Datum: Dienstag, 12. Juni 2018 um 21:18
An: "Zavras, Alexios" <alexios.zavras@...>
Cc: "openchain@..." <openchain@...>
Betreff: Re: [OpenChain] Conformance: What does "organization" mean?
I think it really depends on the style of company. For example, some companies in Asia often do not allow access to and use of external software without explicit contracts in place, and some block services like GitHub to underline the point.
But perhaps we are touching on an important item here.
There are two true statements at play:
(1) It is a good idea for software staff to know about open source.
(2) OpenChain’s goal is to build trust by confirming a company has adopted the key requirements for a quality open source compliance program.
It does not inherently correlate that training all software staff in an *organization* is needed for this.
It does correlate that software staff involved in the open source *program* should have such training.
This allows customers to quickly ask “has this ProductA you are offering gone through your OpenChain conformant program?” and feel confident that if the answer is “yes” they can expect trained personnel following key requirements for a
quality open source compliance program to have signed off on ProductA.
On 12 Jun 2018, at 19:58, Zavras, Alexios <alexios.zavras@...
Shane, you write:
The issue of training an entire organization’s Software Staff is perhaps the most frequently cited area of confusion for companies, not least because many larger companies have many staff not related to open source
I do not understand this term (“staff not related to open source”) and I fear that it might be perceived as pointing to a specific, small set of people who “relate to open source” and thus dilute the OpenChain goal.
If there are developers who can open a browser and copy-paste from anywhere to the Supplied Software, they should be considered in the set of people who need to know the basics of Open Source.
Of course I fully agree with the rest of your post that we have always (until now) been talking about a program – and I believe we should keep this.
Thanks for the “on the ground” feedback. The issue of training an entire organization’s Software Staff is perhaps the most frequently cited area of confusion for companies, not least because many larger companies have many staff not related
to open source and introducing a company-wide training program is therefore not tied to the open source compliance effort.
I want to quickly reiterate that our current Specification is explicit that conformance is for a program and the training requirement is defined as for a program. I’ll copy paste the data I have again for reference.
All data is from the current Specification version 1.2:
From the Introduction:
Regarding the goal of OpenChain Project:
"The Vision and Mission of the OpenChain Initiative are as follows:
§ Vision: A software supply chain where free/open source software (FOSS) is delivered with trustworthy and consistent compliance information.
§ Mission: Establish requirements to achieve effective management of free/open source software (FOSS) for software supply chain participants, such that the requirements and associated collateral are developed collaboratively
and openly by representatives from the software supply chain, open source community, and academia.”
Regarding the focus of the Specification:
"In accordance with the Vision and Mission, this specification defines a set of requirements that if met, would significantly increases the probability that an open source compliance program had achieved a sufficient level of quality, consistency and completeness;
although a program that satisfies all the specification requirements does not guarantee full compliance. The requirements represent a base level (minimum) set of requirements a program must satisfy to be considered OpenChain Conforming.”
Shane's note, the introduction of the Specification outlines a focus on open source compliance program rather than organization. This would apply whether organization is defined to mean division, business unit or legal entity.
Regarding Software Staff and training:
In Section 1.2: "Software Staff must have completed FOSS training within the last 24 months to be considered current (“Currently Trained”). A test may be used to allow Software Staff to satisfy the training requirement.”
In Section 1.2.3: "At least 85% of the Software Staff are Currently Trained, as per the definition above. The 85% may not necessarily refer to the entire organization, but to the totality Software Staff governed by the OpenChain Conforming program.”
These various items are also discussed in the Specification FAQ as outlined in the introduction:
"Additional clarification on how to interpret the specification can be obtained by reviewing the Specification Frequently Asked Questions (FAQs) located at: https://www.openchainproject.org/specification-faq"
Shane’s note: There may have been some “cross-talk” here, with conflation between the scope of the Specification requirement for conformance (a program is conforming, training relates to the program) and more generally what organization precisely contains the
program so that we can set expectations.
In other words, it was regarded as onerous for the training requirement to apply to a legal entity and this lead to a lot of discussion on the calls and list about *where* we set the requirements. But unless the open source compliance program *is* the legal
entity, that’s not a concern. And the Spec clearly says this is not the case. What we are really talking about here is locking down a way to clearly signal which organization (however that is defined) has an OpenChain conforming program.
So it appears that all we really want to clarify is whether the program is housed in a division, a business unit or a legal entity. If we can do that, there is a reduction in uncertain from all sides.
- CompanyA can have an open source compliance program.
- That program needs to meet the requirements of the specification.
- CompanyA can say that program has responsibility for taking care of open source compliance company-wide, in a certain business unit, or a division.
- So what we need then is only to clarify *what CompanyA has decided regarding the responsibility of the program*
- And then we need to reflect that on the website.
Finally, regarding proper procedure, it is to take the discussion to the (newly convened) steering committee for formal vote. So that will be the end result to lock down items for the Specification.
On Jun 12, 2018, at 18:42, Gary O'Neall <gary@...> wrote:
Thanks Miriam and Daniel for summarizing the discussions so far.
After working with a small number of larger companies on openchain compliance, requiring the entire “company” to comply with the training has turned out to be a big challenge. From what I’ve learned over the past 2 years, I believe allowing
subgroups (programs) to achieve compliance would speed up openchain adoption. I believe it is a topic worth revisiting based on this learning.
I wanted to introduce one more concept to the discussion. It may be worthwhile defining multiple levels, perhaps even a hierarchy for compliance. We could still have an entire legal entity be compliant. This would be useful for small
companies and larger companies with a more mature compliance environment. I can think of 3 levels that may be useful:
- Organization (the legal entity)
- Program (the subgroup of an organization under a single open source program)
- Product (distributed software under a program)
When certifying, one could specify whether then entire organization is certified, a program is certified or just a product.
From what I have experienced, Organization and Program would both be used. I’m less certain if Product would be used for certification, but it has come up in previous conversations.
The downside to this proposal is it would add complexity, but I feel the additional flexibility would enable higher adoption of the specification.
according to the Spec OpenChain conformance is declared for compliance
programs of an organization. In our last call, we agreed that the term “organization” needs further clarification, as it is the reference point not only for the program, but also for the 85% of software staff that need to undergo training. We
further agreed to use the July to clarify the term. The term “organization” was agreed after long discussions in the very beginning of the project, where it was also agreed that organization meant legal entity. As we are now considering to change this understanding,
we wanted to make sure everyone was aware of the discussions we have had about this topic to date and the agreements that were reached (or not reached) at various points in time. So in preparation of our meeting in July and to kick off the discussion on the
mailing list, Daniel summarized all of our meeting minutes again and we created an overview over the agreed meaning of organization and the relevant arguments and minutes.
Summary of discussions re. “organization”:
Date of call
(Agreed) meaning of “organization”
Minutes summary (if relevant)
Until July 10, 2017
August 7, 2017
Organization generally means
unless legal entity does not work for the structure of the organization that is claiming conformance.
- Organization is not explicitly defined as a legal entity in the current OpenChain material.
- It was decided that for now we will define organization as legal entity, but companies with other structures
can also self-certify by using Legal entity > StructureName.
- If they have any questions or need assistance they can contact the conformance work team volunteers.
September 5, 2017
- Discussion about what happens in case of acquisitions (re. 85% software staff)
What needs to happen when a conformant company acquires another which is not conformant yet?
What should happen with regards to the conformance during the integration phase of the acquired company? Integration takes time for the new part
of the company to follow policies and processes.
October 16, 2017, October 24, 2017 January 15, 2018
- No agreement.
- Potential meanings:
Section of the company, where staff is involved in software development of software.
Section of the company, where a particular open source program applies.
Business Group of a company.
Release of software needs to be certified to be conformant.
- As long as it is clear whether compliance is for the full or part of the organization it seems perfectly
- Allowing partial conformance is important.
- In the very beginning of the project and that the focus at that time was on conformance legal entity
by legal entity.
- It may be useful if we could certify that a release was OpenChain conforming.
- We need to clarify whether conformance is by a program or a legal entity.
- From a legal perspective it is easier to define conformance by legal entity but in practice it may be
easier by program.
- It may be useful to allow different stages of conformance (full organization, partial conformance) to
encourage a pathway to full conformance.
- Our current understanding of the spec is that it applies to a program, and 85% of the staff related
to a program need to meet the requirements of the spec (rather than the company as a whole).
- There is an expectation of a company being conformant. There may be a detrimental reliance issue. If
it is not full entity conformance there will have to be a lot of clarification.
- Looking at standards like ISO it had organizations being partially conformant but in open source we
need to have complete conformance.
November 6, 2017
- Agreement that organization does
not need to be a whole legal entity.
- The reference point of the spec is “program”.
- It is not relevant, if a whole entity to be conforming.
February 5, 2018
- No agreement.
- Potential interpretations:
- Headcount of the people in an area.
In my opinion, the starting point of our discussion should be:
- The goal of OpenChain, which is to build trust. That requires that we have clarity about what the organization is that has
the OpenChain conformant program.
- The recipient of the Supplied Software needs to be able to trust, meaning that the relevant question is, what the recipient
would expect organization to mean (Would they expect it to mean legal entity or the combination of all those involved in creating the Supplied Software irrespective of which legal entity happens to employ them?).
On the more formal side, we should also consider, what the proper procedure is, as we are essentially changing an agreement that was reached by the OpenChain
project at an earlier stage. We should also consider how the conformance and especially the logos should be presented on the website.
Looking forward to all your input.
Dr. Miriam Ballhausen
Rechtsanwältin / Senior Associate
Bird & Bird
Direct +49 (0)40 460 63 6269
Mob +49 (0)151 7212 3911
Tel +49 (0)40 460 63 6000
Fax +49 (0)40 460 63 6011
Bird & Bird LLP
Großer Grasbrook 9
BIRD & BIRD
Der Inhalt dieser Email ist vertraulich und unterliegt möglicherweise auch dem Anwaltsgeheimnis. Wenn Sie diese Email irrtümlich erhalten haben, löschen Sie sie bitte und benachrichtigen Sie bitte umgehend per Antwort-Email den Absender. Diese Email darf weder
kopiert oder für andere Zwecke verwendet noch darf ihr Inhalt anderen Personen offengelegt werden.
Bird & Bird LLP ist als limited liability partnership unter OC340318 in England und Wales registriert. Registersitz: 12 New Fetter Lane, London EC4A 1JP.
Einzelheiten finden Sie unter www.twobirds.com
Bitte beachten Sie unsere Datenschutzhinweise (www.twobirds.com/LNPrivacy). Dort erfahren Sie welche Kategorien personenbezogener Daten wir erheben, wie wir diese Daten verarbeiten, an wen wir diese Daten im Rahmen
unserer Leistungserbringung übermitteln und welche Rechte und weitere Möglichkeiten Sie in Bezug auf die Verarbeitung Ihrer Daten haben.
Nähere Angaben über Bird & Bird LLP und die mit der LLP verbundenen Anwälte (gemeinsam als “Bird & Bird“ bezeichnet) finden Sie unter
Any e-mail sent from Bird & Bird may contain information which is confidential and/or privileged. Unless you are the intended recipient, you may not disclose, copy or use it; please notify the sender immediately and delete it and any copies from your systems.
You should protect your system from viruses etc.; we accept no responsibility for damage that may be caused by them.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928