The post has been translated automatically. Original language: Russian
Many people believe that if the source code is in an open repository, then the project is already Open Source.
This is not entirely true.
Open source code only means that it can be viewed. Open Source is also a set of rights that the author gives to other developers.
Usually, the license determines whether it is possible:
- use the program;
- change the code;
- distribute copies;
- include the code in other products;
- sell products based on it;
- publish your own changes.
It is the license that determines what other people can do with the code.
Why is this important?
Imagine that a company publishes the entire source code of its product on GitHub, but writes:
The code can be studied, but it cannot be used in commercial projects.
The source code is open to read, but it is no longer Open Source in the classical sense.
This approach is usually called Source Available — the source code is available, but the rights to use it are limited.
This is a normal model. The main thing is not to confuse it with Open Source.
Why open the code at all
Open source has several strengths.
First, users can check how the program works.
Secondly, other developers can find bugs and suggest improvements.
Third, open source reduces the user's dependence on a single vendor.
For a technology company, it's also a way to spread new technology faster. A developer can study the product, try it out and understand the architecture without lengthy negotiations with the supplier.
But there is a downside.
The more rights you give users, the less control you retain over the further use of the code.
Therefore, choosing a license is not a formality.
It's part of the business model.
Licenses are very different
For example, MIT and Apache allow you to use the code quite freely, including inside commercial products.
The GPL allows the use and modification of the code, but requires the discovery of derivative works under certain conditions.
AGPL goes even further and takes into account the situation when the modified program is used as a network service.
Each model has its own philosophy and its own business implications.
The main thing
Before publishing the source code, it's not worth answering the question:
"Do we want to open the code?"
And for a more precise question:
"What rights do we want to give other people?"
Almost anything can be resolved.
You can request to publish the changes.
You can open the code just for studying.
You can leave the project itself open, but control the official builds, name, and support.
That is why the choice of a license should be made even before the project begins to actively spread.
In the following materials, we will analyze the main types of licenses and see how MIT, Apache, GPL and AGPL differ in practice.
Многие считают: если исходный код лежит в открытом репозитории, значит проект уже Open Source.
Это не совсем так.
Открытый исходный код означает только то, что его можно посмотреть. Open Source — это ещё и набор прав, которые автор даёт другим разработчикам.
Обычно лицензия определяет, можно ли:
- использовать программу;
- изменять код;
- распространять копии;
- включать код в другие продукты;
- продавать продукты на его основе;
- публиковать собственные изменения.
Именно лицензия определяет, что другие люди могут делать с кодом.
Почему это важно
Представим, что компания публикует весь исходный код своего продукта на GitHub, но пишет:
Код можно изучать, но нельзя использовать в коммерческих проектах.
Исходный код открыт для чтения, но это уже не Open Source в классическом смысле.
Такой подход обычно называют Source Available — исходный код доступен, но права на его использование ограничены.
Это нормальная модель. Главное — не путать её с Open Source.
Зачем вообще открывать код
У открытого кода есть несколько сильных сторон.
Во-первых, пользователи могут проверить, как работает программа.
Во-вторых, другие разработчики могут находить ошибки и предлагать улучшения.
В-третьих, открытый код снижает зависимость пользователя от одного поставщика.
Для технологической компании это ещё и способ быстрее распространять новую технологию. Разработчик может изучить продукт, попробовать его и понять архитектуру без долгих переговоров с поставщиком.
Но есть и обратная сторона.
Чем больше прав вы даёте пользователям, тем меньше контроля сохраняете над дальнейшим использованием кода.
Поэтому выбор лицензии — это не формальность.
Это часть бизнес-модели.
Лицензии бывают очень разными
Например, MIT и Apache позволяют довольно свободно использовать код, в том числе внутри коммерческих продуктов.
GPL разрешает использование и изменение кода, но требует при определённых условиях открывать производные работы.
AGPL идёт ещё дальше и учитывает ситуацию, когда изменённая программа используется как сетевой сервис.
У каждой модели своя философия и свои последствия для бизнеса.
Главное
Перед публикацией исходного кода стоит ответить не на вопрос:
«Хотим ли мы открыть код?»
А на более точный вопрос:
«Какие права мы хотим дать другим людям?»
Можно разрешить практически всё.
Можно потребовать публиковать изменения.
Можно открыть код только для изучения.
Можно оставить открытым сам проект, но контролировать официальные сборки, название и поддержку.
Именно поэтому выбор лицензии стоит делать ещё до того, как проект начинает активно распространяться.
В следующих материалах разберём основные виды лицензий и посмотрим, чем MIT, Apache, GPL и AGPL отличаются на практике.
Share
