MIT is the preferred open source license, and using the same license as the open source project is the best practice. OCV prefers to start companies around projects that have a permissive license (e.g. MIT, Apache, or BSD) or the possibility of relicensing.
Open source license decision tree for OCV companies
OCV will consider projects that aren’t permissively licensed on a case by case basis. We strongly prefer to relicense whenever possible. This should be done through the influence of the author of the project or the key contributor in the community. If relicensing is an option, we strongly recommend to relicense to MIT and release a blog post (example) explaining the rationale behind this change to the open source community.
An open core company’s product has one distribution that includes both open source and proprietary code. The entire distribution should be publicly available and available to download. The proprietary code is source-available and the features in the proprietary codebase are activated by a paid subscription.
Proprietary features should be stored in the same repository as the open source code in a subdirectory called /proprietary. Avoid naming the subdirectory /ee or, /enterprise-edition. For example, GitLab’s proprietary code base is a subdirectory. The subdirectory is in the same repository that contains the open source code.
The licensing for a repository should be stated in the master directory of the repository in a document titled LICENSE (example). The license document should describe explicitly which directories fall under which license and where specific software is proprietary. When different portions of a repository have differential licensing, it is best to be explicit about that differential licensing.
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".
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.
The open source project and the free version of your software are typically not the same thing. The open source project should always remain open source and be available to download, use, and modify via the repo it’s stored in. There are no restrictions, limits, or constraints on the open source version but it’s not usually available as a hosted SaaS product. It’s important to maintain a good, usable version of the open source project and contribute back to the open source community.
The free tier is typically a hosted SaaS product that includes all the same functionality as the open source software and includes some access to proprietary features and functionality. Limitations within the free tier should focus on quickly driving users to the paid tiers to reduce friction. We recommend providing a limited trial of premium features in the free tier upon signup.
The open source versions and free SaaS versions don’t need to match.
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 software is proprietary.