Комментарии 23
После прочтения статьи понял, что: - "Копилефтные лицензии это плохо". Но остался вопрос, плохо для кого? Для того у кого заимствуют или для того, кто заимствует )
Выложить в открытый доступ исходный код программы или информацию, где его можно получить.
По-моему, это наиболее часто встречающаяся ошибка в трактовке положений GPL (как минимум в рунете). Исходный код совершенно не обязан находиться "в открытом доступе", об этом в положениях лицензии нет ничего - разработчик обязан предоставить код или способ получения доступа к нему только легальным пользователям ПО вместе с бинарниками.
Причина — если конкурент сделает ревизию кода и найдет копилефтную часть, то придется раскрыть код и сделать ПО общедоступным.
Тоже нет. Сам конкурент может приобрести копию ПО и сделать ее общедоступной, это да. Но разработчика к этому ничто в лицензии не обязывает, он имеет полное право продавать копии ровно так же, как продавал раньше.
Не подойдут для коммерческих целей большиство копилефтных лицензий — по их условиям нужно распространять модифицированное ПО. Важно, чтобы ваши наработки были открытые и бесплатные для других пользователей.
Вас на фоне этого абзаца не смущает, что на Западе достаточно успешные софтверные компании строят свой бизнес именно на продаже и поддержке ПО с GPL-лицензиями?
Все верно, основная идея заключается именно в обеспечит возможности получить исходный код, но как это обеспечивается вопрос вне лицензии, но в тексте как раз написано, что необходимо оставить информацию как получить исходник.
Все верно написали, но как раз таки получение кода конкурентом может привезти к потере преимущества вашего ПО на рынке. А если заставят сделать общедоступным, то тогда такое ПО никто не будет покупать.
Есть такие бизнесы на западе, но основные бенефиты они получают не от продажи экземпляров, а от технической поддержки и доработки такого ПО для заказчика (red hat например)
Уважаемый автор, а не могли бы вы прояснить ситуацию с использованием "опасных" лицензий при разработке внутрикорпоративного софта?
Поэтому еще их называют вирусными.
Не все копилефт лицензии являются вирусными, MPL, CDDL, EPL, etc не "заразят" ваш продукт. Вирусными называют прежде всего семейство GPL
Eclipse Public License v.1 — единственная лицензия, которая прямо разрешает коммерческое использование в определенных случаях
Все FOSS лицензии разрешают коммерческое использование в любом случае. Коммерческое использование =/= закрытый код
Не подойдут для коммерческих целей большиство копилефтных лицензий
Автор имеет право продавать копилефтные произведения. Многие писатели, фотографы, художники, скульпторы выпускают свои произведения по копилефтным лицензиям в одном месте, одновременно продавая их в другом месте.
А можно подробнее про AGPL? Есть просто непонимание как она в действительности работает если используется ПО "as is" (развернут инстанс).
Например: есть объектное хранилище minio. Оно распространяется по лицензиям AGPL и коммерческой. Согласно написаного на их сайте, если инстанс является составной частью продукта (возьмем, например, самописный блог: фото и видео с его мы зачем-то будем хранить в minio) и не используется коммерческая лицензия -- весь продукт должен быть опубликован под лицензией AGPL. Я правильно трактовал их требования, или нет?
By contrast, pipes, sockets, RESTful APIs, and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Грубо говоря, пока в приложении нет прям глубокой интеграции, minio и блог будут рассматриваться как два отдельных приложения
As is тут не причем, это никак не влияет на последствия лицензии. Основная идея AGPL в распространении ее условий на продукты, который распространяются по SaaS, то есть это тот же GPL.
В вашем случае конечный результат использования этого компонента в вашем ПО приведет к всему его "заражению" AGPL.
У меня вот такая шпаргалка с прошлой работы завалялась, может вдруг пригодится кому:
И MPL — это вроде "Mozilla Public License", a Microsoft Public License — это Ms-PL или MS-PL.
Уровень анализа, на первый взгляд, не очень. Сразу бросаются в глаза 2 самые распространенные ошибки - путаница free beer / free software и производная-непроизводная работа / статическая-динамическая линковка.
Вы не могли бы пояснить про разницув лицензиях для случаев, если используется исходник и я его модифицирую и когда я использую уже скомпилированную библиотеку, когда даже не нужно знать на каком языке написан код
про модификации: это будет производное произведение и его судьба зависит от лицензии, по которой распространялся исходник
библиотеки обычно распространяются по "хорошим" лицензиям либо по AGPL. Если последняя, то присоединять библиотеку вы можете динамическим линкованием, чтобы не "заразить" основной код, к которому цепляется библиотека.
Вопрос насчет заимствования части кода.
Если при написании кода использовались LLM-инструменты (что-то вроде ChatGPT, Copilot), которые в результат генерации вставили часть чужого кода без соблюдения авторских прав.
Или другой вариант. Недобросовестный разработчик позаимствовал часть кода, а потом заявляет, что это он написал, используя ChatGPT.
Так как вопрос авторства результатов работы LLM сформулирован размыто. То как это все согласуется с лицензированием. Уже есть какая-нибудь практика?
Или может быть на практике вопрос лицензирования кода актуален только при явном включении библиотек целиком, а часть кода реально никого не волнует?
Как безопасно использовать открытый код и не лишиться прав на ПО