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.
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
Make all code 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.
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.
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.
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.)
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.
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.
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.
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
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.
Become the obvious choice
Make your software more user-friendly than alternatives. Make your open source offering better than other open source options in the same space. When you become the default choice for open source users, converting them to paid plans becomes much easier. You want people to come to you regardless of whether they are looking for open source software or a paid product.
Don't be afraid of competition. If a large company like Microsoft is adopting your technology, embrace it and use it to establish yourself as the expert. If competitors are white labeling your software without attribution, make sure everyone knows it is based on what you made. Make a page on your website that lists all the companies building on your software. Make your company look as big as possible. Then, look at what they're selling, as it’s probably an indicator of demand. Look at which ones are successful and what they are selling, and go build that.
Last updated
Was this helpful?