Ключевые риски, связанные с использованием свободных лицензий

Ключевые риски, связанные с использованием свободных лицензий.

Указанные риски можно разделить на две большие группы:

• Риски, связанные с использованием свободного программного обеспечения в деятельности компании;
• Риски, связанные с использованием свободного программного обеспечения при разработке собственных программных продуктов.

Риски, связанные с использованием свободного программного обеспечения в деятельности компании

Как ни странно, гражданско-правовой точки зрения особых рисков в данном случае нет. Все виды свободных лицензий предоставляют пользователю свободного ПО неограниченную свободу использования программы (ограничение появляется при ее модификации, но это обычно выходит за рамки обычного использования программы в офисе).

Однако, в свое время существовали определенные риски публично-правового характера. В начале 2000-х, когда свободное ПО только начали устанавливать в организациях, Интернет-форумы были затоплены разного рода «страшилками» на тему того, как однажды оперативники Управления К или другие сотрудники правоохранительных органов пришли в гости и, не найдя заветной наклейки на системном блоке, обвиняли в пиратстве и опечатывали компьютеры.

С тех пор имело место немало обсуждений по этому поводу, однако в настоящее время их можно считать во многом устаревшими. Причин тому несколько. Во-первых, прошло достаточно времени, open source и свободное ПО перестало восприниматься как что-то маргинальное. Термин «свободное ПО» стали широко использовать в различных правовых актах. Во-вторых, появилось официальное разъяснение Министерства экономического развития РФ, которое «благословило» использование свободных лицензий и GPL в частности. Речь идет о письме Министерства экономического развития РФ от 5 мая 2009 г. N Д05-2235 “Об использовании свободного программного обеспечения”, в котором было прямо сказано, что «использование свободного программного обеспечения не может быть основанием для применения санкций и препятствий в осуществлении предпринимательской деятельности при контроле за соблюдением авторских прав».

Однако, при наличии подозрений на “заказ” со стороны конкурентов или других заинтересованных лиц, целесообразно подготовиться, и кроме распечатки указанного письма озаботиться распечаткой и нотариальным удостоверением перевода текста лицензионных соглашений на свободное ПО, которое используется в организации (операционные системы, офисные пакеты и т.п.). Печать нотариуса с гербом обычно оказывает успокаивающее действие на правоохранительные органы.

В том случае, когда свободное ПО покупалось в виде коробочных версий (а не скачивалось в сети Интернет), сопутствующая «бумажная» документация (накладные, счета-фактуры, договоры) также способна иметь большое «легализующее» значение.

Риски, связанные с использованием свободного программного обеспечения при разработке собственных программных продуктов

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

Основная проблема заключается в том, что при наличии около 70 свободных лицензий, многие из них несовместимы между собой. Другими словами, сочетание фрагментов кода, распространяемого на условиях лицензий GPL, BSD, MPL и Apache, может оказаться юридически невозможным. Сам факт использования GPL-кода потребует применения к итоговой программе лицензии GPL, в то время как это будет противоречить лицензии MPL, будет требовать применения MPL к изменившимся файлам. В условиях, когда какой-нибудь фрагмент кода программы используется с нарушением условий его лицензирования, весь результирующий программный продукт приобретает сомнительный правовой статус. Это может иметь значение при дальнейшей коммерциализации программы, особенно, если она будет осуществляться с привлечением зарубежных партнеров, которые традиционно уделяют большое внимание юридической чистоте продукта. Но еще большее значение это будет иметь в тех случаях, когда крупная иностранная компания заинтересуется разработчиком программы и захочет его приобрести. Сопутствующий M & A процесс due diligence включает в себя анализ исходного кода программы, в том числе с привлечением специализированных организаций (например, компании Black Duck и ей подобных, которые могут просканировать код и определить его происхождение). Наличие нарушений лицензионного соглашения при разработке программы может послужить основанием для существенного снижения цены или даже отказа от сделки. Так что разного рода стартапам, которые рассчитывают на интерес со стороны крупных игроков рынка IT, следует особое внимание уделить качеству кода своих программных продуктов.

Разумеется, существует и формальный риск предъявления претензий со стороны правообладателя (автора GPL-программы) или его уполномоченного представителя (для лицензий GPL – это FSF). Существует ряд судебных споров (пока только зарубежных), которые обычно заканчивались капитуляцией нарушителя. См. подробнее: http://gpl-violations.org. Даже если в результате и не будет присуждена значительная компенсация, ущерб репутации в сообществе open source будет весьма значительным.

Основным средством минимизации рисков в данной ситуации является знание того, из каких компонентов состоит программный продукт и на каких условиях они могут быть использованы.

Для достижения указанной цели целесообразно внедрение в компании политики использования open source. В частности, обязанность программистов фиксировать происхождения кода, а также загружать вместе с ним те лицензии, которые его сопровождают. Она также может содержать перечни лицензий, которые можно использовать без согласования с юристами (как правило, это все либеральные лицензии) и лицензий, которые требуют такого согласования.

В некоторых случаях целесообразно проведение анализа (сканирование) программного кода с помощью автоматизированных средств (в т.ч. с привлечением специализированных компаний, например Black Duck Software Inc.; Palamida, Inc.).

В любом случае, руководство компании должно донести до сведения сотрудников простую истину (и обеспечить понимание): выбор и использование сотрудниками программного кода является не только их личным делом, а непосредственно влияет на качество результата с точки зрения его юридической оборотоспособности. Следовательно, участие юриста в данном процессе должно рассматриваться не как досадная помеха, а как одно из условий обеспечения дальнейшего коммерческого успеха того, что разрабатывается.