Short answer: Three things: a written open source policy, a tracking process for the open source code and its license terms, and an annual review to make sure your developers actually follow the policy.
If you operate a software-based business, you are likely using some open source code in your product. There is nothing wrong with that. It is common, and probably a best practice. But what is your process to review and track that code, and the associated license terms? Here are three thoughts from a software licensing lawyer on building an open source policy that actually works for a software company.
1. Written Open Source Policy.
Think through (a) what situations make sense for your company to use open source code (perhaps for functionality that is not core to your offering), and (b) what types of licenses you will and will not allow. Permissive licenses like MIT and Apache 2.0 usually require only attribution, while copyleft licenses like the GPL can force you to disclose your own source code if you distribute it. A common rule is to avoid GPL-licensed code in anything you ship to customers. Write the rules down in a policy and make sure every developer knows them. A written open source policy is the cheapest insurance against an OSS-license blowup during due diligence. If you want an outside framework to anchor your policy, the Linux Foundation’s OpenChain standard (ISO/IEC 5230) is the recognized baseline for an open source compliance program.
2. Tracking Process for Open Source Code.
Tracking where you use the open source code and its license terms is critical and easy to do along the way. Your process could be as simple as a spreadsheet listing the name of each open source component, which of your products and versions include it, the license requirements, and a copy of the license. This is super simple if you implement it along the way, and really hard to recreate years later when an acquirer or the CEO needs to know what open source code is embedded in your product. Modern teams formalize this as a software bill of materials (SBOM), often using the SPDX standard. Your open source policy should make this tracking a named responsibility, not a nice-to-have.
3. Annual Review of Your Open Source Policy.
Whoever is in charge of your open source policy (and you should have one named owner) should annually review that your developers, including contract developers, are aware of and follow your policy. The annual review is the difference between a written open source policy that lives in a folder and one that actually governs developer behavior. It is also the moment to catch new components that slipped in without a license check.
Why Your Open Source Policy Matters.
The reason all of this pays off shows up at the worst possible time: a financing or an acquisition. Buyers run open source scans during due diligence, and an undocumented GPL component can stall or reprice a deal. A clean policy, an up-to-date SBOM, and a documented annual review turn that diligence question from a fire drill into a one-email answer. For a small company, that is real leverage at the table.
Open Source Policy: Common Questions.
Do small software companies really need an open source policy? Yes. If you ship code or run a SaaS product, you are using open source, and a one-page policy plus a tracking sheet is enough to start. You do not need a 25-page document.
Which open source licenses should we avoid? Be careful with copyleft licenses like the GPL and AGPL when you distribute code or offer a network service, because they can require you to release your own source. Permissive licenses like MIT, BSD, and Apache 2.0 are usually safe with attribution.
Who should own the policy? One named person, usually engineering leadership, with the authority to approve or reject components and to run the annual review.
Most small software companies need at least these three basics in their open source policy, not a 25-page document. Keep it short, keep it current, keep it followed. I hope this helps.
For the technical-legal analysis on when GPL copyleft attaches versus when it does not, see Linking and the GPL (Technical and Legal Analysis). For the SaaS-specific version of the same question, see AGPL: What Every SaaS Company Should Know.
Resources:
Linking and the GPL (Technical and Legal Analysis)
AGPL: What Every SaaS Company Should Know
Disclaimer:
This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.
Discover more from Aber Law Firm
Subscribe to get the latest posts sent to your email.