It's a common practice these days to use open source packages when building software applications. Open source packages are convenient: there are options out there for pretty much anything you need.
If you're building commercial software products, it's important to remember the compliance requirements that come with these packages. How the open source packages are licensed dictates how you can use them.
Being non-compliant exposes your organization to legal risks, and could potentially result in a loss of trust from the open source community. Worse, you may have to spend engineering hours dealing with the complications from the fallout (such as untangling your codebase, etc.).
Some organizations have a formal approval process in place to review and audit open source packages before they can be used by developers. This process involves a legal review, an architectural review, a form to fill out, an issue tracker ticket to create, and so on.
For others, this process may be too heavy and slow.
In an ideal world, at any given time, you know exactly where all the open source packages are used in your codebase - and importantly, if how you use these packages are compliant with how they're licensed.
At Datree we've been working on automating adoption of all kinds of policies - including compliance-related ones. Our product comes with rules to help you achieve SOC 2 compliance, for example.
We're happy to have released new rules and features to help your team be compliant with open source licenses:
- Prevent Copyleft license dependencies
- Prevent unlicensed dependencies
The report now shows dependencies that aren't following the above rules, allowing you to monitor any deviation from your organization's OSS licensing policies.
The data is exportable and can be used for OSS license audit purposes.
If you're interested in getting a live walkthrough - and assess your codebase for "rogue" open source packages in the process - we'd love to talk to you! Just book a time that's most convenient for you here.