The post has been translated automatically. Original language: Russian
Permissive licenses like MIT allow you to take open source code, modify it, and use it further, even in a closed product.
The GPL, LGPL and AGPL are arranged differently.
Their general principle:
if you distribute a modified version of the program, in certain cases you must also open the source code of these changes.
This approach is called copyleft — the requirement to preserve the freedom of the code in the derived versions.
GPL
The GPL allows:
- use the program;
- Study it;
- change;
- distribute your own versions;
- apply it in commercial projects.
However, if you distribute a derivative program, you usually have to provide its source code under the terms of the GPL.
In other words, you can't just take a GPL project, significantly change it, close the source code, and sell it as a completely closed product.
LGPL
LGPL is softer.
It was created primarily for libraries.
A closed program can use the library under the LGPL without automatically becoming fully open.
However, changes to the library itself should usually remain available under the terms of the LGPL.
This is a compromise between the free distribution of the library and the ability to use it in commercial closed programs.
AGPL
The GPL has a feature.
If a company has changed a program, but does not distribute it, but simply runs it on its server, the obligation to open the changes usually does not arise.
The AGPL closes this gap.
If the modified program is used over the network, users should be given the opportunity to obtain the source code of this version.
Therefore, AGPL is especially interesting for server programs and Internet services.
Why would the author need such a license?
The main advantage is that it is more difficult to pick up changes from an open project and turn them into a completely closed branch.
The company can use the code and earn money from it.
However, in situations stipulated by the license, it must maintain the availability of the source code.
This creates a kind of exchange.:
you get an open source code and keep your changes open.
But there is also a drawback.
Such requirements are too strict for some companies.
Lawyers for large organizations may prohibit the use of the GPL or AGPL in certain products altogether, so that there is no accidental obligation to disclose the source code.
Therefore, such a license can reduce the number of potential users.
It turns out to be a simple choice.
If the main thing is maximum distribution, MIT, BSD or Apache 2.0 are more often chosen.
If the main thing is to keep the derivative versions open, look towards the GPL and AGPL.
And the next question is even more interesting.:
is it possible to keep the project open, but still maintain control over the official version of the product?
About this — in the next article.
Разрешительные лицензии вроде MIT позволяют взять открытый код, изменить его и использовать дальше даже в закрытом продукте.
GPL, LGPL и AGPL устроены иначе.
Их общий принцип:
если вы распространяете изменённую версию программы, в определённых случаях вы должны открыть и исходный код этих изменений.
Такой подход называют copyleft — требованием сохранять свободу кода и в производных версиях.
GPL
GPL позволяет:
- использовать программу;
- изучать её;
- изменять;
- распространять свои версии;
- применять её в коммерческих проектах.
Но если вы распространяете производную программу, обычно должны предоставить её исходный код на условиях GPL.
То есть нельзя просто взять GPL-проект, существенно изменить его, закрыть исходники и продавать как полностью закрытый продукт.
LGPL
LGPL мягче.
Она создавалась прежде всего для библиотек.
Закрытая программа может использовать библиотеку под LGPL, не становясь автоматически открытой целиком.
Но изменения самой библиотеки обычно должны оставаться доступными на условиях LGPL.
Это компромисс между свободным распространением библиотеки и возможностью применять её в коммерческих закрытых программах.
AGPL
У GPL есть особенность.
Если компания изменила программу, но не распространяет её, а просто запускает на своём сервере, обязанность открыть изменения обычно не возникает.
AGPL закрывает этот пробел.
Если изменённой программой пользуются через сеть, пользователям должна быть предоставлена возможность получить исходный код этой версии.
Поэтому AGPL особенно интересна для серверных программ и интернет-сервисов.
Зачем автору такая лицензия
Главное преимущество — изменения сложнее забрать из открытого проекта и превратить в полностью закрытую ветку.
Компания может пользоваться кодом и зарабатывать на нём.
Но в ситуациях, предусмотренных лицензией, она должна сохранить доступность исходного кода.
Так возникает своеобразный обмен:
вы получаете открытый код — и сохраняете открытыми свои изменения.
Но есть и недостаток
Для некоторых компаний такие требования слишком жёсткие.
Юристы крупных организаций могут вообще запретить использование GPL или AGPL в определённых продуктах, чтобы случайно не возникла обязанность раскрывать исходный код.
Поэтому такая лицензия может уменьшить число потенциальных пользователей.
Получается простой выбор.
Если главное — максимальное распространение, чаще выбирают MIT, BSD или Apache 2.0.
Если главное — сохранение открытости производных версий, смотрят в сторону GPL и AGPL.
А следующий вопрос ещё интереснее:
можно ли оставить проект открытым, но при этом сохранить контроль над официальной версией продукта?
Об этом — в следующем материале.
Share
