Ну, понятно, что если участник не имеет добрых намерений, то рано или поздно это будет ясно и из анализа его деятельности внутри Википедии. Тем не менее, «маскироваться» можно довольно долго. Ведь, например, далеко не всегда очевидно, улучшает правка статью, или ухудшает — и у разных участников здесь могут быть разные мнения. К тому же, помимо статей есть еще огромное пространство обсуждения разных общих вопросов, касающихся развития сообщества, где тоже есть пространство для взаимодействия и споров. И тут уже совсем трудно понять, какие действия хорошие, а какие — плохие. Вот, скажем, участник А выступает против присвоения прав администратора участнику Б. Это он делает исходя из каких-то объективных соображений, с целью принести пользу проекту, или просто потому, что хочет позлить Б? И т.д.
Основной деструктивный эффект здесь достигается на том, что если анализровать вневикипедийную информацию, то отсутствие добрых намерений очевидно сразу. И для тех людей которым оно очевидно (скажем, для объекта нападок), работать совместно с таким участником — практически невозможно, причем уже сейчас. А меры можно будет принять, исходя из доктрины «невидимости внешних ресурсов» — только через многие месяцы. А цели тролля к тому моменту уже будут достигнуты — участник выжит из проекта.
Проблема в том, что ведь всё равно пишут. Так пусть хоть пишут грамотно, и не начинают скандалить, когда статью собираются удалять. Это сэкономит много нервов всем, в том числе — администраторам и другим участникам Википедии.
Не читайте советских газет :) Подробнее о Flagged Revs см. также здесь. А по сути: никакой, даже самый жесткий режим включения Flagged Revs не подразумевает «премодерацию» в обычном смысле: никакие правки не скрываются, и те люди, которые хотят увидеть самую свежую правку, всегда могут её увидеть. А если даже говорить о такой «мягкой» премодерации, то необходимо понимать, что «модераторами» (точнее, участниками с правом editor) уже сейчас в русской Википедии больше 300 человек, и им может стать любой участник, обладающий базовым опытом работы в проекте. И единственная цель этой системы в настоящий момент — борьба с вандализмом и другими вопиющими проблемами в статьях. Так что слухи о «введении премодерации» несколько преувеличены. :)
Премодерации в Википедии нет, не было, и не будет — по крайней мере, не больше, чем на digg'е или Хабрахабре. Всё остальное, в данном случае, к сожалению, Ваши домыслы. А по стилю — ну так никто не и не спорит с тем, что юмористические тексты читаются лучше, чем энциклопедические. Только я не понимаю противопоставления. Каждому свое.
Пожалуй, всё ж таки надо сказать, что цитированные в посте критерии значимости пока не приняты как правила, поэтому ссылаться на них надо осторожно, и в первую очередь ориентироваться на общий критерий значимости (который, правда, тоже не принят, но зато более-менее вытекает из других правил).
Нет, если модуль использует Crypt::MatrixSSL (т.е. содержит use Crypt::MatrixSSL), то я полагаю, что это очевидно является созданием производной работы с библиотеки, и требует выполнения условий GPL.
С драйверами nVidia и ядром вообще ситуация интересная. Насколько я понимаю мнение Торвальдса (могу поискать релевантную переписку на LKML), он говорит, что мы не можем считать видеодрайвер «производной работой с ядра», если, скажем, существенная часть кода этого драйвера совпадает с версией того же драйвера под Windows, а из кода ядра для сборки этих драйверов нужны только заголовочные файлы (Торвальдс считает, что это fair use этих участков кода). Тем самым, если принять трактовку Торвальдса, то конечно само по себе существование таких драйверов действительно 100% легально.
Насчет совместной дистрибуции — вопрос более интересный. Я так понимаю, что единственные правообладатели, чьи права могут нарушаться при такой совместной дистрибуции — это права авторов linux kernel. Насколько я понимаю, они смотрят на это «сквозь пальцы» (в отличие от, например, распространения kernel в различных устройствах при несоблюдении устройств — см. gpl-violations.org). Что касается «наездов» на вендоров GNU/Linux-дистрибутивов — я помню какую-то мутную историю, связанную с этим, но, кажется, тот человек, который пытался призвать к ответственности кого-то из вендоров, на самом деле никаких прав это делать не имел.
В то же время, описанная автором исходного поста ситуация явно иная: здесь разработчики исходной библиотеки кровно заинтересованы в том, чтобы условия GPL выполнялись максимально строго, и скорее всего, если автор сделает то, что им задумано (основательно порушив бизнес-модель исходного разработчика), я думаю, что это явно не останется незамеченным со стороны исходных девелоперов.
Я не вполне уверен в столь однозначной трактовке. Есть ли у вас информация о прецедентах такого использования GPL-лицензированных библиотек крупными проектами (где можно было бы ожидать, что потенциальное нарушение условий лицензии заинтересует разработчиков исходной GPL-библиотеки)?
Замечу, что как я писал выше, динамическую линковку с какими-либо библиотеками FSF считает созданием «производной работы». См. также релевантные вопросы в GPL FAQ: О GPL-ных плагинах, О GPL-библиотеках.
Поставленный вопрос довольно нетривиален. Заведомо известно, что в FSF полагает любую (стастическую или динамическую) линковку программы с библиотекой созданием derivative work с библиотеки. Что касается RPC, то здесь мне не все ясно. Вроде бы, никто не считает общение веб-браузера с веб-сервером с помощью HTTP созданием производной работы. Но RPC мне кажется более жесткой связкой клиентской программы с серверной, и может порождать derivative work при определенной трактовке.
Я думаю, что основной вопрос, который здесь следует задать, звучит так: можете ли вы написать сторонее приложение (которое вы не собираетесь лицензировать под GPL), не имея информации о внутреннем устройстве исходной GPL-ной библиотеки, и опираясь, скажем, только на спецификации публично-доступных протоколов? (Понятно, что я могу написать веб-браузер, не заглядывая во внутреннее устройство IIS, просто глядя на спецификации HTTP, поэтому мой браузер заведомо не будет производной работой с IIS; IIS в данном случае можно будет заменить на Apache или на что угодно еще.) Если ответ отрицательный, то я полагаю, что получившийся гибрид может считаться созданием производной работой с исходной библиотеки и не может распространяться под лицензией, отличной от GPL.
Более того: даже если написание такой «тройки» программ может быть и легальным, но совместное распространение может оказаться нелегальным. Этот вопрос необходимо изучить отдельно.
В любом случае, наверное, имеет смысл посоветоваться с каким-нибудь юристом, разбирающимся в вопросах свободных лицензий. Правда, боюсь, что в России таковых нет или почти нет.
Нет, это неверно. GPL не требует «показывать исходники всему миру». GPL требует в точности то, что она требует: если вы передаете производную работу с GPL-лицензированной своему заказчику, то вы обязаны передать её вместе с исходниками и тоже на условиях GPL (то есть заказчик, если захочет, сможет распространять её дальше на тех же условиях). Если вы даете возможность скачать свою программу всем желающим (в виде бинарника) — тогда да, нужно предоставлять и исходники всем желающим. Но если вы делаете работу под заказ, такого требования нет. Подробнее см. первоисточники.
Короткий ответ: попробуйте :)
Длинный ответ: на чем вы будете собирать эту систему? Чтобы ее собрать, нужно собрать toolchain (набор инструментов для сборки). А на чем его собрать?..
Собственно, люди в CentOS и подобных проектах именно этим и занимаются. Как рассказывали когда-то представители ScientificLinux на Open Source Forum, приходится пересобирать систему по три раза…
Нет, это неверно. Правильно следующее: если вы передаете кому-то программу, основанную на GPL-коде, вы обязаны передать также ее исходник, причем на тех же условиях (GPL). То есть получатель вашей программы (лицензиат) сможет распространять эту программу дальше (но на условиях все той же GPL) — бесплатно или за деньги, как угодно.
Другое дело, что если Вы позволяете скачать бинарник свободно кому угодно, то обязаны также кому угодно раскрыть и исходник. Все так и делают обычно.
Да, это понятно, что в среднем поддерживается определенный паритет или даже идет некоторый прогресс по всем параметрам, и современные камеры с большим числом мегапикселей шумят не сильно больше, чем их значительно менее мегапиксельные собратья. Понятно, что баланс между разными параметрами определяется рынком, в т.ч. его PR/маркетинговыми составляющими. Я говорю о том, что я лично предпочел бы, чтобы этот баланс был сдвинут в сторону «меньше шумов, больше чувствительность». С другой стороны, вопрос — а когда все-таки объективно надо остановиться в росте числа пикселей? Уже 6 мегапикселей хватает, чтобы печатать снимки A4 на примерно 250 dpi. Ну, допустим, иногда хочется напечатать снимок на журнальном развороте с 300 dpi. Это максимум 15 мегапикселей. Зачем больше?
Я не большой специалист в фотографии, но мне казалось, что мешают — уменьшая физический размер ячейки, уменьшается поток, который она воспринимает, а значит — меньше предельная чувствительность, больше шумов…
То есть я бы предпочел камеру с вдвое меньшим числом мегапикселей, если на ней смогу снимать с вдвое большим ISO.
Действительно, здесь лучше достаточно аккуратно выбирать слова. GPL запрещает создание проприетарного («закрытого») форка с Вашей программы — то есть если кто-то возьмет Ваш код, модифицирует его (или включит его в состав своей программы), он обязан будет следовать лицензии GPL — то есть в случае распространения такой модифицированной программы, предоставлять своим получателям исходники на тех же условиях. Но это не означает, например, что какая-нибудь компания не сможет взять Ваш движок, модифицировать его для своих нужд и установить на своем сайте (не распространяя никуда дальше) — при этом не открывая исходников своих модификаций. (С этой проблемой пытаются бороться разработчики AGPL, но юридические основания этой лицензии для меня лично несколько туманны.)
Слово «коммерческий» в данном контексте лучше вообще избегать, поскольку оно вводит в заблуждение. Например, использование GPL'ного движка на коммерческом сайте — это вполне коммерческое использование. Имеет смысл также почитать GPL FAQ.
Насчет ссылки — на мой взгляд, гораздо разумнее действительно передалть требование в просьбу, как это обычно и делается. Чаще всего веб-разработчики такие просьбы уважают, как из чувства благодарности, так и из чисто прагматических соображений — в случае возникновения проблем естественно обратиться к Вам за помощью, и не менее естественно, что в случае отсутствия такой ссылки, Вы (или сообщество разработчиков) вряд ли захотите им помогать.
На мой взгляд, будет очень здорово, если появится еще один свободный движок под свободной лицензией — потенциал есть! :)
«Проект распространяется под лицензией GPLv2(GNU General Public License), т.е. использовать его в коммерческих целях запрещено. Дополнительное требование для тех, кто использует движок LiveStreet: необходимо присутствие ссылки на главной странице, ведущей на сайт livestreet.ru»
Я прошу прощения, но Вы, видимо, не вполне понимаете, что такое лицензия GPL — она не регламентирует «использование» программы, а лишь копирование, распространение и модификацию (в точности те действия, которые контролируются законодательством об авторском праве), и не ограничивает эти действия «некоммерческими целями». (Напротив, свободное ПО, распространяемое под GPL, очень активно используется коммерчески, и это — одна из составляющих его успеха.) Ограничить же использование Вы вообще никак не можете, ибо оно не покрывается авторским правом.
Также требование ссылки, ведущей на главный сайт, противоречит условиям GPL (если быть точнее — накладывает дополнительные условия поверх GPL, и делает Вашу программу фактически распространяемой не под GPL, а на условиях «GPL + доп. требования», которые не совместимы с GPL — то есть, например, другие разработчики не смогут заимствовать Ваш код в GPL'ные продукты).
Основной деструктивный эффект здесь достигается на том, что если анализровать вневикипедийную информацию, то отсутствие добрых намерений очевидно сразу. И для тех людей которым оно очевидно (скажем, для объекта нападок), работать совместно с таким участником — практически невозможно, причем уже сейчас. А меры можно будет принять, исходя из доктрины «невидимости внешних ресурсов» — только через многие месяцы. А цели тролля к тому моменту уже будут достигнуты — участник выжит из проекта.
Насчет совместной дистрибуции — вопрос более интересный. Я так понимаю, что единственные правообладатели, чьи права могут нарушаться при такой совместной дистрибуции — это права авторов linux kernel. Насколько я понимаю, они смотрят на это «сквозь пальцы» (в отличие от, например, распространения kernel в различных устройствах при несоблюдении устройств — см. gpl-violations.org). Что касается «наездов» на вендоров GNU/Linux-дистрибутивов — я помню какую-то мутную историю, связанную с этим, но, кажется, тот человек, который пытался призвать к ответственности кого-то из вендоров, на самом деле никаких прав это делать не имел.
В то же время, описанная автором исходного поста ситуация явно иная: здесь разработчики исходной библиотеки кровно заинтересованы в том, чтобы условия GPL выполнялись максимально строго, и скорее всего, если автор сделает то, что им задумано (основательно порушив бизнес-модель исходного разработчика), я думаю, что это явно не останется незамеченным со стороны исходных девелоперов.
Замечу, что как я писал выше, динамическую линковку с какими-либо библиотеками FSF считает созданием «производной работы». См. также релевантные вопросы в GPL FAQ: О GPL-ных плагинах, О GPL-библиотеках.
Я думаю, что основной вопрос, который здесь следует задать, звучит так: можете ли вы написать сторонее приложение (которое вы не собираетесь лицензировать под GPL), не имея информации о внутреннем устройстве исходной GPL-ной библиотеки, и опираясь, скажем, только на спецификации публично-доступных протоколов? (Понятно, что я могу написать веб-браузер, не заглядывая во внутреннее устройство IIS, просто глядя на спецификации HTTP, поэтому мой браузер заведомо не будет производной работой с IIS; IIS в данном случае можно будет заменить на Apache или на что угодно еще.) Если ответ отрицательный, то я полагаю, что получившийся гибрид может считаться созданием производной работой с исходной библиотеки и не может распространяться под лицензией, отличной от GPL.
Более того: даже если написание такой «тройки» программ может быть и легальным, но совместное распространение может оказаться нелегальным. Этот вопрос необходимо изучить отдельно.
В любом случае, наверное, имеет смысл посоветоваться с каким-нибудь юристом, разбирающимся в вопросах свободных лицензий. Правда, боюсь, что в России таковых нет или почти нет.
Длинный ответ: на чем вы будете собирать эту систему? Чтобы ее собрать, нужно собрать toolchain (набор инструментов для сборки). А на чем его собрать?..
Собственно, люди в CentOS и подобных проектах именно этим и занимаются. Как рассказывали когда-то представители ScientificLinux на Open Source Forum, приходится пересобирать систему по три раза…
Другое дело, что если Вы позволяете скачать бинарник свободно кому угодно, то обязаны также кому угодно раскрыть и исходник. Все так и делают обычно.
То есть я бы предпочел камеру с вдвое меньшим числом мегапикселей, если на ней смогу снимать с вдвое большим ISO.
Слово «коммерческий» в данном контексте лучше вообще избегать, поскольку оно вводит в заблуждение. Например, использование GPL'ного движка на коммерческом сайте — это вполне коммерческое использование. Имеет смысл также почитать GPL FAQ.
Насчет ссылки — на мой взгляд, гораздо разумнее действительно передалть требование в просьбу, как это обычно и делается. Чаще всего веб-разработчики такие просьбы уважают, как из чувства благодарности, так и из чисто прагматических соображений — в случае возникновения проблем естественно обратиться к Вам за помощью, и не менее естественно, что в случае отсутствия такой ссылки, Вы (или сообщество разработчиков) вряд ли захотите им помогать.
На мой взгляд, будет очень здорово, если появится еще один свободный движок под свободной лицензией — потенциал есть! :)
Я прошу прощения, но Вы, видимо, не вполне понимаете, что такое лицензия GPL — она не регламентирует «использование» программы, а лишь копирование, распространение и модификацию (в точности те действия, которые контролируются законодательством об авторском праве), и не ограничивает эти действия «некоммерческими целями». (Напротив, свободное ПО, распространяемое под GPL, очень активно используется коммерчески, и это — одна из составляющих его успеха.) Ограничить же использование Вы вообще никак не можете, ибо оно не покрывается авторским правом.
Также требование ссылки, ведущей на главный сайт, противоречит условиям GPL (если быть точнее — накладывает дополнительные условия поверх GPL, и делает Вашу программу фактически распространяемой не под GPL, а на условиях «GPL + доп. требования», которые не совместимы с GPL — то есть, например, другие разработчики не смогут заимствовать Ваш код в GPL'ные продукты).