Open source codes, libraries and designs are all available for use against a licence. As a developer and a user, you must make sure you are aware of the various compliances required, and also ensure that your software complies with these.
Open source compliance is a process by which open source users, integrators and developers satisfy the licence obligations implicit in their open source software components. A well-designed open source compliance process will help organisations protect their intellectual property.
First step to compliance: Awareness
A lot of companies do not consider themselves as open source companies. And because of that, their business leaders don’t believe they need to manage open source. But, in reality, all software developed today consumes open source components, libraries and frameworks. This use of open source carries a few risks, which are then passed on to customers. Indian developers have contributed hugely to a lot of open source projects like Soda and HarmonyOS on a global scale. Open source compliance is today mandatory to ensure that there are no issues in the use of these projects.
Sriharsha Narayanam, lead architect, Huawei Technologies India Pvt Ltd, points out three scenarios where one must consider compliance. The first is the open source project that is developed and hosted, where the highest responsibility and obligations lie with the creator. The second is when developers contribute to third party open source projects, which comes with a lot of shared responsibility. The final scenario is when we use open source projects. “Give enough attention to each of the scenarios — be it with respect to the tooling or the guidelines. The key responsibility is to create awareness among all the members joining open source projects,” says Narayanam.
Martin Callinan, director, Source Code Control India Pvt Ltd, a company that provides services to manage licensing, says, “Training programmes should be provided about what needs to be managed and how to manage it. The companies can be helped in making policies. For instance, the organisation may have intellectual property (IP) value in the software, for which the source code cannot be shared. It is advisable to create a guidance for developers about what to avoid coming into their code that will be shipped to the customers. It must also include services on security vulnerabilities in the components used. Many companies can’t actually identify what open source is being used. Such firms need help to refer to software composition analysis tools, which can identify the licences associated with components and vulnerabilities,” he says.
Balakrishna Mukundaraj, associate project manager, Bosch Global Software Technologies Pvt Ltd (BGSW), also feels it is important to develop training, policies and other processes that are necessary to achieve open source compliance across the organisation. BGSW is among the first companies to provide compliance audit services to all the different business units of Bosch worldwide. “The consultation services begin during design — companies come to us with queries about licensing at the stage of procuring components. The organisation level training is vital even for any tools that have been procured or developed in-house,” he says.
“Education is the core foundation of open source compliance. An open source awareness programme for onboarding graduates will help to figure out the roadmap to be implemented within a company. At Bosch, we took this up seriously and started giving more time towards the training, which has proved very useful,” he adds.
Along with training and awareness, a little knowledge about the common misnomers and challenges can help developers improve their understanding of open source compliance. The Linux Foundation offers two courses for this:
- Introduction to Open Source License Compliance Management (LFC193)
- Open Source Licensing Basics for Software Developers (LFC191)
A few myths
The software is free: The most common misunderstanding in open source is with the term ‘free’. “It actually means you are free to use it and do whatever you want within your project as long as you meet the obligations of the licence,” says Aykut Avci, global license compliance manager, iText Software.
As there are numerous permissive, non-permissive and copyleft licences like Apache License (permissive licence), Massachusetts Institute of Technology License (permissive licence), General Public License or GPL (non-permissive and copyleft licence), Affero GPL (non-permissive and copyleft licence) and more, it’s quite difficult for a developer to know the obligations of each one of these. “The open source you use may be free, but there are different business models that can allow a certain part of it or certain functionalities to be open, and the rest is for commercial use. People frequently confuse the two. For instance, iText has a dual licence – if you use the open source copyleft licence, you will need to make the source code of your derivative work available to users, but you can purchase a commercial licence to take away the copyleft obligation,” he adds.
Open source software has good quality: We expect an organisation to have a very high quality of open source. But remember, there is good and bad quality open source. The update history and commits of open source projects are a good reflection of the health of an open source component. The community is not going to check that.
Narayanam says communities do have strong pipelines and checks, but they may not work to achieve quality. Hence, always set your standards high for the open source project and the delivery project, with respect to the quality, cyber security and tooling.
Callinan says it is a myth that if it is managed commercial software, it does not have much risk. It is also a myth that open source communities will fix everything. Some projects are managed only by one person. To check the quality of a project, look at the activity around the components, library or the package you want to bring into your software. There are tools that can reveal data about the number of commits causing a hidden risk for companies, such as the recent log4j vulnerability. “Always check how well-supported the product is,” he adds.
The OpenChain Project of the Linux Foundation is a great example of how trust can be built into the complete supply chain of software.
Compliance issues are being taken care of: According to Narayanam, when developers are collaborating on an external open source project, the host may not take care of the compliance. So, how does one ensure compliance? It’s best to have a common understanding of the copyright statement right from the beginning when you are contributing to or hosting a project. The advice of a legal team is mandatory.
From a quality perspective, give details on what kind of tooling you have used to ensure compliance when the code is checked. Also, place checks and balances on what level of cyber security you want to ensure.
The engineering team, developers, legal team and IP team will all need to be involved in compliance.
Licensing can be ignored: There are many different types of licences and their versions. Tools can be used to identify the components in the code, but unless you code in, they generally don’t provide interpretation. As this becomes confusing, people tend to avoid using them.
“We must look at the business risk as opposed to working just with developers. Developers shouldn’t have to spend time interpreting licences. Companies must put guidance in place. Also, start working with a company by attending education programmes to get some understanding across the business about the different types of licences and implications you need to manage, and what tools you need to put in place,” Callinan says.
He points to the famous case of Tesla, where the company was forced to share the source code of its navigation system. Investors and companies need to evaluate and find if there are any risks in the code being used.
Licences are not ambiguous: Mukundaraj says it is very difficult to explain licence ambiguity to your development team, whether it is internal or external. It’s even more tedious to figure out whether your vendors have also complied with the different licences. Licences get pretty ambiguous within selected categories at times, and you don’t know whether you are compliant with them or not.
Certain licences can be used only for educational institutions and not for a commercial organisation. But sometimes developers think it is fine to use them for their proof-of-concept within the company and purchase a commercial licence later.
“You are just not allowed to do that, because the licence clearly says that if you want to use the free version, you either have to be an education society or a non-profit organisation. Otherwise, you cannot use it even for proof-of-concept or proof-of-experiment. Stay in touch with your lawyers, so that you don’t make your own choice of licences,’’ he says.
“Always include security in your checklist as resolving any breaches will cost you more,” Callinan warns.
Also look for the people who are enforcing open source licences. Traditionally, this would be the community’s free software foundation or a freedom law centre. But now it turns out that competitors, individuals, developers and corporates are enforcing these. For example, in the case of CoKinetic Systems Corporation versus Panasonic, the former claimed damages for a hundred billion US dollars and Panasonic was forced to comply.
“If we find text in a company’s code without a commercial licence, they may not be sharing their source code in obligation to some GPL licence. I would look at that as a risky investment. OpenChain can be used to check for mergers and acquisitions. Benchmark a target company, audit its maturity with respect to managing issues, and then you can decide if it is a risk investment or not,” says Callinan.
Check out these tools and tips
There are great projects like SPDX, which is an ISO 5962 standard that can be used by companies. Open source tools and projects should be used for compliance and detection of libraries, snippets, licensing and obligations.
Say, for example, if you look at codes on GitHub, the licence information is never consistent. Some people use copyright statements, Apache licence, and so on. This makes it hard to manage all those different licences coming into your code. In such cases, it’s best to look for an SPDX software package or Data Exchange kind of projects. Callinan says, “The idea of SPDX is to drive consistency of documentation of the licences posted, both in human and computer readable formats. So when you consume software, you can easily identify what licences are in the code. And when you ship your software, you can easily communicate about those licences, which makes it easier to manage the software.”
Narayanam suggests FOSSology be used to understand licensing copyright compatibility. He says, “This binary scan tool will help to find out all the binaries and the corresponding source code that can be risky. And with respect to security concerns, fuzzing angle, peach fuzzer or a scan burp suit can help. FindBugs and Sonarqube can support quality. So, if some project is hosted on GitHub, we can incorporate a lot of tools if it is completely open source.”
Commercial open source software can be used outside the scope of the open source licence. Avci says there are cases where a developer uses one version of a software in a project that comes with an Apache licence. When this software is upgraded to a new version, the developer assumes the licence has been complied with already. But this may not be the case. The compliance check is ongoing. “An open source project like iText has had three major releases in the past and the latest has a new AGPL licence model. A user compliant with the earlier versions just cannot overlook the new licence,” says Avci.
Since it is not easy for small organisations and enterprises to consult lawyers every time, Avci recommends a few simple checks to avoid risking your business. In large enterprises, open source software is often implemented with the help of external software providers. These enterprises may not be aware of what is in the software they receive from a third party software vendor. So it is a good practice to check the software bill of materials (SBOM) as it will tell you if the software given to you is compliant or non-compliant. This is a small step to start with.
Second, developers assume the licence document to be too legal and tend not to read it. But remember, all the initial open source licence documents were formulated by the technical people and not lawyers. “Just take the responsibility to go through the documentation as it may be too technical for lawyers,” Avci adds.
Mukundaraj says that lawyers help to enhance protection. “As developers, read documentation with a technical perspective. If you feel it does not satisfy your project, then go to a lawyer. If you feel unsatisfied, push it through scanning tools; approaching a lawyer with the list shouldn’t be difficult after that. If you are a large enterprise, you will have your own legal team and if you are a small group, look for support from incubation companies,” he says.
He explains that it is still fine to trust the instincts of the technical team head: “If your technical head says that it’s fine to be used as per my knowledge, go ahead and build your software. Before delivery, just ensure the scan is done, and list all the licences and copyrights. Later, you may seek legal advice to see which licences can help you achieve the compliances.”
Compliance is a multi-step process. Apart from the version upgrades, your old version of software may also have some new vulnerability, which is found later. All the vulnerabilities cannot be found in the initial release days of a version of a component. Some security risks pop up after use. Hence, it’s important to either follow various kinds of checks manually depending on your product line or find these automatically using tools. This helps to fix security risks immediately and to keep a constant check on licences.
A way forward
There are tools available that reveal the components used in a product, but if there is lack of understanding about the licence implications, there can be a potential risk in using them. Companies that have an interest in using standardised open source can take the help of global projects like OpenChain, which is hosted by the Linux Foundation. “It tells you how to manage the supply chain of software and, more importantly, how to prove to your customers that there is no risk in using the software. It’s an ISO standard now; you can get a certification that says you have got the processes that manage open source software development. This gives a lot of confidence to customers,” Callinan explains.
According to experts, OpenChain ceates global transparency and uniformity with respect to open source compliance. It helps organisations to customise and developers to comply with various licences.
“As the group lead for the open source education board at OpenChain, we are developing an open chain compliant or awareness programme that will be available as Web based training. We are planning to host it in the Linux Foundation free of cost. This certification will help achieve awareness on the minimum criteria for compliance. We also have some ideas about creating a FAQ kind of playbook for open source compliance. Currently, a playbook for medium scale companies is available and more upgrades will be done. The course titled ‘LFC193 – Introduction to Open Source License Compliance Management’ is now available and the advanced version of LFC194 will be launched soon. Developers just have to continue participating and contributing to all the OpenChain education or any tooling meetings,” says Mukundaraj.
Callinan warns that stricter regulations are forcing tech companies to submit their SBOM. The US White House has imposed these regulations to improve the nation’s cyber security, and this can affect all software exported to that country. “There will be a point where software solutions cannot be exported to Europe or the US, unless they comply by these regulations. So, start complying with them right away,” he concludes.
| Well-known litigations with respect to open source compliance |
|
