-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider changing the platform license #2080
Comments
If protecting our business means that no-one can use our code and make money of it themselves, there is only one option here as far as I understand: https://tldrlegal.com/license/gnu-affero-general-public-license-v3-(agpl-3.0) |
Not excatly knowing everyone's skills and knowledge about licenses and implications of selecting one, I'm raising a question do we have enough talent to understand the consequences? |
In addition I've heard about cases in which APIs related code is licensed differently than core components. So, the question is are we selecting one license? Business wise we also need to consider not only to protect open source values, but opportunities to integrate our platform components to other systems. Do we want to hang ourselves to strict and ideological open source stuff or create new business opportunities? |
Hi Guys Chandra invited me to participate in this discussion. I have pretty limited knowledge on APIinf.io, but have quite a bit of experience in dealing with licensing and business model questions. So you could take what I write below as general notes to consider. But anyhow I'll try to make my comments more specific to APIinf.io. Choosing a license is most often a too limited question. The wider, real question is how the venture will make money (or finance itself); and in a startup/company setting what is its competitive advantage (CA). The crux here is the CA: what is your CA and how will you grow and nurture it to become stronger. The choice of licence is then made possible, when you know the above. In a startup, or strongly changing company, one needs to look 1-3 years to the future to meaningfully make judgements on the CA. So how does the world look for APIinf.io in 1-3 years? Based on some of my earlier discussions with Chandra, APIinf.io looks to grow its user base and ecosystem by maintaining a FOSS project with MIT license, and offering API management services. The medium term goal is to gain insight into API usage (including data), and learn and develop artificial intelligence (AI) and related algorithms. And, if brand is not mentioned, it should mostly be added to these medium term goals. So in three years APIinf.io could maintain an opensource project, and a service platform based on that. Sellable items would include the API management service and value added services based on data and AI. Data and AI here are not accessible to others, except as granted by APIinf.io, normally against payment. So the data and AI would the CA of APIinf.io. This would be complemented with support services and consultancy services. Adding the brand element here: APIinf.io could host n store, where third parties could sell services and sw pieces working on top of the API management service; and APIinf.io would charge a comission on such sales. This puts the brand also in the CA. While growing there, you will run the risk of being forked. How to avoid that? FOSS projects avoid forking by two ways: by choosing a difficult license or by having a very strong project (growing, wide, also complex, in time brand too) that makes forking unenticing. Quite often projects which started with AGPL or GPL move, when the projects are establised, towards more permissive licenses, e.g. LGPL or MIT. Also, forking is not necessarily bad. As long as you keep your CA and brand, and assuming your CA is real, you should be able to maintain the best business in the field. Forking could, at best, standardize the market around your solutions, exposing more custmers to your CA. At worst, it will fragment the market, create a low-end version of your product (always assuming your CA is real), and decrease the (low-end) user base available to you. This type of decisions should not be based on fear or gut. If you choose the bolder option (MIT), you need to keep an enthusiastic, lively and growing project (and well funded) and communicate this to the community. However, it would be good to find and follow signals regarding forking risks. A more risk-averse scenario would choose AGPL, in which case it is impossible to measure, whether your MIT-project is susceptible to forking or not. In the end it comes down to the CA: if it is real (and not the code), the faster growth path with MIT is better. Regarding investor thoughts: mostly (VC type) investors want to see a scalable business model and they want to pursue a high-reward-high-risk scenario. In the above, data and AI based services, as well as brand based store sales, as well as support/platform services are scalable. The scalability of the support/platform service is limited in some sense by the MIT license. But the CA is outside of the code, so the code could be MIT to support the growth of the user base. Payable users is a subset of all users. Forking of the code is good in the sense if it grows the user base, and you maintain your CA and brand (=new users of the fork are potential payable users to you). Very shortly: identify your CA. CA is no longer in the code, but elsewhere in the value chain. Maximise distribution of what can be distributed with zero/low cost, and thus generate maximum demand for your CA, which is not susceptible to copying. |
Thanks @willebra for thorough and insightful comment! |
Don't have much experience in license choosing, especially in a long term view. |
A little statistics from BlackDuck if that seems interesting https://www.blackducksoftware.com/top-open-source-licenses. Put your focus on license number 17. ;) |
@willebra Thanks for taking the effort and providing us with your insights on the license and on the competitive advantage! |
What's the process to close this issue? |
Good point. |
The purpose of the issue was to collect feedback and comments from our team about the license. Unfortunately, I did not give a deadline to comment this issue, so I'm giving it now. If there any more comments from our team, they should be given by Friday 17 Feb. After that I will close the issue. Any discussion about USP could be either a separate issue or maybe a continuation of the customer journey workshops. |
First of all, thanks to all for taking time to comment on this post. This licensing discussion has been initiated by me in the team so I will also put my perspective here. I have 2 point of view about this issues, first is about Adaptation & Branding and second is what APInf stands for and its responsibility towards community.
APInf board will consider all the inputs and make a decision about this in a month. I request @bajiat to close this issue and If anyone has any inputs after that, you are free to open this issue and add your inputs. |
MIT popularityThe MIT license is popular for many projects, including the profusion of "component libraries aimed to enter in larger works" (source) emerging in language ecosystems such as JavaScript, Python, etc. These small-scale libraries probably skew the distribution of 'license popularity', since small libraries are much more common than more end-to-end applications. Commercial useIt is worth clarifying that any open source/free software license would allow people to use Apinf to make money:
Free/open source license typesThere are two types of free/open source licenses, generally speaking:
The MIT license (tldr, line-by-line analysis) falls into the 'permissive' category, since its main language is to relinquish copyright restrictions and liability of the original author(s). ApinfSince Apinf has reached a scale not typical of libraries, general purpose databases, etc., it is worth considering an open source license with broad terms. In effect, we are building a large software suite, by combining many tools together in a more-or-less cohesive manner. It is also noteworthy that our project is designed to run on a server environment and be accessed over a network. Based on the above considerations, this discussion thread, and in-person discussions, I recommend we first determine whether our community and business would be better supported by a permissive/promiscuous or strong/Copyleft license. Once we reach a decision, I recommend we choose from the following candidate licenses:
RationaleApacheThe Apache license (tldr) is maintained by the Apache Software Foundation (ASF). It is permissive, while including important language about software patents. The Apache License is commonly used among ASF and Cloud Native Computing Foundation projects. EUPLThe European Union Public License (tldr) is created on the initiative of the European Commission. It is approved by the European Commission in 22 official languages of the European Union, having been translated by native legal experts. EUPL 1.1 contains language inclusive of software designed to run on a network, so pertains directly to Apinf. |
Good point there Brylie. This is just "feelings". It might be different for other devs. Just wanted to point out that "understanding the license and my obligations to it" is easier when using permissive licenses. |
Thanks for participating in the discussion! Closing the issue. Final decision will be made by the board, but the points given in the discussion will help in making the decision. |
|
We should consider changing our license in order to
The current APInf license is MIT.
Some of the potential options (not in any order of preference)
The text was updated successfully, but these errors were encountered: