Intellectual property3 min read
Open source in your startup: free to download does not mean no conditions
Track licences, how you use each component and what you ship. A dependency inventory is more useful than a blanket ban on open source.

Open-source software can be central to a startup's product without being a legal problem. The problem is not knowing which licences apply and how the product uses the components. A licence grants permissions subject to conditions. Different licences impose different obligations, and a repository described as public does not necessarily have an open-source licence at all. Make a dependency inventory part of engineering work rather than waiting for an investor questionnaire.
Record the version and the actual use
For each important dependency, keep the package, version, source, licence and whether you modify, distribute, embed or only run it internally. Record frontend code delivered to users separately from server-side components. Include copied snippets, containers and fonts, not only packages in the main manifest. Example: your backend may stay on company servers while a browser bundle is delivered to every customer. Those deployment facts can change which licence conditions are triggered.
Do not reduce every licence to permissive or viral
Permissive licences can still require copyright notices and licence text. Copyleft obligations depend on the particular licence, version and relationship between components. The GNU GPL and AGPL are not identical: the AGPL contains a specific network-interaction provision for modified versions. Avoid declaring that every SaaS product is exempt from source obligations or that every use forces publication of the whole business. Read the applicable text and obtain advice for combinations where the scope is uncertain.
Make compliance reproducible
Create a place in the release process for required notices, source offers or other obligations that actually apply. Keep the relevant source version and build information when needed. Assign ownership for licence changes when dependencies are upgraded. An automated scanner helps find material, but a green report is not a legal conclusion about linking, modification or distribution. Review exceptions and document why a component is acceptable for this product and deployment model.
Keep sales promises consistent with the code
Do not promise a customer that every line is exclusively owned by your company if the product includes licensed third-party material. Describe ownership and licence exceptions accurately in contracts and due-diligence documents. Ask contractors to disclose dependencies and avoid incompatible promises in their IP assignments. The useful fact is that open source is often commercially usable; the task is to comply with its conditions. A maintained inventory and a small approval process make that possible without asking developers to reinvent every useful library.
Sources
- Swiss Copyright Act(Arts. 10, 16 and 17)
- GNU Project: licence FAQ(GPL, AGPL and distribution)
- GNU Affero General Public License version 3(Section 13)
