Open source software makes code available for others to view and, subject to its license, use or adapt. It can accelerate development by supplying components a team need not build itself, from libraries to databases and operating systems. Availability is not permission to claim ownership: check the license before incorporating code into a product. section 8.7 section 8.7.1
The license is a business decision, not just a developer preference:
- Copyleft licenses such as the GPL can require software that uses the licensed code, including modifications, to be released under the GPL. Assess that obligation before using such code in a proprietary product. section 8.7.1
- Permissive licenses such as BSD, MIT, and Apache allow use in proprietary software, though some require a public notice. License terms can also differ on copyright, patents, and derivative works. section 8.7.1
Make reuse routine without making it uncontrolled. Publish a list of acceptable licenses, use libraries as libraries rather than passing copied code off as original work, and keep a central register recording each library’s name, website, license, and the component that uses it. If a license permits copying a code block, register that use too. section 8.7.2 section 8.7.4
Why the register matters
In technical due diligence, a buyer may check who legally owns the source code. Discovery of large blocks lifted from open source projects and presented as company-owned code can put a deal—and confidence in the rest of the codebase—at risk. section 8.7.4
Publishing your own code can invite debugging help and contributions or help establish a standard. A small library developed alongside a larger product may be a good candidate, but publication creates an ongoing maintenance commitment. Before release, agree on the purpose and packaging with the CEO and legal team; confirm the company has the right to release the code and that it contains no trade secrets or company intellectual property that should remain private. section 8.7.3
