Бесплатный код, который может дорого обойтись

Установить библиотеку через npm занимает пару минут. Проверить, на каких условиях её вообще можно использовать в коммерческом продукте, обычно вспоминают сильно позже.

Open source не означает, что код можно брать без ограничений. У программы есть правообладатель, а возможность использовать её даёт лицензия. В российском праве программы для ЭВМ охраняются авторским правом (ст. 1259, 1261 ГК РФ), а открытые лицензии прямо предусмотрены ст. 1286.1 ГК РФ.

То есть вопрос не в том, можно ли использовать открытый код в коммерческом продукте. В большинстве случаев можно. Вопрос в том, что конкретно разрешает лицензия и что она требует взамен.

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

Но популярное утверждение «нашли GPL-библиотеку — придётся открыть весь продукт» тоже неверно. Нужно смотреть, как именно используется компонент, модифицировался ли он, как взаимодействует с остальным ПО и распространяется ли результат третьим лицам.

С MIT, BSD, Apache 2.0 обычно проще, но «проще» тоже не значит «никаких условий». У лицензий остаются требования к сохранению copyright notices, текста лицензии и других уведомлений. У Apache 2.0, например, отдельно урегулированы вопросы патентных прав.

Почему мы вообще обращаем на это внимание клиентов?

Потому что проблема с open source часто обнаруживается не разработчиком и не юристом компании. Её находит крупный заказчик при проверке продукта, инвестор на due diligence или покупатель бизнеса, когда начинает разбирать цепочку прав на ПО.

И тогда библиотека, которую несколько лет назад кто-то добавил одной командой, превращается в вопрос: а компания вообще вправе распространять продукт так, как распространяет его сейчас?

Если использование выходит за пределы лицензии, это уже вопрос нарушения исключительного права. Правообладатель может требовать прекращения нарушения, а также возмещения убытков или выплаты компенсации. Для программ для ЭВМ соответствующие способы защиты предусмотрены в том числе ст. 1252 и 1301 ГК РФ.

Поэтому мы обычно предлагаем начинать не с огромной opensource-политики на двадцать страниц, а с простой ревизии:

• —какие сторонние компоненты фактически есть в продукте
• —на каких лицензиях они используются
• —есть ли среди них лицензии, которые конфликтуют с текущей моделью распространения ПО
• —кто и по каким правилам может добавлять новые зависимости

После этого уже понятно, нужна компании отдельная opensource-политика или достаточно нескольких правил для команды разработки.