Open Source с юридической точки зрения: особенности использования

Согласно данным Обзора будущего Open Source 2015 (The 2015 Future of Open Source Survey), подготовленного компанией Black Duck Software, 3 из 4 компаний в Америке ведут свою деятельность с использованием свободного или открытого программного обеспечения, и только 3% компаний боятся использовать такой код при разработке собственного софта. Такие данные показывают, что использование свободного или открытого кода при разработке нового софта является приемлемым и распространенным явлением. Это хороший способ экономии, так как создание собственных решений потребует больших временных и денежных затрат. В то же время, использование свободного или открытого кода имеет свои особенности, которые могут существенно влиять на отношения компании-разработчика с заказчиком.

Open Source Developer Program Software User Concept

Не будем вдаваться в тонкости различий между свободным (Free Software) и открытым (Open Source Software) программным обеспечением, а постараемся посмотреть на «pros and cons» этого явления с юридической стороны и назовем это все в дальнейшем Free and Open Source Software (FOSS).

FOSS — это софт с открытым кодом, который можно свободно просматривать, изучать, изменять, использовать для разработки нового ПО и т.д. Однако не следует забывать, что разработчики такого софта не отказываются от своих авторских прав (в отличие от общественного пользования – public domain – в тех странах, которые это допускают), а «выдают» лицензии на его использование.

Существует множество публичных репозиториев, в которых размещены FOSS-программы, их исходники, а также описание разрешенных способов и особенностей использования такого FOSS – обычно в файле license.txt или README. В зависимости от вида лицензии меняются и обязанности, которые могут возникнуть относительно софта, созданного на базе FOSS кода, или в состав которого включен FOSS-код  (вместе – производный код).

Существует несколько видов FOSS-лицензий, основными из которых являются copyleft (или non-permissive) и permissive-лицензии. Главным отличием между этими лицензиями является необходимость подчинять производный код лицензии, по которой использовался FOSS-код.

Самым известным типом copyleft-лицензии является General Public License (GPL), условия которой предусматривают, что любой производный код должен быть открытым для общественности на условиях GPL-лицензии. При этом к такому производному коду при передаче прав на его использование необходимо прикладывать GPL-лицензию, уведомление об авторском праве и файл с открытым исходным кодом.

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

Разрешительные (permissive) лицензии позволяют распространять производный код на условиях других лицензий или же делать такой код проприетарным. Тем не менее, они также предполагают ряд дополнительных условий. Например, все копии производного кода должны включать текст лицензии и уведомление об авторском праве, содержать имя автора и дату модификаций (MIT License); запрещено использовать название открытого продукта при распространении производного кода (Apache 2.0).

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

На практике нередки случаи, когда инженеры-подрядчики IT-компаний, которые непосредственно занимаются разработкой, впадают в искушение использовать copyleft-лицензированный код то ли с целью упрощения или удешевления своей работы, то ли в силу незнания правил и последствий такого использования. Такие ситуации являются опасными, поскольку в случае использования FOSS-кода по GPL-лицензии (если без такого кода софт не сможет работать) конечный софт не может быть проприетарным и его использование должно подчиняться GPL-лицензии. Последующая передача исключительных имущественных прав интеллектуальной собственности на такой код в большинстве случаев не влияет на существующие лицензии. Как результат, заказчик получит код, относительно которого действует неисключительная лицензия без установленного срока действия для неограниченного  круга пользователей. Если же такой код не будет подчинен условиям GPL-лицензии, заказчик будет нарушать авторские права GPL-владельцев. Вряд ли это будет соответствовать его ожиданиям.

Поэтому согласно данным обзора будущего Open Source 2016, наиболее крупные IT-компании проверяют свой код на наличие FOSS, а треть компаний контролирует инженеров относительно использования FOSS  в разработанном софте.

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

Если же все-таки необходимо удешевить разработку, можно использовать FOSS, который доступен по разрешительным лицензиям (permissive). Таким образом, конечный продукт будет не обязательно подчинять условиям такой лицензии, однако другие условия лицензии выполнять стоит (запрет на рекламу, указание автора модификаций и др.).

Использование FOSS без учета условий лицензии или использование свободного кода, к которому не приложена никакая лицензия, может привести к негативным последствиям, за которые IT-компания будет отвечать как минимум имиджем и как максимум материально. Например, автор (владелец) FOSS-кода может обратиться в суд о возмещении вреда, причиненного нарушением его авторских прав, и заказчик, как владелец продукта, будет нести ответственность перед ним. Если такая история случится в Украине, то «цена» нарушения будет составлять как минимум сумму понесенного вреда. А если автору (владельцу) FOSS не сильно захочется доказывать размер понесенного вреда, то он сможет претендовать на компенсацию в размере от  14 500 грн до 72,5 млн грн (ч.2 ст.52 Закона Украины «Об авторском праве и смежных правах»). Затем «пострадавший от автора» заказчик сможет обратиться с иском о взыскании таких потерь с IT-компании, которой он и заказывал разработку, и которая должна была обеспечить ему передачу имущественных прав интеллектуальной собственности без каких-либо рисков. В других странах существуют похожие механизмы ответственности для недобросовестных разработчиков.

Еще одной ловушкой при использовании FOSS является положение «NO WARRANTY». В случае возникновения каких-либо ошибок в работе производного кода из-за недостатков использованного FOSS, их придется исправлять за собственный счет. Никакой ответственности первоначальных разработчиков и тех, кто в дальнейшем время от времени «допиливал» такой FOSS, в таких случаях не предусмотрено. Зачастую исправление таких ошибок потребует немалых денежных и человеческих ресурсов.

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

Так, например, в марте 2014 года в США начался судебный процесс вокруг использования FOSS-компонента в программном обеспечении Distribution Channel Management (DCM), которое было разработано компанией Versata Software, Inc.

Программное обеспечение DCM основывалось на VTD-XML коде, права интеллектуальной собственности на который принадлежали компании XimpleWare.

XimpleWare предлагает VTD-XML для коммерческого использования по «закрытой» лицензии, а также в некоммерческих целях по лицензии GPLv2. Versata не приобретала «закрытую» лицензию на использование этого программного обеспечения, таким образом, использование ею VTD-XML  регулировалось GPLv2 лицензией.  Использование любого производного от VTD-XML  программного обеспечения должно подпадать под действие лицензии GPLv2. Versata нарушила условия GPLv2, сделав DCM проприетарным. XimpleWare подала иск против Versata и всех клиентов Versata, которые использовали DCM на основании коммерческих лицензий.

Суд признал нарушение лицензии GPLv2 при распространении программного обеспечения DCM. Versata  была вынуждена заменить использованный FOSS на другой код. Все остальные претензии сторон были урегулированы путем переговоров.

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

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

В договоре с клиентом:

1. если клиент согласился на использование FOSS, необходимо использовать только тот FOSS код, который предоставляется по разрешительным лицензиям,  и в договоре определить конкретные виды таких лицензий;
2. предусмотреть освобождение IT-компании от ответственности за какие-либо проблемы в работе конечного софта, при разработке которого использовался FOSS, на который заказчик дал свое согласие;
3. предусмотреть освобождение или ограничение ответственности компании-разработчика в случае предъявления каких-либо претензий со стороны правообладателей FOSS на случай нарушений условий лицензии FOSS заказчиком.

Учитывая стандартную структуру украинских IT-компаний, особое внимание необходимо уделять договорам с инженерами-подрядчиками, поскольку именно они, согласно украинскому законодательству, являются первоначальными авторами софта. В таких договорах, так же, как и в договорах с клиентом,  нужно четко устанавливать будет ли разработка уникальной, или возможно использовать FOSS, предусматривать конкретные виды лицензий и процедуру согласования использования FOSS.

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

И напоследок. Если вы не уверенны, использовался ли FOSS-код при разработке продукта, существуют различные сканирующие программы (FOSS Bar Code Tracker, Dependency Cheker, FOSSology, Black Duck Software, etc.), которые позволяют его выявить.

В качестве превентивных мер желательно разработать внутреннюю политику IT-компании по использованию FOSS для того, чтобы понимать ваши обязанности как заказчика и обязанности разработчиков, а также проводить тренинги для разработчиков о различных видах FOSS-лицензий и требованиях по их соблюдению. Так, например, Фонд открытого программного обеспечения выпустил руководство по соблюдению GPL лицензий, которое можно использовать при составлении такой политики.

Автор: Виктория Луганская, юрист ILF.