The last few weeks we looked at various types of licenses and what they entail. Now that we know a little bit about them it’s time to look at the approach of using multiple licenses or hybrid software licensing.
The ins and outs
Multi licensing is the practice of licensing your work under multiple different licenses so that others can choose under which license they want to use it or work on it. The practice emerged in the early aughts addressing the need for making open source development profitable. It allowed developers to create proprietary variants of copyleft software and was intended for those who wanted to work on it, but either wanted to monetize their work later or just didn't want to publish their source code. The usual way to go about this is dual-licensing software under a permissive license like MIT and a copyleft license like GPL.
For example Perl is licensed under GPL and their Artistic License to make it available to both groups.
Credits: undraw.co
Takes two to tango
GPL is a copyleft license, that means under this license any derivative work has to be licensed under GPL (or a compatible copyleft license). That's why it’s often called a viral license because it carries over from project to project. This led to the approach of dual-licensing and by that way giving the developer community a choice between using the copyleft or the proprietary variant:
- those who wanted their work to remain copyleft and free to use would choose the GPL license.
- those who wanted their work to be monetized later or didn't want to publish their source code would choose the proprietary license.
But wait, there’s more
Issues with license compatibility made some even use tri-licensing to maximize compatibility. Like Mozlilla with both Firefox and Thunderbird being licensed under their Mozilla Public License, GPL v2 and LGPL v2.1 Mozilla later updated their license to include compatibility clauses for GPL which made tri-licensing a bit redundant.
Ruby used a similar approach using Ruby license, GPL v2 and the 2-clause BSD license.
Why should I?
Today the growing popularity of permissive licenses, as well as fixing some of the compatibility issues in copyleft licenses, has somewhat simplified software licensing. However some issues are still present, especially in connection with copyleft licenses. GPL is still widely used and is incompatible or only one way compatible with numerous other licenses. That makes multi-licensing a viable approach with some advantages:
project flexibility - developers can choose whether they want their work to be copyleft or proprietary and if they want to make their source code public and available for modification or not,
best of both worlds - combining wide ranging continuous code improvement through the community while maintaining the possibility of monetization through commercial licensing,
variability - you can offer a freemium version for everyone to work on and a subscription based commercial premium version for end-users,
simplicity - avoiding various headaches with license compatibility.
So if it’s so great why doesn't everyone do it? Well the obvious drawback is the added work in maintaining more than one license. In a community that values simplicity more straightforward approaches are usually favoured. But hey who says you can't zig when everyone else zags?
A guest blog post for GraphQL Editor blog by Michal Tyszkiewicz
Speed up your GraphQL API development
GraphQL Editor is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster. Try GraphQL Editor for free!
Top comments (1)
Can you please also explain BYOL?