Curated by Anindeeta Chakraborty
If you want to earn money from your open source software, then go for restrictive licenses, not permissive or public domain licenses.
Any source code, which is open to public is open source. If the source code is not available to the public, it is not an open source. If you are giving out the software for free and if the source code is not available to the public, then it is a freeware and not an open source software.
There are certain guidelines for a software to be qualified as Free Software Foundation (FSF)/ Open Source Initiative (OSI)-approved open source.
The basic rule is that open source code should be given to the user to run it, study it and modify it. The user should also be allowed to share the modified /unmodified part. If these four permissions are given by the author to any user, then it is an FSF/OSI-approved open source software.
There are three aspects of open source software: What, How and Why
WHAT – A source code which is shared within a community is open source software. An open source software follows a decentralized development approach. This means development does not happen at one centre, it will be developing on a global scale and everyone would be developing it.
HOW – Any individual or company trying to integrate open source should have proper open source guidelines. They should have a team dedicated to comply with the license obligations, a team who is well-proficient in reading the open source licenses that are usually very tricky. Last but not the least, they should have security vulnerability check for each and every component they are integrating in their own software.
WHY: Why a company or a startup or an individual should integrate open source software into their own product? Why there is such need that you have to incorporate a software that is not built by your own team?
Now, let me give you answers to these questions.
First, it will help reduce the development cycle. As the technology is moving on and as we are progressing, the development cycle is getting lesser and lesser day by day. Earlier we use to receive a new version in a year, now it has gone down to one month. The companies are releasing improved versions every month. So, the only way we can cope up with this fast pace is to use the already built-up module available in the open source domain.
Second is cost reduction. Usage of open source is not about profit because well-established company will not care about any cost, they are more concerned about their product. What they want is that the product should fulfil all the advertised functionalities and live upto the expectations, but usage of open source will still help them reduce the cost of the products.
Third is getting the bleeding edge technology. It is something which is really new in the market. The company developing the product may not be good or at par in market with the technology. Then they can use already build-up module and integrate it with their own software.
According to the golden circle, the vision should be why we are doing it and then we should build a strategy around it and then develop a product around it.
So, if we are developing a product by keeping ‘the why of open source’ then we should first have a strategy, all the guidelines and basic teams and then develop the product. Thus, you will able to create a full proof open source included product.
WHILE LICENSING YOUR SOFTWARE, YOU SHOULD INCLUDE A ‘NO WARRANTY CLAUSE’ SO THAT NO ONE CAN COME BACK TO YOU AND SAY “BECAUSE OF YOUR SOFTWARE I HAVE SUFFERED THIS LOSS”
Licensing of the open source software
Open source software can be licensed in three ways:
You can put it down in public domain where you do not need to put it down under any license. You can say that it is for public, for the welfare of the developers. But there are few downsides to this, as there will be no warranty clause.
Apart from WTF Public License and CCO (Creative Commerce License), these licenses do not have warranty clause. So, the company, developer or individual using your software can come back to you and say they are suffering loss that because of your open source component. This is a very important aspect that you should understand. Whenever you are trying to license your software, you should include a ‘no warranty clause’ so that no one can come back to you and say “because of your software I have suffered this loss”.
That’s where permissive licenses come in the picture. These are licenses that do not put much restrictions on user/companies and are very friendly for developers and authors. So, if an author is putting his own contribution through MIT license, then MIT license has an expressive clause where it says, ‘you cannot just go against author and ask him that we have suffered this loss’. You cannot blame author for any loss you are suffering as this software comes with no warranty.
If your software has a registered patent, then I would suggest you go out for the Apache license because it has an expressive patent clause which grants any patent rights to be given to the user who will be using that software.
Why is this important? Let me explain it this way – If you have an open source software and a well working algorithm, a patented algorithm, and you are using MIT license, then you are not giving the patented rights to the user. So, the user will be worried that though he is using a patented algorithm, he has no right to use that algorithm. This will inhibit him to use your open source software and go with some other open source software. This is where an Apache license will help you to license all the technology you have and all the algorithm that you have created to open source domain.
And the last one is restrictive license. If you want to monetise, the permissive licenses and the public domain licenses won’t help. If you want to earn money from your open source software, then you must go for restrictive licenses. In a restrictive license, an author can put multiple restrictions and if a company/individual wants to use that software without that restrictions, they need to come back to the author and ask for another copy, licensed in a permissive way or in a commercial license.
This is where the catch is. You will be shipping out your open source software into the public domain, where there will be multiple users. Day by day it will grow up, and soon when the corporates will look at it, they will be needing the software with less or no restrictions.
This is how a developer/author can earn money by giving out a commercial license to the user. A few of the restrictive licenses are General Public license (GPL), Lesser General Public license (LGPL) and Affero General Public License (AGPL). They come with different restrictions.
Explanation about GPL, LGPL and AGPL licenses
LGPL is created for the benefit of users so that they can incorporate libraries into their own proprietary product without sharing the source code. However, they are required to dynamically link the LGPL license component.
In case of GPL, they can only link if it’s in a cloud or through a CLI (Command Line Interface) mode. If the user is not invoking it in cloud or CLI, they must share their own source code into the public domain.
When the founders of FSF/OSI realised that people are taking advantage of GPL they included a clause which says, “if the software is communicated over the network then the virality clause will also be applicable.” So, if you are planning to monetise your software, I would suggest you go for AGPL from the beginning. AGPL is the most restrictive license and chances of someone taking benefit of your open source component will be less.
One mistake the developers usually make is that during the initial time when they are developing their code, they put it under MIT license and for the later version they use AGPL. Any organisation who wants to use the software will see two versions available in the public domain: one version in MIT and another in AGPL. Now, you cannot relicense the copy which is already with the user, and they will only go for MIT and not AGPL. This way they can avoid paying the development fees. So, if you are planning to monetise your software, then you should put all the code under AGPL from day one.
“A license is basically a contract between you and the user. You can file an infringement suit and say into the court of law that these were the terms in which we agreed on and that the user was supposed to release his own proprietary code. Say for example, if it’s a big tech giant which is earning billions of dollars, they will never release its own proprietary source code. So, if they have infringed and if they have not complied with the regulation and license obligations, you can file an infringement suit and get a lot of money in return. But if it’s an individual developer, all he needs to do to comply to the license obligations is to give his own proprietary source code into the public domain. The contract begins the moment user starts using the components. From there on, the author can enforce the contract under which he has opensourced his contribution.”
Putting the code under restrictive licenses has a lot of disadvantages, but at the same time if you are planning to earn from it in the long run, then you should go for AGPL.
The difference between AGPL and GPL is that AGPL will have over the network clause.
One thing which the founders of OSI initially missed is that they said that a software is conveyed through some medium, but the internet was not covered in that. So, the companies started putting all the open source components into cloud. While the software is in cloud, it is not conveying the software as such, but they are using the open source component, a GPL version, without sharing their own proprietary code. That’s why they came up with APGL to give all the restrictions over the network.
‘Never call it a product’
Now you have a product and you want to open source it and you want to monetise it. How you would proceed for it. One of the basic pillars of it is ‘you should never call it a product’. The moment you call it as a product, people will think that it’s a finished product and there is nothing to contribute to it. But if you are calling it as a project, something that Apache and Linux are also doing, they will become contributors. They will contribute to get benefits out of it and to get recognition. It should be looked up as a community engineering collaboration and not an individual or one man show. You should put your open source software into a repository such as Github. Everybody should be allowed to collaborate, integrate and submit their contribution. That’s how the project can improve drastically because multiple people are contributing to it.
You also should never take complete control of the project, because then it becomes just another proprietary software doing all work.
IF YOU ARE PLANNING TO MONETISE YOUR SOFTWARE, THEN YOU SHOULD PUT ALL THE CODE UNDER AGPL FROM DAY ONE.
Ways to earn money from open source
There are four ways under which you can earn money from open source.
1.Donations – Wikipedia has been doing this. But it all depends on your company size or product. If your company or your product can reach to a large number of people, then you can get donations.
Example – A person shared that he has a mobiles OS but is not getting enough donation. In a span of three-four years, he was only able to get around 30 dollars.
2.Web apps – If you have a website and you are getting enough clicks, because people are coming there to download your open source software, then you can earn through that also.
The following two are the real ways by which you can to earn money.
- 3. Support and maintenance– Red Hat has been doing this already. Here you will create a great product and put it out in the open source market. People will be contributing to it and it will get better every day. And when the big companies/corporates want to use it, they will need some assistance support or extra capabilities which are not available in open source market. Here, you can charge the company for those services, maintenance and for giving them better quality.
4.Dual licensing- When you have a software, there are two ways you can license it, either under a copyleft license and proprietary license. Many websites such as Facebook, Twitter, YouTube won’t show you ads or ask for premium subscription at the beginning. They will just try to get users in the beginning.
When you put your software into the opensource market, people will come for it as free is always accepted by everyone. With time your product will grow, users will increase, people will contribute, and it will get better and better every day. That is the time when you can start giving out proprietary or commercial license copies of your own software, with no restrictions.
You can set a value for commercial version depending upon who is buying it. If it’s an individual or a company, in order to get to that stage, you must use a copyleft license, which is just opposite of copyright license.
When you are putting your product under a copyleft license, you are actually saying that no one can hold a copyright on it because only I have the copyright.
LGPL, AGPL, GPL – they all fall under the copyleft type licenses. When you’re putting your product under AGPL from day one, people will be contributing for free, there will be bug fixes and patch development. They will be improving your product free of cost. When the product is at this developed stage, you can charge your clients for the finished product.
Author of the article
The article is curated from the speech presented by Sachin Bhakar, Regional Counsel, Hewlett Packard Enterprise, at Open Source India (OSI) 2018. He worked as IP & Open Source Compliance Analyst with Honeywell from 2016 to 2018.
| Q. Initially I had put my source code in the repository through MIT. In the next version, I made some changes and use AGPL. How does it matter If I start with MIT license and then convert to AGPL? Because when you open the Github, by default you see the Apache License and people without much thinking usually go for Apache License.
A. Let’s suppose that your code is of 100 lines, and you have already put those lines in the open source domain. Version Two will be of 120 lines and there will only minor changes. If a company wants to use that particular functionality, they will have now two options – either pay you for AGPL or just to develop 20 lines for MIT version. In such case, they will usually avoid paying to the author at any cost. Therefore, from day one, you should put your code into AGPL because then every copy will be under AGPL and they will not be putting their proprietary code into the public domain. And just to avoid that part they will have to pay you. That’s how you will be able to monetise your software. Q. A free software is developed by an individual and over time many contributors join. At a point when the product is complete and becomes a proprietary, can the contributors claim that they also have a role? A. That’s where contributor license comes in picture. When you have an open source software and you want contributors to contribute to your project, you can put a contributor license agreement and you can modify according to your need. You can say that the moment you contribute to this library, the contribution is not yours, it’s mine and I can license it. That’s how you can take away the rights from the contributors. They can be given the credit, but you can get the right to relicense it. The ownership will lie with the original author. Q. If I add a different functionality and initially put 100 lines of code, and on top of it add more 500 lines of code. Then I put the entire thing under AGPL3, and an alternative license as a commercial license. Will I benefit with that? A. Of course you will benefit from that as you have improved your software and so the earlier portion does not matter. Instead of taking that software from the repository and developing it, the best option would be to take your developed product and get it commercially license from you. So, it entirely depends how much functionality the software is providing. Q. How are the contributors getting benefitted? What is the motivation for them? A. For a developer who are contributing to an open source, it’s their hobby. They are playing with codes, it’s an exercise for them. They are actually improving themselves by contributing to the code. That’s the only take away or advantage they get from contributing. |
