GGI Activity: Manage Legal Compliance
Table of contents
Manage legal compliance
Link to GitLab issue: https://gitlab.ow2.org/ggi/ggi-castalia/-/issues/21.
Organisations need to implement a legal compliance process to secure their usage and participation in open source projects.
Mature and professional management of legal compliance, in the organisation and across the supply chain, is about:
- Performing a thorough analysis of the intellectual property that includes licence identification and compatibility checking.
- Ensuring the organisation can safely use, integrate, modify and redistribute open source components as part of its products or services.
- Providing employees and contractors with a transparent process about how to create and contribute to open source software.
Software Composition Analysis (SCA): A significant part of legal and IP issues result from the usage of components released under licences that are either incompatible between them or incompatible with the way the organisation wants to use and redistribute the components. SCA is the first step in sorting out those issues as “you need to know the problem to fix it”. The process is to identify all the components involved in a project in a Bill of Material document, including build and test dependencies.
Licence checking: A licence checking process uses a tool to automatically analyse the code base and identify licences and copyrights within. If executed regularly and ideally integrated into continuous build and integration chains, this allows catching IP issues early.
With the ever-growing use of OSS in an organisation’s information systems, it is essential to assess and manage potential legal exposure.
However, checking licences and copyrights can be tricky and costly. Developers need to be able to check IP and legal questions quickly.
Having a team and a corporate officer dedicated to IP and legal questions ensures proactive and consistent management of legal questions, helps secure open source components' usage and contributions and provides a clear strategic vision.
The following verification points demonstrate progress in this Activity:
Other ways to set up verification points:
- Inform people about the risks associated with licensing in conflict with business goals.
- Propose an easy solution for projects to set up licence checking on their codebase.
- Communicate on its importance and help projects to add it to their CI systems.
- Provide a template or official guidelines for project structure.
- Set up automated checks to make sure that all projects comply with the guidelines.
- Consider conducting an internal audit to identify licences of the company infrastructure.
- Provide basic IP and licensing training for at least one person per team.
- Provide complete IP and licencing training for the officer.
- Set up a process to escalate IP and licencing issues to the officer.
Remember that compliance is not just about legal; it’s also about IP. So here are a few questions to help understand the consequences of legal compliance:
- If I distribute an open source component and do not respect the licence conditions, I infringe the licence –> legal implications.
- If I use an open source component within a project that I wish to distribute/publish, that licence may oblige visibility on elements of code that I do not want to make open source –> Confidentiality impact for my company’s tactical advantage and with 3rd parties (legal implications).
- It is an open discussion about whether using an open source licence for a project I want to publish grants relevant IP –> IP implications.
- If I make a project open source before any patent process, that probably excludes the creation of patents concerning the project –> IP implications.
- If I make a project open source after any patent process, that probably allows the creation of (defensive) patents concerning that project –> IP potential.
- In complex projects that bring in many components with many dependencies, the multitude of open source licences may exhibit incompatibilities between licences –> legal implications (cf. Issue #23).