When you want to share your source code (components, libraries, dependencies, etc.), you need to attach an open source software (OSS) license to it. Then other developers can freely use it or modify it in their work (to the extent defined in the license).
In many cases, there are obligations in addition to the rights granted by the OSS license. Once the user distributes the code, these obligations will apply.
This is Linux FoundationAccept it:
“Open source compliance is the process by which users, integrators, and developers of open source software comply with copyright notices and meet their open source software component licensing obligations.”
Why do you need to worry about license compliance?
Failure to comply with the terms of the OSS license or failure to attach one may at best cause trouble replacing components; at worst, it may lead to legal proceedings and the risk of losing ownership of your proprietary code.
Some other potential consequences of non-compliance may include:
- Restrict sales of your software products until compliance is reached
- Restrictions on distributing products before the source code is released
- Endanger your ownership of proprietary code
- If the problematic dependency is found late, the additional cost of product development
- Negative user feedback and loss of reputation among customers and the open source community
- Legal costs for resolving claims
Many people will remember cases of violation of the GPL D-Link, Tom tom, with more Companies in the early 2000s. Without exception, all defendants for non-compliance claims must ultimately comply. Compared with following basic compliance procedures, these companies spend more money and time to resolve non-compliance claims.
Why do I need a license? Isn’t open source free to use?
Can’t you release code publicly without a license?
The short answer is no. If your software does not have an open source license, it will not be open source. According to copyright law, such software is protected by copyright by default and has all the restrictions that this implies.
If you want anyone to use your code freely, you should make sure that something is commonly referred to as “Four freedoms“. They said that operating system software can be used, researched, modified, and distributed freely as long as they comply with the license.
For the first three, there are no conditions; you are free to use, research, and modify the code for any purpose.If you go beyond that and decide to distribute your modified version (or original version), then this is Open source license compliance Start.
The lack of license text is the primary cause of license infringement cases, as we have seen above, this can lead to loss of ownership and enforcement measures (such as temporary injunctions).
Are you using the correct open source license?
Using the wrong license is another common problem. This may have a large-scale impact on popular open source projects.
Some people may remember map Changes in license terms resulted in version downgrades and removal of Nmap components from open source Linux distributions.
When choosing a license, please carefully consider how you want users to use it and the license’s provisions on copyright and jurisdiction.
Some licenses are very permissive and easy to comply with, such as Apache, BSD, MIT, and X11. With licenses such as CDDL and Mozilla, simply submitting the code back to the community repository may be sufficient, but some additional considerations may be required. A strong copyleft license like the GPL may require a review process.
Your project may require a combination of many different licenses, just like most larger projects. This brings additional challenges because you must ensure that the permissions and conditions of the license do not conflict with the requirements of another. Permissive licenses are usually compatible with each other and, therefore, are often used as components of proprietary software. Permissive licenses are also compatible with copyleft licenses.
Copyleft licenses are the trickiest to use on commercial products because they require the public release of any derivative code under a compatible copyleft license.
How to master the open source software license
90% of the code in most commercial software is open source, and these codes usually come from third-party sources.
Therefore, developers or companies need to work hard to learn the code base of all their products to ensure that they are compliant and there is no conflict between licenses, comply with all conditions and make necessary attributions.
A clear policy regarding OSS compliance is required. The goal is to have a list of all open source components, their dependencies, and corresponding licenses in the code base.
Many software development teams still perform this operation manually. Although this may be enough for the component and its license, if we add dependencies to a combination that may have completely different licenses, things get quite complicated. For large engineering teams and software developers, license compliance becomes tedious and time-consuming.
Open source components may rely on countless licenses that can only be detected by scanning using semi-automated tools. This type of scan can help identify problematic licenses or detect unlicensed or unstandardized licenses buried deep in the code.
There are many tools available; some of them are called file scanners or code scanners, and others are called CI (continuous integration) scanners and component identification tools.
It is usually worthwhile to use it because the open source code used in the product can be identified and its license can be verified relatively easily and quickly.
