Open Source Licenses
Splitting the term Open Source, Source is your recipe to the software (source code), and open is the license.
Open source licenses are licenses that comply with the Open Source Definition, and are approved by the Open Source Initiative. A solution isn't Open Source unless it's shipped with one of these licenses. All of these licenses have a few things in common. Each and every license ensures freedom to the users:
- Freedom to Run
- Freedom to Revise
- Freedom to Remix
- Freedom to Redistribute
Apart from the basic 4 freedoms, they also share attribution required (copyright notice) as a common part.
Copyright in general means no one can use, copy, modify, or distribute your work without being at a legal risk.
Copyright and licensing are both foundations of FOSS2, and they’re both also important elements of the larger world of intellectual property (IP). It wouldn’t be a stretch to say that copyright and licensing aren’t the actual foundation of FOSS, IP is. Not only is IP the basis of FOSS, it’s a critical element in nearly every business.
VM Bressure
Open Source authors wish their solution to be used, modified, and shared. As the legal default is exclusive copyright, you need to explicitly give these permissions with a license.
License
When thinking of different Open Source licenses, it's easier to understand different types, or different families of Open Source. As open source is about providing freedom to the users, we will talk about Open Source licenses on a spectrum of freedom provided. We will start with permissive mostly because these licenses are easier to understand. They are written in simple language, and are often less than a page.
Permissive family
Permissive licenses, as name suggests, are Very PERMISSIVE - people can do whatever they want with that work under any terms. They can take the open source code, mix it with closed source, or take the code, make improvement to the code and make it open source or choose not to open source it. It’s really up to the consumer to do whatever they see fit.
Permissive licensed code gives all the 4 freedoms we just spoke of, but it doesn’t REQUIRE that derivative work has to preserve all the freedom. Anyone can modify and make it closed source What is required though, is attribution! SO if you are going to use a permissive licensed code, you have to give credit in a visible way. Some license might add different language like you can’t use the same name of the project in a derivative work, some might add a patent clause.. but for the most part, it’s all about attribution! Example of some permissive licenses
- MIT license
- Apache software license
- Any of the BSD license
Benefits of permissive licenses
- Easy to understand
- No strings attached
As discussed before - as they are Written in simple words, and language is less than a page: you dont’ have to be a lawyer to understand what they are asking you. So the compliance overhead for a permissive license, is very low. It’s all about the attribution and it’s an easy thing to do in development lifecycle. It’s gives the most freedom to people to do as they say fit. Another strength to a permissive license: it’s easier to disrupt the market in an emerging market. Few big players 1 - 2 vendors, If there is a monopoly with a proprietary closed source solution that most people are using in the industry You show up with a open source solution that gives a competitive alternative to these paid proprietary closed sourced solution, people get very interested in the work because of its nature of being open source and their ability to exercise freedom in how it’s used. They have more flexibility in how the software fits into their solution’s puzzle and they can innovate on top of it. Permissive license works especially well if you are thinking of conversion or if you are trying to build customer who might already be using a proprietary or closed platform, there is a good chance that these clients might already have their own software they build on top of the closed source tool they are licensing out. Or they have their own content, software, data – different pieces whatever it might be that they built around that platform. So permissive license, the big benefit is that you can mix open and closed software. There is nothing preventing you in doing that and that relieves the burden. So it’s easier to convert customers and they can utilize the toolings they have already build and plug together. That’s why permissive licenses offer that disruption in that proprietary or closed source ecosystem model because people can come with whatever they have wheter open or closed source and that will work with your open source solution.
Cons of permissive licenses
One of the often discussed downside is little to no control over reuse. You don’t always get that insight into how your work is being used, you don’t see different usecases and outcomes. YOu won’t understand how people are modifying your work. You also have the risk of Someone with more resources or more engineering capacity can fork your project and do things with it, you won’t be able to benefit from their work if they decide to compete with you. As we just discussed, no strings attached, it’s all part of the deal. Another challenge can be viewed in terms of collaboration. Forking is often encouraged. People always tend to do what’s easier for them and if you have a permissive license, it’s easier for people to just fork it, modify it in a way that works for them and carry on with their day. It doesn’t incentivize collaboration the same way other licenses we would talk about. It can promote sometimes improvement in isolation. It doesn’t mean collaboration doesn’t happen, but we are just talking about what people are going to be incentivized for.
Copyleft family
So the big difference in copyleft license is some of the extra languages in license. Remember the 4 freedoms? permissive license doesn’t enforce it. CL have languages have say “well, if you are going to make changes, or modify this work, or combine in something else, you have to still follow those freedoms”. So you can’t change the license and you have to follow the same rules and requirement of the original license. So if you are going to combine a copyleft licensed code in your permissive project, the general rule is “anything that copyleft touches has to be open source”. It’s generally the rule. Examples Any of the GPL license There is the original GPL license But also a more strict license AGPL (affero GPL) There is a less strict GPL license called lesser GPL There is also one mozilla license And a new notable one that has a piece around the data in it is cryptographic autonomy license
This time let’s start with the downside The biggest is, these license are coming with more strings attached and not everyone is going to like those strings Two example of that Google has an open source program office and they also publish all their policy and processes around open source in public. Anyone can go and read them. I am going to share a specific page from that which is around their AGPL policy. AGPL is a strict copyleft license that we will talk about but looking here, see how Google has restricted all uses of it. “It’s easier for them to so NO AGPL, we don’t want challenge around compliance” I would not be surprised if more companies have policy like this
This can be a disadvantages or an advantages depending on your business strategy and how you see your partnerships. You have a safe guard around someone out-resourcing you competing you with your own code but also, like google, not everyone would be willing to play ball with this term.
Second part usually fits in with governments, NGOs, medical industry or even some banking systems. Anyone who might be working with legacy tech stack, older technology, things that weren’t really build using modern cloud, and, modular approach - If you have to combine a CL code with a legacy tech stack, you would have the same obligations, to open source the code. Which they might not be wiling or able to make open source. Especially if you have passwords, credentials, api keys hardcoded in your code base and you haven’t really designed those to having those secrets abstracted out from teh project, open sourcing can be a big challenge for you and CL is going to enforce that. So if you have a potential use case where a tenant/customer ho might want to combine your CL code in their own system or tech stack, there would be implications and they might not have the resources to follow the rules consideration : need more resources to succeed like documentation, community engagement Pros Copy left is for community - incentive model changes (compared to permissive) If someone is going to modify the work independently, they can still do that but they will have to follow same terms. In many cases if you are going to use the project, not only you have to maintain the new changes, you have to maintain the whole tech stack and also all of dependency change. It’s easier for you to package and submit your improvements back to the project - you don’t have to maintain it and now you can rely on the upstream Allows you to create an ecosystem like wordpress Unique because huge range of open source plugins, tools, themes that’s build around core software People build around you, and you pick what you need to grow in shared direction