How to use the principles of Open Source to the maximum or MIT vs GPL
Over the past few years, I have worked on a number of open source projects (of which Merb, Ruby On Rails and jQuery stand out the most) and formulated some thoughts about using open source projects and the practical implications of choosing a license.
In essence, there are only two types of licenses that are widely used in OpenSource.
The type I worked with most often is BSD or MIT licenses. These licenses allow unlimited use, modification, distribution and commercialization of the source code, with two reservations. First, a copyright notice must be distributed with the source code. Secondly, if you use my code under the MIT license, you cannot sue me for the consequences of using these source codes.
The other main type of license is called CopyLeft and requires that any changes to the source code be also made public if the modified version is distributed. The practical effect of this license cannot be exercised without the support of the government in copyright law.
The most popular CopyLeft license is the GPL, which is used for Linux and is also viral. In the sense that if you use the code published under the GPL in your own code, then you must also open your code (if you distribute it).
')
The less viral version of the GPL - the LGPL - requires that any changes made to the software are also published, but removes the requirement to publish with simple use.
Because of the uncertainty about the viral characteristics of the GPL, legal departments in large corporations are very hostile to the GPL license. Software licensed under the LGPL is more likely to be approved by corporate lawyers, and MIT / BSD licenses are generally their favorites (apparently because they do not impose any obligations on corporations).
When I work on a serious Open Source project like Ruby on Rails or jQuery, I have relatively simple desires.
Of these desires, numbers two and three have the highest priority. I want to expose the code to as much of the real world as possible. And I want as many high-quality patches as possible to correct the errors found. Although if I had to choose between these two points, I would choose number two: “exposing” my code to the real world is the best way to quickly find errors and incorrect assumptions in the design that I know.
I will begin with the simplest: my first desire (so that my software is used as much as possible) is most easily satisfied by an extremely liberal policy of use. Adding restrictions on the use of software by definition reduces its degree of acceptance.
More importantly, the same can be said about exposing code in the real world. The most important way to achieve this goal is to "make use of the code as convenient as possible for as many people as possible."
If at least 1% of all users of the MIT-licensed code always report an error found, it will be 1% of thousands of potential users, in contrast to 100% of the proprietary users in the case of a CopyLeft-license. In practice, this figure is much more than 1%, since proprietary software users make bug reports just like OpenSource users.
The only counter-argument against this is that, in the case of a CopyLeft license, a number of proprietary users will be forced to become OpenSource users, and their contribution will outweigh the contribution of proprietary users to the MIT license. But in practice, proprietary users choose proprietary solutions when they are forced to choose between OpenSource, with restrictive usage schemes and other proprietary software.
The undoubted advantage of involving proprietary developers in the OpenSource project is that the code is additionally checked in proprietary environments. In addition, they have access to closed usage scenarios, as well as access to OpenSource markets with low penetration.
The next big wish is a constant stream of high-quality patches. It would seem that this should be a strong point of CopyLeft licenses, because all users of the software have to contribute. However, since projects with CopyLeft licenses are not used in a proprietary environment anyway, the patches for Open Source projects from these environments for projects under more liberal licenses are much more numerous. Again, even if only a few percent of proprietary users contribute back to the project, this will mean significantly more contributions than 100% of zero proprietary users.
Of course, I can only talk about jQuery and Rails (and other smaller open source projects I’m working on), but a lot of new long-term participants began to work on the Open Source project while working on corporate projects where the permit angle when choosing software for internal use.
No matter how much you agree with the above arguments, it is clear that CopyLeft licenses intentionally impose a higher barrier on the way to use decisions than more liberal licenses.
For projects that use more liberal licenses, the fact that many proprietary users of their software do not make changes back is a feature, not a bug.
This is because we are not obsessed with all the people who use our program without contributing. Instead, we focus on users, bug reports, patches, and long-term participants, which we will get in perspective by keeping the entry barrier as low as possible.
After all, the world of open source is everywhere around us. And we did it without resorting to coercion or the formation of a completely autonomous set of software. We did this by creating great software and convincing real users that this is better than any alternative.
Linux is an unusual example, since its license does not greatly hinder its use. In particular, this is because most Linux users do not make changes to it, and the limitations of the GPL license rarely come into play.
In cases like this, I would say that the CopyLeft license is pretty close to maximizing usage, which is a major advantage of more liberal licenses. However, it is not clear to me what benefits CopyLeft license can provide even in these (rather rare) cases.
Playing field
In essence, there are only two types of licenses that are widely used in OpenSource.
The type I worked with most often is BSD or MIT licenses. These licenses allow unlimited use, modification, distribution and commercialization of the source code, with two reservations. First, a copyright notice must be distributed with the source code. Secondly, if you use my code under the MIT license, you cannot sue me for the consequences of using these source codes.
The other main type of license is called CopyLeft and requires that any changes to the source code be also made public if the modified version is distributed. The practical effect of this license cannot be exercised without the support of the government in copyright law.
The most popular CopyLeft license is the GPL, which is used for Linux and is also viral. In the sense that if you use the code published under the GPL in your own code, then you must also open your code (if you distribute it).
')
The less viral version of the GPL - the LGPL - requires that any changes made to the software are also published, but removes the requirement to publish with simple use.
Because of the uncertainty about the viral characteristics of the GPL, legal departments in large corporations are very hostile to the GPL license. Software licensed under the LGPL is more likely to be approved by corporate lawyers, and MIT / BSD licenses are generally their favorites (apparently because they do not impose any obligations on corporations).
What do I want when I write Open Source.
When I work on a serious Open Source project like Ruby on Rails or jQuery, I have relatively simple desires.
- I want the software I work on to use as many people as possible. This is probably a selfish desire, but it can be viewed as a desire to see as a result useful software that many really use.
- I want to have a subset of the set of users who will send bug reports, as well as test the performance of the code in a variety of use situations and work environments to improve the quality of the software as a result. In short, it can be formulated as “Have enough eyes for all errors to surface.”
- I want people to be interested in improving the software to submit patches. In particular, I want to get patches from people who have thought about the problem, found the cause of the error and are trying to fix it, and I want to get fewer patches from people who just invented another hack just to get something to work. In essence, a high signal-to-noise ratio for patches is more important than a large number of patches.
- I want people to be interested in improving the software for the long term. That the project received long-term participants (contributors) and finally developers (committers).
Of these desires, numbers two and three have the highest priority. I want to expose the code to as much of the real world as possible. And I want as many high-quality patches as possible to correct the errors found. Although if I had to choose between these two points, I would choose number two: “exposing” my code to the real world is the best way to quickly find errors and incorrect assumptions in the design that I know.
Meeting these requirements
I will begin with the simplest: my first desire (so that my software is used as much as possible) is most easily satisfied by an extremely liberal policy of use. Adding restrictions on the use of software by definition reduces its degree of acceptance.
More importantly, the same can be said about exposing code in the real world. The most important way to achieve this goal is to "make use of the code as convenient as possible for as many people as possible."
If at least 1% of all users of the MIT-licensed code always report an error found, it will be 1% of thousands of potential users, in contrast to 100% of the proprietary users in the case of a CopyLeft-license. In practice, this figure is much more than 1%, since proprietary software users make bug reports just like OpenSource users.
The only counter-argument against this is that, in the case of a CopyLeft license, a number of proprietary users will be forced to become OpenSource users, and their contribution will outweigh the contribution of proprietary users to the MIT license. But in practice, proprietary users choose proprietary solutions when they are forced to choose between OpenSource, with restrictive usage schemes and other proprietary software.
The undoubted advantage of involving proprietary developers in the OpenSource project is that the code is additionally checked in proprietary environments. In addition, they have access to closed usage scenarios, as well as access to OpenSource markets with low penetration.
The next big wish is a constant stream of high-quality patches. It would seem that this should be a strong point of CopyLeft licenses, because all users of the software have to contribute. However, since projects with CopyLeft licenses are not used in a proprietary environment anyway, the patches for Open Source projects from these environments for projects under more liberal licenses are much more numerous. Again, even if only a few percent of proprietary users contribute back to the project, this will mean significantly more contributions than 100% of zero proprietary users.
Of course, I can only talk about jQuery and Rails (and other smaller open source projects I’m working on), but a lot of new long-term participants began to work on the Open Source project while working on corporate projects where the permit angle when choosing software for internal use.
Low entry barrier helps meet open source goals
No matter how much you agree with the above arguments, it is clear that CopyLeft licenses intentionally impose a higher barrier on the way to use decisions than more liberal licenses.
For projects that use more liberal licenses, the fact that many proprietary users of their software do not make changes back is a feature, not a bug.
This is because we are not obsessed with all the people who use our program without contributing. Instead, we focus on users, bug reports, patches, and long-term participants, which we will get in perspective by keeping the entry barrier as low as possible.
After all, the world of open source is everywhere around us. And we did it without resorting to coercion or the formation of a completely autonomous set of software. We did this by creating great software and convincing real users that this is better than any alternative.
Postscript: Linux
Linux is an unusual example, since its license does not greatly hinder its use. In particular, this is because most Linux users do not make changes to it, and the limitations of the GPL license rarely come into play.
In cases like this, I would say that the CopyLeft license is pretty close to maximizing usage, which is a major advantage of more liberal licenses. However, it is not clear to me what benefits CopyLeft license can provide even in these (rather rare) cases.
Source: https://habr.com/ru/post/80257/
All Articles