Лицензия раздора
Roman I Khimov, Вторник, 17 Июль 2007, 19:40
Хорошо это или плохо, но выбор лицензии в мире свободного ПО диктует многое. В первую очередь, возможность осуществления основного права, даваемого этими лицензиями, а именно, права на изменение программ. Очевидно, что выбрав какую-то лицензию вы потом сможете интегрировать в свой проект только исходники под какой-то совместимой с вашей лицензией. В случае с GPLv2 ситуация осложнена тем, что лицензия "вирусная" и должна охватывать весь распространяемый вами код.
За время существования GPLv2 успел накопиться солиднейший пул ПО, распространяемого под этой лицензией. Возможно, именно из-за её "вирусной" сущности. Сопоставимый (но при этом всё же значительно уступающий) пул имеется, пожалуй, только у лицензии BSD, но она находится в заведомо проигрышном положении - GPL-ные проекты могут запросто использовать BSD-шный код, но вот обратное никак не возможно.
Конечно, существуют ещё десятки других лицензий, но чаще всего они либо достаточно попустительские, чтобы не причинять никому неудобств (например, MIT), либо используются для отдельных проектов, которые варятся в собственном соку (например, MPL). Погоды они не делают, основных столпа два - GPLv2 и BSD, причём, как уже говорилось выше, GPLv2 сильнее по определению.
И вот в эту установившуюся систему взаимодействий приходит новая версия GPL. Не будем спорить насколько она хороша или плоха, удачна/неудачна, это не так важно для сути текущего обсуждения. Важно другое, лицензии GPLv3 и GPLv2 несовместимы. И по задумке FSF, естественно, новая версия должна вытеснить другую. Именно с этим, к сожалению, и есть проблемы.
Будет ли распространяться Linux под GPLv3, на самом деле, совсем не так важно, как это пытаются представить. Хотя, конечно, слово Линуса для многих будет серьёзным аргументом, но лицензия нашего славного ядра, к счастью, ни на что напрямую не влияет, ядро это самодостаточная система, которая крайне редко заинтересована в прямом обмене кодом с другими проектами (хотя есть примеры и такой плодотворной работы, см. KVM, который притащил в ядро добрую часть QEMU).
Значительно важнее то, что будет происходить в пользовательском пространстве, где появляются первые приложения под новой лицензией и другим приложениям необходимо с ними как-то взаимодействовать, в том числе, напрямую обмениваться кодом. На сегодняшний момент на новую лицензию перешли, естественно, все проекты, контролируемые FSF, а также Samba.
Здесь надо сказать, что у некоторых компаний есть вполне чёткие претензии к GPLv3, опять-таки, не будем спорить о том, насколько они обоснованы, важно, что они есть. Помимо этого, новая лицензия поставила их перед занятным фактом. Как известно, одним из основных источников заработка компаний, работающих со свободным ПО, является поддержка. Все выпущенные продукты, прим этом, имеют жёстко зафиксированные версии входящих в них компонент.
Прелесть ситуации заключается в том, что многие ошибки, обнаруживаемые в программах, исправляются в основных репозиториях разработчиков и позже подхватываются дистрибьюторами для адаптации к своим старым стабильным веткам программ. Если раньше это было просто и понятно, то сейчас, при смене лицензии разработчиками, патч, исправляющий ту или иную ошибку и разработанный после смены лицензии, конечно же, должен распространяться по новой лицензии. А вот у дистрибьютора появляется головная боль из-за того, что у него есть несколько вариантов развития событий:
Как вы понимаете, это выбор без выбора. И надо заметить, некоторые вендоры уже предупредили своих клиентов о возможной смене лицензии поставляемых продуктов "на ходу".
Тем не менее, возможен и другой вариант развития событий, который, это надо особо отметить, вполне серьёзно обсуждается в компаниях. Это - создание ответвлений от основных проектов, основаных на коде, доступном под старой лицензией GPLv2. По факту, бОльшая часть разработок сейчас проводится хорошо оплачиваемыми сотрудниками разных компаний, в том числе и в тех проектах, которые требуют передачи копирайта (правами на проекты FSF целиком и полностью обладает FSF).
Однако, надо понимать, что такое решение потянуть могут только большие игроки в бизнесе GNU/Linux, а конкретно это Red Hat и Novell (IBM/Oracle/другие в значительно меньшей степени), поскольку это потребует полностью самостоятельной разработки и полную невозможность использования кода, разработанного под GPLv3. Даже если GPLv3 будет использоваться только в FSF и Samba это уже такой объём и уровень сложности кода, что ни один более мелкий игрок не сможет это тянуть на себе. Но не приходится сомневаться в том, что если любой из крупных игроков начнёт такое ответвление, за ним (а точнее, совместно с ним) потянутся и множество более мелких.
При этом, что ещё интереснее, проекты под GPLv3 всё-таки будут иметь преимущество, поскольку абсолютное большинство проектов распространяется с условием "GPLv2 или выше", поменять которое может только правообладатель. Тем самым, "материнские" проекты в большинстве случаев всё же смогут интегрировать код, разработанный ответветвлениями под GPLv2 в свои проекты, меняя лицензию на GPLv3. Впрочем, это же потребует значительных усилий по синхронизации от свободолюбивых программистов, что тоже не сахар, особенно при учёте реализации своих отдельных задач.
В целом, возможность серьёзного раскола в сообществе с не очень ясными последствиями налицо. Но ситуация запрограммирована так, что новый вирус (aka GPLv3) должен всё-таки целиком и полностью поглотить старый (aka GPLv2). И если это действительно пойдёт в таком направлении без создания ответвлений на лицензионной основе, то всё будет нормально, даже несмотря на отдельные вопли бизнесменов о том как проклятая FSF не даёт зарабатывать на свободном ПО. Но если старый вирус сдаваться откажется и будет поддержан бизнесом, нас ждёт интереснейшее, но очень печальное время упущеных возможностей. FSF сделала свой ход, карты в руках крупных бизнес-игроков, ждём-с.
это контент от Центр информации по операционным системам
( http://www.osrc.info/plugins/content/content.php?content.129 )
Roman I Khimov, Вторник, 17 Июль 2007, 19:40
Хорошо это или плохо, но выбор лицензии в мире свободного ПО диктует многое. В первую очередь, возможность осуществления основного права, даваемого этими лицензиями, а именно, права на изменение программ. Очевидно, что выбрав какую-то лицензию вы потом сможете интегрировать в свой проект только исходники под какой-то совместимой с вашей лицензией. В случае с GPLv2 ситуация осложнена тем, что лицензия "вирусная" и должна охватывать весь распространяемый вами код.
За время существования GPLv2 успел накопиться солиднейший пул ПО, распространяемого под этой лицензией. Возможно, именно из-за её "вирусной" сущности. Сопоставимый (но при этом всё же значительно уступающий) пул имеется, пожалуй, только у лицензии BSD, но она находится в заведомо проигрышном положении - GPL-ные проекты могут запросто использовать BSD-шный код, но вот обратное никак не возможно.
Конечно, существуют ещё десятки других лицензий, но чаще всего они либо достаточно попустительские, чтобы не причинять никому неудобств (например, MIT), либо используются для отдельных проектов, которые варятся в собственном соку (например, MPL). Погоды они не делают, основных столпа два - GPLv2 и BSD, причём, как уже говорилось выше, GPLv2 сильнее по определению.
И вот в эту установившуюся систему взаимодействий приходит новая версия GPL. Не будем спорить насколько она хороша или плоха, удачна/неудачна, это не так важно для сути текущего обсуждения. Важно другое, лицензии GPLv3 и GPLv2 несовместимы. И по задумке FSF, естественно, новая версия должна вытеснить другую. Именно с этим, к сожалению, и есть проблемы.
Будет ли распространяться Linux под GPLv3, на самом деле, совсем не так важно, как это пытаются представить. Хотя, конечно, слово Линуса для многих будет серьёзным аргументом, но лицензия нашего славного ядра, к счастью, ни на что напрямую не влияет, ядро это самодостаточная система, которая крайне редко заинтересована в прямом обмене кодом с другими проектами (хотя есть примеры и такой плодотворной работы, см. KVM, который притащил в ядро добрую часть QEMU).
Значительно важнее то, что будет происходить в пользовательском пространстве, где появляются первые приложения под новой лицензией и другим приложениям необходимо с ними как-то взаимодействовать, в том числе, напрямую обмениваться кодом. На сегодняшний момент на новую лицензию перешли, естественно, все проекты, контролируемые FSF, а также Samba.
Здесь надо сказать, что у некоторых компаний есть вполне чёткие претензии к GPLv3, опять-таки, не будем спорить о том, насколько они обоснованы, важно, что они есть. Помимо этого, новая лицензия поставила их перед занятным фактом. Как известно, одним из основных источников заработка компаний, работающих со свободным ПО, является поддержка. Все выпущенные продукты, прим этом, имеют жёстко зафиксированные версии входящих в них компонент.
Прелесть ситуации заключается в том, что многие ошибки, обнаруживаемые в программах, исправляются в основных репозиториях разработчиков и позже подхватываются дистрибьюторами для адаптации к своим старым стабильным веткам программ. Если раньше это было просто и понятно, то сейчас, при смене лицензии разработчиками, патч, исправляющий ту или иную ошибку и разработанный после смены лицензии, конечно же, должен распространяться по новой лицензии. А вот у дистрибьютора появляется головная боль из-за того, что у него есть несколько вариантов развития событий:
- Если код распространяется по лицензии "GPLv2 и выше", то разработчик может использовать существующий патч, но автоматически, при этом, будет сменена лицензия на "GPLv3 и выше".
- Если код доступен строго по лицензии "GPLv2" или разработчик не хочет/не может менять лицензию, он вынужден придумывать собственные исправления для проблемы
Как вы понимаете, это выбор без выбора. И надо заметить, некоторые вендоры уже предупредили своих клиентов о возможной смене лицензии поставляемых продуктов "на ходу".
Тем не менее, возможен и другой вариант развития событий, который, это надо особо отметить, вполне серьёзно обсуждается в компаниях. Это - создание ответвлений от основных проектов, основаных на коде, доступном под старой лицензией GPLv2. По факту, бОльшая часть разработок сейчас проводится хорошо оплачиваемыми сотрудниками разных компаний, в том числе и в тех проектах, которые требуют передачи копирайта (правами на проекты FSF целиком и полностью обладает FSF).
Однако, надо понимать, что такое решение потянуть могут только большие игроки в бизнесе GNU/Linux, а конкретно это Red Hat и Novell (IBM/Oracle/другие в значительно меньшей степени), поскольку это потребует полностью самостоятельной разработки и полную невозможность использования кода, разработанного под GPLv3. Даже если GPLv3 будет использоваться только в FSF и Samba это уже такой объём и уровень сложности кода, что ни один более мелкий игрок не сможет это тянуть на себе. Но не приходится сомневаться в том, что если любой из крупных игроков начнёт такое ответвление, за ним (а точнее, совместно с ним) потянутся и множество более мелких.
При этом, что ещё интереснее, проекты под GPLv3 всё-таки будут иметь преимущество, поскольку абсолютное большинство проектов распространяется с условием "GPLv2 или выше", поменять которое может только правообладатель. Тем самым, "материнские" проекты в большинстве случаев всё же смогут интегрировать код, разработанный ответветвлениями под GPLv2 в свои проекты, меняя лицензию на GPLv3. Впрочем, это же потребует значительных усилий по синхронизации от свободолюбивых программистов, что тоже не сахар, особенно при учёте реализации своих отдельных задач.
В целом, возможность серьёзного раскола в сообществе с не очень ясными последствиями налицо. Но ситуация запрограммирована так, что новый вирус (aka GPLv3) должен всё-таки целиком и полностью поглотить старый (aka GPLv2). И если это действительно пойдёт в таком направлении без создания ответвлений на лицензионной основе, то всё будет нормально, даже несмотря на отдельные вопли бизнесменов о том как проклятая FSF не даёт зарабатывать на свободном ПО. Но если старый вирус сдаваться откажется и будет поддержан бизнесом, нас ждёт интереснейшее, но очень печальное время упущеных возможностей. FSF сделала свой ход, карты в руках крупных бизнес-игроков, ждём-с.
это контент от Центр информации по операционным системам
( http://www.osrc.info/plugins/content/content.php?content.129 )