ROS Blog Intellectual Property: Ideology vs Practicality

Интеллектуальная собственность: Идеология vs Практичность

Оригинал статьи - http://www.reactos.org/node/724

Дата публикации оригинальной статьи - 14.12.2013

Автор оригинальной статьи - Цзылян Гуо

Главное, о чём должны помнить люди при обсуждении тех или иных аспектов GPL это то, что эта лицензия была создана в первую очередь для достижения идеологических и политических целей, а именно для того, чтобы пользователи программного обеспечения получили возможность изменять и дополнять программное обеспечение исходя из собственных потребностей. Для достижения этой цели, GPL стремится обеспечить постоянную доступность исходного кода и возможность его повторного использования без каких-либо ограничений за исключением лишь тех, которые накладывает сама лицензия GPL в целях обеспечения защиты этих свобод. Разумеется, в этой цели есть немало благородных аспектов, но есть в ней и последствия для программистов, разрабатывающих код под GPL. Самым значительным из них является идеология "всё или ничего". Если вы пожелаете непосредственно использовать код, покрытый лицензией GPL, в своём приложении, то будьте готовы, что ваш код будет подчиняться требованиям GPL, и вы будете обязаны предоставить его по первому же запросу. А иногда это бывает не так уж просто сделать, насколько об этом думают некоторые фанатично настроенные защитники свободного ПО. Но их можно понять, ведь их целью является мир, в котором всё ПО имеет лицензию GPL, поскольку они считают, что именно это и является самым "правильным" положением вещей в индустрии программного обеспечения. Однако проблема здесь в том, что выбрав продвижение идеологической позиции в качестве основной цели, GPL может фактически может создать препятствия повторному использованию кода, распространяемого под этой лицензией.

Как уже упоминалось выше, когда кто-либо использует код под лицензией GPL, его код также получает лицензию GPL, а сам он обязан обеспечить доступность своего кода по первому запросу. Это, опять же, создаёт некоторые проблемы разработчику, поскольку необходимо потратить некоторое время и ресурсы для обеспечения доступности кода. Если разработчик не разделяет целей и идеологии GPL, то ему придётся сделать выбор между этими неудобствами и необходимостью самостоятельно создавать все функции, которые уже имеются в коде, покрытом лицензией GPL. В большинстве случаев цена самостоятельного создания функционала играет более важную роль, чем удобство повторного использования чужого кода, поскольку как только код получит лицензию GPL, то все его итерации будут распространяться лишь под лицензией GPL, что приводит к созданию долгосрочных обязательств и обременению. Таким образом, в долгосрочной перспективе куда проще и дешевле разработать собственное решение, чем повторно использовать уже имеющийся, но покрытый лицензией GPL, код. Другим решением может стать использование кода под более пермиссивными лицензиями, например Apache или BSD. Они лишь требуют чтобы код и его непосредственные модификации оставались под лицензией BSD, и не содержат требований по перелицензированию остальных частей программы под эту лицензию. Таким образом, эти лицензии позволяют упростить использование покрытого ими кода, накладывая минимум ограничений на его использование. Выбор разработчиков, которых не заботит идеология, или компаний, которые имеют довольно сложные соглашения об использовании интеллектуальной собственности, будет довольно очевиден.

Хотя я и не стану приводить аргументы в пользу той или иной позиции, я всё же приведу аргументы о том, какая из них наиболее полезна с точки зрения программиста. Мир программного обеспечения устроен довольно сложно и программирование само по себе является непростой задачей, так программисту ещё нужно обдумать правовой статус различных частей кода! Если представить, что открытый код это "белое", а закрытый код - "чёрное", то свободное ПО будет, скорее, "серым". При использовании открытого или закрытого кода вы чётко понимаете, что можно и что нельзя делать с этим кодом. При использовании свободного ПО всё далеко не так очевидно.