Closed bajiat closed 7 years ago
philippeluickx
commented
7 years ago 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)
kyyberi
commented
7 years ago 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?
kyyberi
commented
7 years ago 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?
willebra
commented
7 years ago 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.
The problem with choosing AGPL (or GPL, depending on the typical deployment scenario of the sw) is that is slows the growth of users, and may alienate some existing users. So you want to build a large ecosystem, with alot of users (=potential customers), potential ecosystem partners (sellers on your store). If you choose AGPL, your growth speed is going to be hurt, and your maximum user base will be smaller.
If you choose MIT license, you can expect the fastest growth in user base, but at the same time you will risk forking. There have been historical, well-known forks (MySQL -> MariaDB; OpenOffice -> LibreOffice), all of them have been result of long-lasting controversy: in a way expected forks. I would be interested to hear from early stage forks. My gut feeling is that mostly people are afraid of forks (and choose AGPL), but it’s not based on concrete indications on forks. Forking is in practice not that easy. In order to get a credible fork, you need to have a team (development, community, leadership) and the team needs to be funded; and VC’s aren’t enthusiastic to fund something that already has an established competitor. (If you were disrupting someone strategially, that would be different, but APIinf.io seems to me to sail towards the blue ocean, emerging markets.) My gut feeling would be that a startup in an emerging market, having funding and a team, can actually withstand forks quite well.
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.
kyyberi
commented
7 years ago Thanks @willebra for thorough and insightful comment!
55
commented
7 years ago Don't have much experience in license choosing, especially in a long term view. Here is a blog post about open source license usage on GitHub.com that perhaps may help us to make a decision.
kyyberi
commented
7 years ago A little statistics from BlackDuck if that seems interesting https://www.blackducksoftware.com/top-open-source-licenses. Put your focus on license number 17. ;)
bajiat
commented
7 years ago @willebra Thanks for taking the effort and providing us with your insights on the license and on the competitive advantage!
kyyberi
commented
7 years ago What's the process to close this issue?
philippeluickx
commented
7 years ago Good point. Considering the points here, we should decide on what our USP would be. Data is always a good USP...
bajiat
commented
7 years ago 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.
ccsr
commented
7 years ago 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.
Adaptation & branding Our mission at APInf is to make everyone aware of the importance of API Management and increase the adaptation by every developer and every organization who are involved with APIs. We have been making all the efforts possible to remove any barriers which would create hurdles to achieve our mission. We believe strongly in being open and transparent about all we do. This is also one reason why we opened our process for everyone. We are encouraged to we see results for our efforts. It also helped us to reach out to all kinds of audiences and listen to them or sometime involve them. We are also very glad that we have a global and vibrant community now. Of course, there is always possibilities to improve.
Responsibility APInf is built on the strong fundamentals of open source and open process. We have been contributing upstream for all the components we use in APInf platform, whenever we did some additions or changes. With a good faith, we hope that everyone who is forking or using APInf also make the contributions to APInf's upstream so, that community and team can benefit and learn from it. The current license (MIT) does not guarantee this. We have a responsibility towards our community and specially towards our contributors to bring them acknowledgement for their contributions and also ensure that they benefit also from others making their contribution. We would like to avoid the situation where our contributors feel that they are not acknowledged and this is something we want to consider seriously. Of course, we totally acknowledge that some customers of APInf would not like to share their contributions due to business reasons and policies. We are totally ok with it and we will support them and our company surely understand it.
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.
brylie
commented
7 years ago The 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.
It is worth clarifying that any open source/free software license would allow people to use Apinf to make money:
The freedom to run the program as you wish, for any purpose (freedom 0) Free Software Definition
No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it. Open Source Definition
There 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).
Since 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:
The 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.
The 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.
philippeluickx
commented
7 years ago Good point there Brylie. Personally when I see "strong" copyleft licenses, it scares me. Does it mean that when I use this code, I need to open source everything else I work on? Am I still doing legal coding, what are my restrictions? With the more permissive licenses, there are less questions.
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.
bajiat
commented
7 years ago 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.
kyyberi
commented
7 years ago
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)