abbra: (Default)
Конечные автоматы бывают разные. Есть генераторы исходного кода по схемам-описаниям, есть табличные исполнители, а есть неявные конечные автоматы. Они сложнее, но читаются как детективный роман -- со множеством веток предположений и откатов на исходные позиции, а так же с необходимостью найти на них время. Неявные конечные автоматы в разных проектах -- это то, что одновременно удерживает от прихода новых участников (нужно уметь раскручивать детективный сценарий) и позволяет глубже понять, что и как задумывалось. Разгадав очередной автомат, получаешь вполне осязаемое удовлетворение.
Два примера )
abbra: (Default)
Конечные автоматы бывают разные. Есть генераторы исходного кода по схемам-описаниям, есть табличные исполнители, а есть неявные конечные автоматы. Они сложнее, но читаются как детективный роман -- со множеством веток предположений и откатов на исходные позиции, а так же с необходимостью найти на них время. Неявные конечные автоматы в разных проектах -- это то, что одновременно удерживает от прихода новых участников (нужно уметь раскручивать детективный сценарий) и позволяет глубже понять, что и как задумывалось. Разгадав очередной автомат, получаешь вполне осязаемое удовлетворение.
Два примера )
abbra: (Default)
Trolltech добавила в пакет лицензий QT поддержку GPLv3. QT3 под GPLv3 уже доступна, QT4 доступна в Snapshots.

Это означает, что теперь можно будет поддержку CIFS в KDE обеспечивать на основе Samba 3.2.
abbra: (Default)
Trolltech добавила в пакет лицензий QT поддержку GPLv3. QT3 под GPLv3 уже доступна, QT4 доступна в Snapshots.

Это означает, что теперь можно будет поддержку CIFS в KDE обеспечивать на основе Samba 3.2.
abbra: (Default)
Samba Team перешла на использование GNU GPLv3 практически сразу после публикации окончательной версии лицензии. Принятое в июле 2007 решение состоит в том, что весь код, выпущенный после ветки 3.0 (на сегодня это ветки 3.2 и 4.0) будет доступен под GNU GPLv3 (и отдельные компоненты под GNU LGPLv3). На практике это означает, что все приложения, использующие libsmbclient из Samba 3.2 и старше, клиентскую библиотеку для работы со стеком протоколов CIFS, должны быть совместимы с GNU LGPLv3.

В июле 2007 также было принято решение, что все новшества будут добавляться только в 3.2 и 4.0. Ветка 3.0 (текущая версия 3.0.26a) остается под GNU GPLv2 (и libsmbclient под GNU LGPLv2), однако для этой ветки будут выпускаться только обновления в безопасности.

На самом деле, лицензия на код проекта Samba не строго GNU GPL, а "GNU GPL конкретной версии или более новая версия по выбору пользователя". Это позволяет делать код совместимым с тем, что будет опубликовано под новыми версиями GNU GPL. Однако здесь же возникает некоторая проблема: код, опубликованный строго под лицензией GNU GPLv2, без "или более новая версия по выбору пользователя", становится несовместим с кодом под GNU GPLv3. Такая несовместимость возникла, например, у библиотеки QT: QT доступна строго под GNU GPLv2,

В результате, получается, что код, лицензированный строго под GNU GPLv2, несовместим с кодом, выпущенным под GNU GPLv3 и GNU LGPLv3 (или более поздними версиями этих лицензий). Заметьте, не новая лицензия несовместима, а старая запрещает такое совместное использование.

В рассылках разработчиков дистрибутивов постепенно начинаются дискуссии о том, что использование Samba 3.2 (когда она выйдет) потребует дополнительной работы по выяснению и устранению подобных несовместимостей. Естественно, дискуссии поляризуют и разработчики распались на два лагеря: "GPLv3" и "GPLv3 не нужна". Надо сказать, что определенная логика в позиции последних наблюдается, правда, она далека от практики и проблем, которые создание GNU GPLv3 было призвано адресовать.

Если дискуссия в devel@ в ALT Linux Team пошла скорее в продуктивном русле -- мы попытались выяснить что и как может лицензионно "поломаться" в случае появления в Сизифе версии libsmbclient под GNU LGPLv3 -- то в Fedora-devel-list@ быстро все скатилось в традиционную анти-GPLv3 колею; дело дошло даже до заявлений, что необходимо сменить SONAME библиотеки, поскольку она будет несовместима с предыдущим интерфейсом (на самом деле, совместима, а смену лицензии при всем желании не решают путем сегрегации библиотечных интерфейсов). Однако одно здравое замечание (от Nicolas Mailhot, он не связан с Samba Team) там прозвучало и его я бы хотел процитировать:
The samba project will continue to do maintenance and security fixes
on the last GPLv2 release however it won't get all the improvements of
the next one. So IMHO it's totally unrealistic to expect to keep using
the GPLv2 samba branch even mid-term. Users will start begging for
GPLv3 samba features soon.

That means all the projects that depend on samba will have to move to
GPLv3 compatibility quickly. There is no status-quo escape - the samba
people know they can not be replaced (past forks didn't get any
traction, and no one really wants to dig in MS bugs in their place)
and they've been deeply involved in EU MS litigation (so they know
GPLv2 is not sufficient). The probability of Samba going back to GPLv2
is actually lower than the probability of the kernel going GPLv3.

Some people have blinded themselves thinking their dislike of the FSF
was shared by everyone and boycotting the GPLv3 process would ensure a
bad license no one would use. Groups that had to taste real-world
litigation like Samba, however, have always make clear they were not
happy with GPLv2 and would move their code to GPLv3 no matter what
others chose.


По-русски:
Проект Samba по-прежнему будет выпускать исправления безопасности для последней версии, выпущенной под GPLv2, однако эта версия не будет включать в себя все улучшения, которые попадут в последующие выпуски. Так что, по-моему, полностью нереалистично ожидать использование GPLv2-версии Samba даже в среднесрочной перспективе. Пользователи скоро начнут просить возможности GPLv3-версии Samba.

Это означает, что все проекты, зависящие от Samba, будут вынуждены достаточно быстро обеспечить совместимость с GPLv3. Избежать этого невозможно -- Samba Team знает, что заменить ее труд нечем (предыдущие попытки форков не получили сколько-нибудь серьезного использования и никто не хочет вместо них погрязнуть в ошибках Microsoft), а также они очень серьезно вовлечены в антимонопольный процесс против Microsoft в Европе (так что они знают, что GPLv2 недостаточно). Вероятность того, что Samba вернется к GPLv2 на самом деле меньше вероятности того, что ядро Linux перейдет под GPLv3.

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


Вернемся к приложениям, которые используют тем или иным образом libsmbclient. В GNOME это все приложения, которые собраны с поддержкой GNOME VFS. В официальной поставке GNOME таких приложений под строгой GNU GPLv2 немного: Evolution и Bug-buddy. В Evolution, на самом деле, лицензионный бардак -- с пожеланиями Novell использовать проприетарные расширения там все запутано и простое использование строго GNU GPLv2 вынуждает политические дискусси с Novell -- в них сейчас завязли ребята из Open Change. В Bug-buddy тоже все весело: код строго под GNU GPLv2, по пожеланиям оригинального автора, Якоба Беркмана (работает в Novell). Текущий мейнтейнер, Фернандо Эррера, не против перехода на GNU GPLv2 "или любая более новая версия по выбору пользователя", однако от Якоба мы с ним пока никакого ответа не получили. Якоб не участвует в разработке GNOME уже несколько лет.

С Trolltech и QT пока что вопрос открыт -- говорят, они до сих пор изучают GNU GPLv3. Однако решение в той или иной мере принять придется всем и последние демарши Баллмера демонстрируют насущную необходимость по крайней мере отдельных положений, включенных в GNU GPLv3.
abbra: (Default)
Samba Team перешла на использование GNU GPLv3 практически сразу после публикации окончательной версии лицензии. Принятое в июле 2007 решение состоит в том, что весь код, выпущенный после ветки 3.0 (на сегодня это ветки 3.2 и 4.0) будет доступен под GNU GPLv3 (и отдельные компоненты под GNU LGPLv3). На практике это означает, что все приложения, использующие libsmbclient из Samba 3.2 и старше, клиентскую библиотеку для работы со стеком протоколов CIFS, должны быть совместимы с GNU LGPLv3.

В июле 2007 также было принято решение, что все новшества будут добавляться только в 3.2 и 4.0. Ветка 3.0 (текущая версия 3.0.26a) остается под GNU GPLv2 (и libsmbclient под GNU LGPLv2), однако для этой ветки будут выпускаться только обновления в безопасности.

На самом деле, лицензия на код проекта Samba не строго GNU GPL, а "GNU GPL конкретной версии или более новая версия по выбору пользователя". Это позволяет делать код совместимым с тем, что будет опубликовано под новыми версиями GNU GPL. Однако здесь же возникает некоторая проблема: код, опубликованный строго под лицензией GNU GPLv2, без "или более новая версия по выбору пользователя", становится несовместим с кодом под GNU GPLv3. Такая несовместимость возникла, например, у библиотеки QT: QT доступна строго под GNU GPLv2,

В результате, получается, что код, лицензированный строго под GNU GPLv2, несовместим с кодом, выпущенным под GNU GPLv3 и GNU LGPLv3 (или более поздними версиями этих лицензий). Заметьте, не новая лицензия несовместима, а старая запрещает такое совместное использование.

В рассылках разработчиков дистрибутивов постепенно начинаются дискуссии о том, что использование Samba 3.2 (когда она выйдет) потребует дополнительной работы по выяснению и устранению подобных несовместимостей. Естественно, дискуссии поляризуют и разработчики распались на два лагеря: "GPLv3" и "GPLv3 не нужна". Надо сказать, что определенная логика в позиции последних наблюдается, правда, она далека от практики и проблем, которые создание GNU GPLv3 было призвано адресовать.

Если дискуссия в devel@ в ALT Linux Team пошла скорее в продуктивном русле -- мы попытались выяснить что и как может лицензионно "поломаться" в случае появления в Сизифе версии libsmbclient под GNU LGPLv3 -- то в Fedora-devel-list@ быстро все скатилось в традиционную анти-GPLv3 колею; дело дошло даже до заявлений, что необходимо сменить SONAME библиотеки, поскольку она будет несовместима с предыдущим интерфейсом (на самом деле, совместима, а смену лицензии при всем желании не решают путем сегрегации библиотечных интерфейсов). Однако одно здравое замечание (от Nicolas Mailhot, он не связан с Samba Team) там прозвучало и его я бы хотел процитировать:
The samba project will continue to do maintenance and security fixes
on the last GPLv2 release however it won't get all the improvements of
the next one. So IMHO it's totally unrealistic to expect to keep using
the GPLv2 samba branch even mid-term. Users will start begging for
GPLv3 samba features soon.

That means all the projects that depend on samba will have to move to
GPLv3 compatibility quickly. There is no status-quo escape - the samba
people know they can not be replaced (past forks didn't get any
traction, and no one really wants to dig in MS bugs in their place)
and they've been deeply involved in EU MS litigation (so they know
GPLv2 is not sufficient). The probability of Samba going back to GPLv2
is actually lower than the probability of the kernel going GPLv3.

Some people have blinded themselves thinking their dislike of the FSF
was shared by everyone and boycotting the GPLv3 process would ensure a
bad license no one would use. Groups that had to taste real-world
litigation like Samba, however, have always make clear they were not
happy with GPLv2 and would move their code to GPLv3 no matter what
others chose.


По-русски:
Проект Samba по-прежнему будет выпускать исправления безопасности для последней версии, выпущенной под GPLv2, однако эта версия не будет включать в себя все улучшения, которые попадут в последующие выпуски. Так что, по-моему, полностью нереалистично ожидать использование GPLv2-версии Samba даже в среднесрочной перспективе. Пользователи скоро начнут просить возможности GPLv3-версии Samba.

Это означает, что все проекты, зависящие от Samba, будут вынуждены достаточно быстро обеспечить совместимость с GPLv3. Избежать этого невозможно -- Samba Team знает, что заменить ее труд нечем (предыдущие попытки форков не получили сколько-нибудь серьезного использования и никто не хочет вместо них погрязнуть в ошибках Microsoft), а также они очень серьезно вовлечены в антимонопольный процесс против Microsoft в Европе (так что они знают, что GPLv2 недостаточно). Вероятность того, что Samba вернется к GPLv2 на самом деле меньше вероятности того, что ядро Linux перейдет под GPLv3.

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


Вернемся к приложениям, которые используют тем или иным образом libsmbclient. В GNOME это все приложения, которые собраны с поддержкой GNOME VFS. В официальной поставке GNOME таких приложений под строгой GNU GPLv2 немного: Evolution и Bug-buddy. В Evolution, на самом деле, лицензионный бардак -- с пожеланиями Novell использовать проприетарные расширения там все запутано и простое использование строго GNU GPLv2 вынуждает политические дискусси с Novell -- в них сейчас завязли ребята из Open Change. В Bug-buddy тоже все весело: код строго под GNU GPLv2, по пожеланиям оригинального автора, Якоба Беркмана (работает в Novell). Текущий мейнтейнер, Фернандо Эррера, не против перехода на GNU GPLv2 "или любая более новая версия по выбору пользователя", однако от Якоба мы с ним пока никакого ответа не получили. Якоб не участвует в разработке GNOME уже несколько лет.

С Trolltech и QT пока что вопрос открыт -- говорят, они до сих пор изучают GNU GPLv3. Однако решение в той или иной мере принять придется всем и последние демарши Баллмера демонстрируют насущную необходимость по крайней мере отдельных положений, включенных в GNU GPLv3.

GPLv3

Jan. 16th, 2007 09:51 pm
abbra: (Default)
За суматохой дней забыл о главном -- я, наконец, закончил перевод анализа черновых версий GNU GPLv3 по отношению к российскому законодательству, обещанный [livejournal.com profile] lqp еще летом, и отправил его Эбену Моглену. Надеюсь, что результаты кропотливой работы Федора учтут при выпуске GPLv3 draft 3. По крайней мере, Эбен ответил так:
From: Eben Moglen <moglen@>
Subject: Re: Comments for GPLv3 and Russian law compliance

Thanks. We will take these comments into account, and we are grateful
for the time and effort spent on creating them.

Regards,
Eben


Для желающих, английская версия опубликована тут.

GPLv3

Jan. 16th, 2007 09:51 pm
abbra: (Default)
За суматохой дней забыл о главном -- я, наконец, закончил перевод анализа черновых версий GNU GPLv3 по отношению к российскому законодательству, обещанный [livejournal.com profile] lqp еще летом, и отправил его Эбену Моглену. Надеюсь, что результаты кропотливой работы Федора учтут при выпуске GPLv3 draft 3. По крайней мере, Эбен ответил так:
From: Eben Moglen <moglen@>
Subject: Re: Comments for GPLv3 and Russian law compliance

Thanks. We will take these comments into account, and we are grateful
for the time and effort spent on creating them.

Regards,
Eben


Для желающих, английская версия опубликована тут.

Profile

abbra: (Default)
abbra

April 2016

S M T W T F S
     12
3456789
1011121314 1516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 20th, 2017 05:58 pm
Powered by Dreamwidth Studios