Подножка для GPL

Материал подготовлен на основе публикации Telegram-канала IT PATENT от 11.04.2025.

Подножка для GPL

Заветное слово из трёх букв — GPL — в списке используемых компонентов может вызвать отрицание, торг и тяжёлое «пу-пу-пу»❕ у любого юриста, которому поставили задачу обеспечить лицензионную чистоту программного продукта.

Всегда ли это так страшно?

Обычно GPL вызывает негодование из-за того, что она «вирусная», требует раскрытия исходного кода всего программного продукта и имеет проблемы совместимости с другими лицензиями – например, GPLv2 и Apache 2.0; да даже внутри семейства GPL лицензии могут быть несовместимы в рамках одного проекта!

На этом этапе часто начинается торг с программистами 🥺о замене компонента на другой, с более дружелюбной лицензией. Не всегда это возможно, но иногда можно применить хитрости или использовать GPL против самой себя.

Предположим, что у нас есть SaaS, в который попал компонент GPL (v2, v3). Должны ли мы что-то с этим делать? Не всегда. Мы вполне легально можем его оставить (если нас беспокоит только требование раскрытия исходного кода), если ПО не распространяется конечному пользователю в формате on-prem, box, так как условие предоставления исходного кода продукта связано с распространением, а не с предоставлением доступа пользователя к продукту (это так называемый SaaS Loophole).

Другим вариантом обхода требований является манипулирование понятиями «производное произведение» и «агрегация». По умолчанию в GPL считается, что любое использование компонентов создаёт производное произведение, за исключением случаев, когда можно считать, что наше ПО не зависит от данного компонента. Например, это возможно, если взаимодействие с GPL-компонентом происходит через внешний API, сделав обертку вокруг мешающего GPL-компонента.

Коллеги, делаете лицензионные ландшафты для ПО? Какими средствами автоматизации пользуетесь?

#FOSS #OpenSource #GPL