LINUX.ORG.RU

Опубликован первый черновой вариант лицензии GPL v3


0

0

Основная лицензия Open Source приложений - GPL версии 2.0 служила нам верой и правдой пятнадцать лет. Тем не менее, это лицензия слабо отражает новые веяния цифрового мира, такие как: патенты на алгоритмы в ПО, DRM и Trust Worthy Module Computing. Сегодня был опубликован первый черновой вариант лицензии, который должен решить старые проблемы и внести ясность в толковании некоторых пунктов документа.

Специальный сайт, посвященный третьей версии лицензии: http://gplv3.fsf.org/

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous_incognito

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от Sikon

> Поправочка: Торвальдс сделал ядро GPL-системы GNU/Linux.

Принимается. Хотя это не суть важно. Да, вот конкректно ядро GPL системы писал не Столлман лично, нам хотят сказать, что что бы что-то кому-то доказать он должен был написать весь код, до последней строчки? ;-) Это, наверное и есть альтернативное (не GPL) понимание принципов OS. ;-)))

atrus ★★★★★
()
Ответ на: комментарий от anonymous

> А связывание с библиотекой через RPC?

Зависит от данных. В FAQ написано, что если разные модули меняются сложными внутренними структурами данных, то такую связку надо считать одной программой.

atrus ★★★★★
()
Ответ на: комментарий от atrus

> В FAQ написано, что если разные модули меняются сложными внутренними структурами данных, то такую связку надо считать одной программой.

А результат RPC запроса

GET http://www.linux.org.ru/ HTTP/1.1

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

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

> А результат HTTP запроса является?..

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

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

mihalych ★★★
()
Ответ на: комментарий от mihalych

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

XML-RPC? SOAP? CORBA? DCOP?

> Да и главный критерий (незаменимость каждой из частей) тут отсутствует

Это даже не критерий -- замена демонстрируется легко и непринужденно.

baka-kun ★★★★★
()

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

anonymous
()

Нагрубил - садись в тюрьму! 18.01.2006 12:24 | Upgrade В самом начале января американский президент Джордж Буш (George Bush) подписал федеральный закон, согласно которому отныне авторы оскорбительных анонимных электронных сообщений и комментариев в блогах будут нести самую настоящую уголовную ответственность. Иными словами, не желающим подписываться грубиянам теперь грозит тюремный срок. По сути, принятый документ - это дополненная с учетом современных реалий 113 глава одного большого законопроекта, направленного против телефонного хулиганства. Наказание, которое предусматривает закон, весьма суровое, особенно если учесть относительную безобидность описанных в нем действий, - крупные денежные штрафы и 2 года тюрьмы. Есть подозрение, что у закона в самое ближайшее время появится множество противников. Один уже есть - это Американский союз гражданских свобод (American Civil Liberties Union).

Источник: www.news.com

Upgrade

anonymous
()
Ответ на: комментарий от anonymous

Гонят журналюги. Это часть закона против sexual harassment. Потому и протащили, что оно там было ни к селу ни к городу, никто не заметил.

Abnormal
()
Ответ на: комментарий от baka-kun

Генеричные протоколы они и есть генеричные, нет смысла их рассматривать. Вот если на их основании строится свой протокол обмена данными, с семантикой, никем кроме как этими двумя частями не понимаемой, то тогда другое дело.

mihalych ★★★
()
Ответ на: комментарий от mihalych

> Генеричные протоколы они и есть генеричные, нет смысла их рассматривать. Вот если на их основании строится свой протокол обмена данными

То есть ты абсолютно уверен, что если одно приложение под GPL обменивается IDL с другим приложением, то второе тоже обязано быть под GPL? А если ORB под GPL, то получается, и клиент, и сервер автоматически становятся derived work?

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Я абсолютно уверен, что если суд решит, что это на самом деле две взаимозависимые части одной програмы, не могущие работать друг без друга, то тогда термин "program" (или "work") в GPL следует читать как совокупность этих обоих частей.

mihalych ★★★
()
Ответ на: комментарий от mihalych

> Я абсолютно уверен, что если суд решит, что это на самом деле две взаимозависимые части одной програмы, не могущие работать друг без друга

[remark] Ага... То есть если суд решит, что Linux не может работать без кода, принадлежащего TSG... [/remark]

А казалось бы, такой простой вопрос. Два куска кода могут сообщаться между собой или посредством линковки -- статической или динамической (как compile-time, так и run-time -- dlopen) -- где всё предельно понятно -- они разделяют общую память, так и посредством, в общем случае, некоего IPC (файл, пайп, сокет, разделяемая память, ..., флажковые семафоры, дымовые сигналы и там-тамы), проводящего чёткую грань между адресными пространствами процессов.

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

А оказывается, есть люди, которые аккуратненько пытаются разделять и властвовать: "а-а-а, эти программы слишком тесно между собой общаются! И одна из них богоизбранная! Эй, Фараон, отдавай МОЙ код! И мне плевать, что ты его родил и воспитал потом и кровью!"... Дальше -- больше...

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

> Вот здравый смысл подсказывает

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

А чём собственно конкретно проблема? Было какое-то нездравое решение суда относительно TSG, или просто хочется без причины на GPL наехать? :)

mihalych ★★★
()
Ответ на: комментарий от baka-kun

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

Теоретически - да. Практически распростарнять их вместе все равно нельзя. Т.е. вот моя закрытая супер-прога за деньги, а вон по той ссылке можете взять "file utils", без которых моя прога нифуя работать не будет :)

yyk ★★★★★
()
Ответ на: комментарий от mihalych

> Ну, если суд не руководствуется здравым смыслом, то в такой ситуации тебе ничего не поможет, никакая лицензия, даже BSDL, будешь сидеть невиновным. :-)

Ну уж если СУД скажет, что черное -- это белое, а бело -- черное, то тут уж точно никто не поможет. ;)

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

> А чём собственно конкретно проблема?

В отсутствии чёткого определения, где начинается и заканчивается derived work.

> или просто хочется без причины на GPL наехать? :)

Да боже упаси! ;) Чтобы я, да без причин? ;)

baka-kun ★★★★★
()
Ответ на: комментарий от yyk

> Теоретически - да. Практически распростарнять их вместе все равно нельзя.

А что, где-то есть запрет на распространение GPL ПО на одном носителе с не-GPL? Или где-то есть запрет на запуск GPL ПО посредством не-GPL? Или хоть где-нибудь есть запрет на установку GPL ПО не-GPL инсталлятором?

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

> В отсутствии чёткого определения, где начинается и заканчивается derived work.

Повторю в третий раз, решение вопросов, таких как "является ли программа A производной или неразрывно зависимой от программы B", "кто является автором некого кода", "используется ли в коде запатентованные технологии" и подобное никаким образом не являются прерогативой лицензий, а лишь суда. Суд создаст специальную коммисию (как в случае с SCO против IBM), которая учтет все аргументы и здравый смысл, и ответит на эти вопросы.

Пока прецендентов разбирательств по-моему не было, но принято считать, что критерий незаменимости является решающим.

mihalych ★★★
()
Ответ на: комментарий от mihalych

> Повторю в третий раз, решение вопросов, таких как "является ли программа A производной

Очень сильно зависит от формулировки термина "производная". И в семантике этого слова, и в трактовке "закона об авторском праве" достаточно явно обозначено использование в чём-то части другого, первое "произведено" из второго. Но когда одно использует _результат_работы_ второго -- не его внутренности и прочую требуху, а именно результат их жизнедеятельности --, то ни о каком "произведении" речи идти не может. Это базовое понятие: на скомпилированный код не распространяется лицензия компилятора.

> или неразрывно зависимой от программы B"

А вот тут ты привносишь новое понятие, расширяя границу с, условно, "поглощения" на "взаимодействие". Вот я у тебя (не суда) спрашиваю, а где же на твой взгляд должна располагаться эта граница? Обязан ли, например, конфигуратор exim распространяться _только_ под GPL? А фронтенд к nmap?

Собственно, речь о том, что "неразрывно зависимая" программа -- это далеко не то же самое, что и "производная". И если второе определение целиком лежит в плоскости авторского права, то первое -- дело лицензии. Это ничто иное, как _ограничение_ на применение ПО для определенных целей. Если точнее, то даже не на применение самого ПО, а _результатов_ его _работы_.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

> А что, где-то есть запрет на распространение GPL ПО на одном носителе с не-GPL? Или где-то есть запрет на запуск GPL ПО посредством не-GPL? Или хоть где-нибудь есть запрет на установку GPL ПО не-GPL инсталлятором?

But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Хотя признаю, что это "из другой оперы" :)

yyk ★★★★★
()
Ответ на: комментарий от baka-kun

> Собственно, речь о том, что "неразрывно зависимая" программа -- это далеко не то же самое, что и "производная".

Т.е. можно клепать проги с динамической линковкой к GPL библиотекам? (никакой производной, только использование результатов деятельности).

Ату! Всем срочно клепать закрытые проги с readline, gettext и iconv! :)

yyk ★★★★★
()
Ответ на: комментарий от yyk

> Т.е. можно клепать проги с динамической линковкой к GPL библиотекам?

[rem] Можно,.. если они будут GPL. ;) [/rem]

Ты не заметил, или невнимательно прочитал. В #1236017 я провел водораздел между линковкой (включая любой вид динамической) и общением standalone приложений (например через пайп или сокет). Так вот, по моему мнению, во втором случае ни одна программа не является производной от другой, какими бы сложными структурами и как часто они не обменивались. Даже если вообще жить друг без друга не могут.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Это твоя трактовка, я с ней не согласен. И по-моему, FSF тоже. Однозначного ответа тут нет, существует здравый смысл, которым все руководствуются. Так вот, если эти две части были написаны друг для друга, то они просто части одной программы, и не важно, что она форкается или даже распределяется на процессы на разных процессорах.. Если же лишь одна часть была написана ради другой, то тут может иметь место "derived work" (производная работа), в случае если эта новая часть ни на что больше не пригодна.

mihalych ★★★
()
Ответ на: комментарий от mihalych

> Это твоя трактовка, я с ней не согласен.

Это твоё право. Раз так, очень хотелось бы услышать, где проходит граница по _твоему_ мнению.

> Однозначного ответа тут нет, существует здравый смысл, которым все руководствуются.

Вот в том-то и беда, что нет чёткого однозначного определения. Если с заимствованием коде всё понятно, то с _распространением_ (и отчасти использованием) -- мутная водица. "Можешь делать, что хочешь, но если мне это вдруг _постфактум_ не понравится, я тебя засужу-у-у!!!". Где чёткие формулировки, для каких целей я могу использовать (еще раз обрати внимание) _результат_ работы программы?

> Так вот, если эти две части были написаны друг для друга, то они просто части одной программы

То есть два независимых разработчика вот так просто сели, и написали программы друг для друга? Причём так, что ни одна не может без другой?

> Если же лишь одна часть была написана ради другой, то тут может иметь место "derived work" (производная работа), в случае если эта новая часть ни на что больше не пригодна.

Вот опять: "может иметь место". :( Ты что не видишь, что это недоработка? "Тут играем, тут не играем, а тут рыбу заворачивали".

Я тебя еще раз спрошу: обязан ли фронтенд к GPL программе иметь такую же лицензию? Тут имеют место оба твоих условия: "одна часть была написана ради другой" и "новая часть ни на что больше не пригодна". Ответь, пожалуйста, на такой простой вопрос.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

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

Вроде бы преступление совершил, а иногда могут и оправдать. Нельзя в общем случае судить. Давай конкретный пример хотя бы.

mihalych ★★★
()
Ответ на: комментарий от mihalych

> Как будто не бывает в жизни неоднозначных ситуаций. Ложь во имя спасения, убийство в целях самообороны, подслушал и передал полиции, украл у государства и подарил детскому дому.

Ну к чему эта демагогия? В твоих примерах объектом является человек, плюс огромная эмоциональная насыщенность. А вот в случае с лицензией на абсолютно неодушевленное и нематериальное программное обеспечение можно было бы и расстараться, чтобы всё чётко по полочкам разложить. Ты ведь разумный человек, всё прекрасно понимаешь. Недаром, ни на один вопрос не ответил.

> Давай конкретный пример хотя бы.

Да чем он тебе поможет? Да что, мало в природе приложений, запускающих какой-нибудь GNU tar или gzip, причем и заменить их нельзя, и работать без них не будет? А уж фронтендов ко всяким GPL утилитам...

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

> Да чем он тебе поможет? Да что, мало в природе приложений, запускающих какой-нибудь GNU tar или gzip, причем и заменить их нельзя, и работать без них не будет?

Ну, ты же сам понимаешь, что это трудно (или нельзя) будет назвать производной. gzip и gtar - генеричные утилиты, и очень легко избавиться от их зависимости. Сделав .tar.Z или .zip или что-то другое, без потери функциональности программы. Принцип незаменимости не срабатывает.

> А уж фронтендов ко всяким GPL утилитам...

Вот тут зависимость явная, так что вполне можно назвать производной, хотя всё зависит от конкретного случая.

mihalych ★★★
()
Ответ на: комментарий от mihalych

Проясню. Конечно же, к простому фронтенду, который лишь запускает программу, заменяя выбор с помощью виджетов на опции, придраться сложно. Такое использование скорее всего будет считаться fair use, обычный запуск, что разрешено.

Однако, если мы рассмотрим интерактивный GUI к CVS, то тут уже граничный случай. Практически утилита cvs используется как библиотека. Чтобы стало ещё понятнее, предположим некая утилита позволяет запускать комманды "math sin" и "math cos". Некто написал фронтенд, который пропускает все многочисленные комманды, но и добавляет несколько своих. Т.е. и "mathplus sin" и "mathplus cos" доступны, и новая комманда "mathplus tan", где tan=sin/cos. На месте автора math, я бы потребовал признания mathplus производной программой, т.е. открытия дополнительных исходников под GPL совместимой лицензией. (Почему совместимой, а не строго GPL, смотри GPL FAQ.)

mihalych ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.