Licensing & Distribution
Open core software includes both open source and proprietary licensing. Proprietary code should be source-available but require a license or subscription to use.
One distribution with two licenses
Keep all the code in a single repository whenever possible and make it available for both self-hosted and SaaS deployments. The proprietary code is source-available, and the features in the proprietary codebase are activated by a paid subscription.
The alternative is two distributions with separate licenses, which adds friction when a user wants to use proprietary functionality. Not only do they have to get a license, but they also have to reinstall the software. That’s a big hindrance that can slow the adoption of the commercial software. Separate repositories are technically clean, but they reduce monetization potential.
Problems with separate repos
Changes need to be made in multiple places, duplicating efforts
If a user has a problem, they have to figure out the right repo to submit a PR to
If a user has a feature request, they don’t know where to send the request because they don’t know whether it will be open source or proprietary
This is easiest when you are both the author of the open source project and the founder of the company. If you aren’t the author of the project, you will need to get permission from the people running the project to add proprietary code.
If you don't control the upstream repo, build trust first.
Many open core companies build on existing open source projects they don't control. If you're not the maintainer of the upstream project, focus on becoming an active contributor before seeking integration. You should be contributing to the open source codebase to the extent that project maintainers see you and your company as a positive influence. Once you've established yourself as a trusted contributor, consider asking the upstream maintainers if you can add your proprietary code directly to their repository. The key is demonstrating that maintaining separate repositories creates extra work and inefficiency.
Maintaining a soft fork
If you are working with a community or foundation-owned open source project and can’t integrate the proprietary code into the upstream project, combining source code into a single repository may require maintaining a soft fork and pushing features upstream. It’s a “soft fork” because the open source part stays the same. You just add the /proprietary subdirectory and a few hooks to load those files. Any open source improvements or features are upstreamed.
This does require a significant amount of resources and the responsibility of keeping in sync, but the result is a better experience for the end-users of your open core product. Stay heavily involved with the community to reduce the risk of the forks splitting. You will have more influence over the overall direction of the project if you are a well-respected contributor and can more easily mitigate potential issues between the upstream fork and your downstream version.
Use permissive OSS licenses
OCV prefers to start companies around projects that have a permissive license (e.g., MIT, Apache, or BSD) or the possibility of relicensing. It’s best practice to use the same open source license as the project. We will consider projects that aren’t permissively licensed on a case-by-case basis, but advocate for MIT whenever possible.
Relicensing should be done through the influence of the author of the project or the key contributor in the community. If relicensing, release a blog post (example) explaining the rationale behind this change to the open source community.
Open source licensing guidelines
Use the same license as the open source project
MIT is the preferred open source license
Use the Developer Certificate of Origin for managing contributor copyright
License templates
The licensing for a repository should be stated in the master directory of the repository in a document titled “LICENSE”. Where different portions of a repository have differential licensing, it is best to be explicit about that differential licensing. The license document should describe explicitly which directories fall under which license and where specifically the software is proprietary.
It’s best practice to put proprietary features in a /proprietary subdirectory within the open source repository. Avoid naming the subdirectory /ee or /enterprise-edition. The licensing can be described in the subdirectories themselves under separate license documents referenced in the master directory in the format of:
All content that resides under the "subdirectory/" directory of this repository, if that directory exists, is licensed under the license defined in "subdirectory/LICENSE".
Alternatively, you can delineate open source and proprietary code on a file-by-file basis, but it makes it really hard for people to quickly get an idea of what's proprietary and what's not.
Proprietary code is source-available
This might seem counterintuitive, but transparency in your proprietary code creates significant advantages. We recommend that all OCV companies make proprietary code source available so anyone can contribute. There is no great reason not to do this. Maybe competitors are copying you, but we’ve never seen a startup die because of this. Startups die because no one cares enough about them, no one is using their product, and their product is not improving fast enough.
Offer both self-hosted and SaaS options
Most companies should offer a SaaS version of their software. This isn't about replacing self-hosted options but rather giving customers a choice and creating an additional revenue stream. Keep your SaaS version and your self-hosted version as similar as possible.
Typically, the SaaS version has the same open source features offered in a free tier, but with usage limits like "no more than three users per team" or other restrictions. The code itself should still be visible and modifiable. Make the proprietary features available in both options. If you create them in the SaaS version, make them source-available in the self-hosted version, too.
Telemetry is default on
Telemetry should be on by default, with an option for users to opt out. Otherwise, most users won’t enable it. Telemetry collection must be completely transparent:
Document exactly what you collect, why you collect it, and how it benefits users.
Provide clear opt-out mechanisms and never hide data collection behind unclear documentation.
Write a blog post explaining your telemetry approach. Detail what data you collect, what you don't collect, and how it helps you improve the product.
Make it easy to disable. Show that you respect user privacy and aren't trying to hide anything.
Include a value-exchange
When adding telemetry to an open source project, you need to include a value exchange for the user. For example, when users have telemetry turned on, it checks if they are on the latest version, and users get automatic vulnerability alerts.
Consider making telemetry opt-in for security-focused audiences. The data loss is worth avoiding community trust issues that can permanently damage your reputation. When users discover "hidden" telemetry, they assume the worst about your intentions—even if your data collection was reasonable and well-intentioned.
Activating proprietary features
To activate the proprietary features, the customer instance talks with your entitlement service. They report statistics (customer ID, number of users, aggregate usage numbers of certain features), and you report to them how many users they are entitled to. Don't have license files; it should be an online check.
Use a Unique ID for each customer (probably, UUID)
Customer ID comes from your sales software (Zuora, Salesforce, etc.)
Last updated
Was this helpful?