«Что написано пером,  не вырубишь топором»

GNU GPL and Penguin

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

По мере роста использования свободного программного обеспечения, в том числе и в коммерческих целях, возникает потребность уделять больше внимания особенностям  применения лицензии GPL.

Данное практическое руководство представляет собой подробный и достаточно ясный документ, который позволит компаниям, использующим в своих разработках GPL СПО, избежать возникающих рисков, которые часто неверно квалифицируются за счет неправомерных аналогий с проприетарным ПО.

Документ разъясняет базовые положения GNU General Public Licence и других совместимых лицензий, предоставляя практические рекомендации компаниям как не выходить за рамки лицензионного соглашения.

Чтобы помочь избежать нарушения GPL авторы приводят примеры правильно построенного процесса разработки ПО и его приобретения с позиции свободных лицензий. Так же детально описываются наиболее уместные действия для компании, на которую создателями ПО подана жалоба о несоблюдении GPL. SFLC надеется, что публикация подобного учебника снизит количество нарушений свободных лицензий и предотвратит негативные последствия в случае, если нарушение все-таки возникло.

Вашему вниманию предлагается неполный перевод «A Practical Guide to GPL Compliance» 2008

Переводчики, возможно не все : spiritedflow, ykuznesov, O90, Softy,  Werehuman. Последние изменения в переводе сделаны 6 лет назад.

«Практическое руководство по соответствию GPL»

1. Введение

Это руководство расскажет, как эффективно добиться соответствия GNU General Public License (GPL) и другим связанным лицензиям. В соответствии с философией Software Freedom Law Center (SFLC) коллективной помощи сообществу по соблюдению GPL, это руководство главным образом фокусируется на том, как избежать уступок и как минимизировать негативную отдачу во время принуждения. Документ вводит и объясняет базовые юридические понятия, имеющие отношение к GPL и к принуждению к ее выполнению со стороны правообладателей. Он также выделяет те практики разработки и методы, которые ведут к лучшему соответствию GPL. В конце будут рекомендации, как правильнее ответить владельцам прав после нарушения.

2. Предыстория

Первые преследования за нарушения GPL начались сразу после того, как GPL была написана Ричардом Столманом (Richard Stallman) в 1989 г., и состояли из неформальных действиий сообщества, часто в публичной сети Usenet. [1] В последующие десять лет Free Software Foundation (FSF), которое владело правами на большое количество GNU-программ, было единственным заметным участником, активно защищающим свои GPL-права от имени и в пользу сообщества разработчиков свободного (Libre), а также открытого (FOSS) программного обеспечения. Действия FSF по защите прав были, по большей части, приватным процессом. FSF частным образом связывалась с нарушителями и помогала им обеспечить соотвествие лицензии. Большинство нарушителей преследовались именно таким образом до начала 2000-ых годов.

К этому времени основанные на Linux системы стали довольно распространненными, в частности во встраиваемых системах, таких как, например, беспроводные маршрутизаторы. В этот период публичные насмешки над нарушителями в прессе и сети Интернет стали дополнительным фактором в усиливающимся давлении на компании к соблюдению лицензии. А в 2003 году FSF создала организацию GPL Compliance Lab, увеличив масштаб действий и построив сообщество ‘коалиций’ для того, чтобы помогать правообладателям путём переговоров улаживать вопросы вместе с нарушителями. К началу 2004 года, Гарольд Вельте (Harald Welte) взял на себя задачу по консолидации общих усилий и запустил проект gpl-violations.org — сайт, а также список рассылки для сбора информации о нарушениях лицензии GPL. На основе полученных таким образом данных Вельте подал и успешно довел до конца много исков в Европе.

В 2007 г. SFLC оформила первый в истории авторского права США иск о нарушении GPL. Несмотря на то, что этот и последующие иски, отправленные SFLC ради защиты своих клиентов, были достаточно публичными, SFLC разрешила гораздо больше других подобных ситуаций через частную переписку с нарушителями. Пока мы занимались тем, что помогали индивидуальным компаниям прийти к соответствию GPL, нам встретилось множество нарушений вытекающих из проблем, которые можно было бы предотвратить: неадекватное внимание к лицензированию используемого ПО, непонимание условий GPL, и слабое взаимодействие между разработчиками и их начальством. В этом документе мы опишем эти проблемы и дадим рекомендации, как помочь корпоративным пользователям FOSS пересмотреть свое отношение к GPL-программам и избежать будущих нарушений.

SFLC продолжает свои действия по защите большого количества своих клиентов, которые распространяют свое ПО под GPL, LGPL и другими «копилефт»-лицензиями. Делая это, мы обнаружили, что большинство нарушений происходят из нескольких широкораспространенных ошибок, которые по большей части легко можно было бы избежать. Мы надеемся научить общество коммерческих распространителей и перекупщиков, как, в первую очередь, избежать нарушений, и как уместно и адекватно ответить, если все же условия лицензии были нарушены.

3. Наилучшие способы как избежать распространенных нарушений

В отличие от очень лояльных FOSS лицензий (как ISC), которые обычно только требуют сохранить копирайты, GPL устанавливает ряд важных ограничений на лицензируемых . Эти требования тщательно спланированы так, чтобы поддержать определенные ценности и стандарты сообщества свободного ПО. Не смотря на то, что требования GPL могут показаться противоестесственными для тех, кто больше привык к проприетарным лицензиям, в сравнении же термины GPL более прозрачны и удобны для лицензируемых. На самом деле они упрощают шаги к согласию после нарушения.

Нарушения GPL часто вызваны или состоят из неудачных попыток последовать советам по интеграции GPL-компонент во внутреннюю среду разработки ПО. В этом разделе вы найдете несколько лучших рекомендаций по выбору инструментов, по способам интеграции и распространения, которые вдохновлены и согласуются с методам FOSS. Мы советуем компаниям разобраться с этими советами прежде, чем начать создание продукта, основанного на GPL-программах.

3.1 Оцените пригодность лицензии

Политические споры вокруг GPL часто сосредотачиваются на «копилефт» требованиях. И в самом деле, эта лицензия создавалась преимущественно ради них. Большинство компаний, которые добавляют нетривиальные функции (что-то больше, чем простое портирование или исправление ошибок) в GPL-программы, и поэтому попадают под эти требования, уже хорошо осведомлены об обязательствах, которые они накладывают. [3]

Тем не менее, судя по нашему опыту в преследовании нарушителей GPL, распространители не сильно стремятся к совместимости с положениями копилефт. Это вдвойне верно для распространителей встраиваемых систем. Вместо этого, распространяемые GPL-системы, с которыми мы сталкивались, обычно представляют собой полную операционную систему, включающую компоненты под GPL (такие как Linux, BusyBox) и компоненты под LGPL (например, GNU C Library). Иногда эти программы были исправлены или слегка улучшены с помощью прямого изменения исходного кода, что недвусмысленно говорит о том, что речь идет о производной работе. Наряду с этими программами компании часто распространяют полностью независимые, проприетарные программы, разработанные с нуля, и созданные для того, чтобы работать в FOSS операционной системе, но не объединяться с, линковаться с или каким-либо другим образом наследоваться от GPL-компонент или изменять их. [4] В последнем случае, когда была проведена несомненно отдельная работа, никаких производных работ не было создано. Оставшийся мизер ситуаций, которые не попадают ни в одну из этих двух категорий, и поэтому вызывают более сложные вопросы относительно производных работ, требуют детального, зависимого от фактов, анализа и не будут рассмотрены в этом документе.

Однако, большинству компаний, обвиненных в нарушениях, не хватает понимания того, как соблюдать лицензию даже в простой ситуации. Этот документ предлагает эти основные необходимые знания, которые подойдут для большинства ситуаций. Для ответов на более редкие и более сложные юридические вопросы такие, как является ли ваша разработка производной работой от какой-нибудь копилефт-программы, обратитесь к юристу. [5]

В дальнейшем предполагается, что вы уже определились, какая «работа» затрагивается лицензией, и что любые компоненты не под GPL (например, приложения, написанные от начала до конца вашими разработчиками, которые просто работают в операционной системе, основанной на Linux), распространяемые вместе с GPL-программами, являются отдельной работой с точки зрения закона об авторском праве. В этом случае GPL требует от вас предоставить полный соответствующий исходный код для всех GPL-частей и всех модификаций к ним, но не для независимых проприетарных приложений. Процедуры, описанные в этом документе, относятся к этому типичному сценарию.

 

 

 3.2 Мониторинг комплектации ПО

Разработчики ПО должны иметь возможность улучшения и встраивания полезного функционала в ваш продукт. При этом, вместе с этой возможностью должны быть введены правила и процедуры отчетности, чтобы быть уверенным, что вы точно знаете какое ПО было протестировано или встроено в ваш продукт.

Компании, с которыми мы связывались насчет нарушений GPL, часто отвечают: «Мы не знали, что там есть что-то под GPL». Такой ответ указывает на ошибку в процессе приобретении и внедрении ПО. Интеграция стороннего проприетарного ПО обычно требует формального соглашения и участия руководства и юристов перед тем, как разработчики смогут использовать программу. Совсем другая ситуация с GPL. Ваши разработчики часто достают и внедряют FOSS без вмешательства других. Простота приобретения, однако, не означает, что надзор больше не нужен. Также как ваши юристы и руководящий состав согласует условия для внедрения любого проприетарного ПО, они должны учавствовать во всех решениях относительно FOSS частей в вашем продукте.

Простые технические правила помогут обеспечить прочную основу для интеграции FOSS. Пусть ваши разработчики отправляю электронное письмо на определенный адрес с описанием каждой новой FOSS компоненты, которую они добавили в систему, и заставьте их кратко описать, каким образом они были включены в продукт. Убедитесь, что они используют какую-нибудь систему контроля версий, и сохраняют оригинальные версии всех программ в своей ветке (vendor branch) или похожем механизме, где можно легко отделить чужой код от своих локальных изменений.

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

3.3 Отслеживайте изменения и релизы

Как будет объяснено в деталях ниже, включение полного и согласованного исходного кода в любые дистрибутивы (комплекты поставки) которые были сделаны с использованием ПО лицензированного GPL — это наиболее важная часть процесса поддержания соотвествия GPL. Первостепенно понимание что исходные коды создают данный бинарный дистрибутив.

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

3.4 Избегайте специалистов по сборке

Во многих программных проектах существует всего один или несколько членов команды разработчиков, знающих, как построить законченный продукт. Такая централизация не только создаёт проблему «незаменимых» кадров, но и может привести к проблемам совместимости с GPL, которая требует предоставления сборочных скриптов.

Избегайте полагаться на специалиста по сборке, единственного члена команды, который может построить конечный продукт. Убедитесь, что процесс сборки хорошо специфицирован. Обучите каждого разработчика выполнению сборки бинарного кода, включая (в случае встроенного ПО) создание финального образа прошивки, который будет передаваться заказчику. Требуйте от разработчиков использовать систему контроля версий для процесса сборки. Установите правило, что добавление новых компонент к системе без адекватных инструкций по сборке (или лучше скриптов) недопустимо.

4 Детали распространения

В этом разделе мы объясняем специфические требования к распространению ПО под лицензией GPL. Помните, что этот раздел часто ссылается на специфические меры предосторожности и языковые особенности в GPLv2 и GPLv3. Возможно будет полезно держать открытой копию каждой из этих лицензий в процессе чтения этого раздела.

4.1 Права на распространение бинарного кода

Различные версии GPL являются копирайт-лицензиями, дающими право использовать ПО таким образом, каким его запрещают использовать законы об авторском праве. Это право является требованием § 6 в GPL. Данный раздел рассматривает требования (как в GPLv2, так и в GPLv3), которые должны быть выполнены в случае распространения GPL-программ в бинарной форме (например, исполняемые и объектные файлы), которые типичны для включения в другие программы. Так как бинарные приложения получены из оригинального исходного кода программы, то вам нужны права из копирайта для их распространения. В § 3 в GPLv2 и в § 6 в GPLv3 описаны права и условия, связанные с распространением GPL-программ в бинарной форме.

Разделы о распространении GPL-программ в бинарной форме предлагают некоторые методы, каждый из которых мы будем рассматривать в отдельности. Каждый вариант ссылается на «Соответственный Код» — код для бинарного распространения, включающий в себя исходный код, из которого бинарный элемент был собран. Это сокращенное и упрощенное определение является достаточным для обсуждения распространения ПО в бинарной форме в данном разделе, но вы можете вернуться к данному разделу после прочтения полного обсуждения «Соответственного Кода», который представлен в § 4.2

4.1.1 Вариант (а): Исходный код вместе с бинарным

GPLv2 § 3(a) и v3 § 6(a) являет собой простейший вариант, предусматривающий распространение ПО: включать Соответственный Код в каждый бинарный пакет. Остальные варианты относительно просты для исполнения, но этот вариант всегда позволяет минимизировать потенциальные проблемы, вы автоматически выполняете требования GPL во время распространения ПО, потому что вы распространяете Соответственный Код вместе с бинарным. Другие методы не всегда обладают таким свойством, поэтому мы настоятельно рекомендуем вам использовать именно этот вариант. Если вы не согласны, то после распространения бинарного кода вы еще долго будете обязаны следить за своими обязательствами.

Обеспечить соответствие этому варианту очень просто: если вы распространяете продукт, который включает бинарные копии ПО лицензированного GPL (например, в виде прошивки, или на ЖД, CD, или на любом другом долговременном носителе информации), вы можете расположить Соответственный Код вместе с бинарным кодом. Или вы можете вложить исходный код на CD или на ином носителе информации в комплект поставки продукта.

GPLv2 ссылается на различные способы храниения информации как на » традиционно используемые носители информации для обмена ПО». Сегодня Интернет стал превосходным стредством распостранения ПО, там, где доступны быстрые соедиения к сети, но GPLv2 была написана когда загрузка ПО через сеть не была практична (или была невозможна). Это условие не изменилось со времени публикации GPLv2 для большей части земного шара, и Интернет все еще не может выступать в роли » традиционно используемого носителя информации для обмена ПО». GPLv3 утоняет этот момент требованием, что исходный код должен быть » записан на долговременном носителе информации традиционно используемом для обмена ПО». Выше сказанное подтверждает, что вариант а) требует от распространителей бинарного кода предоставления исходного кода на реальном носителе.

Обратите внимание, хотя выбор варианта а) требует распространения на реальной носителе информации, дополнительное распространение через Интернет очень полезно. Детали этого замечания будут обсуждаться в п.4.1.2

4.1.2 Вариант b) Предложение

Многие производители предпочитают при распостранении кода комплектовать бинарный код предложением получить или загрузить исходный код, вместо включения его в комплект поставки. Этот вариант предпочтителен, когда стоимость комплекта поставки сравнима со стоимостью носителя информации с исходным кодом. Например, в случае поставки встроенных систем с недостаточным для хранения исходного кода объемом ПЗУ, этот вариант позволяет не включать в комплект поставки CD вместо руководства или других печатных материалов.

 

Однако, этот вариант сильно увеличивает длительность ваших обязательств. Предложение на получение исходного кода должно быть действительно в течении трех лет с момента окончания поставок бинарного кода (в соответствии с GPLv2) или с момента окончания поставок бинарного кода или его частей (в соответствии с GPLv3). Ваша система обслуживания заказов на получение исходного кода должна функционировать намного дольше жизненного цикла продукта.

Дополнительно, если вы вынуждены соответствовать требованиям GPLv2, вы не можете использовать сетевые сервисы для предоставления исходного кода. В соответствии с GPLv2, исходный код может быть предоставлен только на реальном носителе. Обычно это подразумевает, что вы должны продолжать выпускать актуальные «CD с исходным кодом» в течении нескольких лет после завершения жизненного цикла продукта.

В соответствии с GPLv2, в предложении на получение исходного кода, возможно и рекомендуется предоставлять Интернет-ссылку для загрузки исходного кода в дополнение к предложению предоставить исходный код на реальном носителе. Эта практика позволяет быстро получать исходный код там, где есть быстрые сетевые соединения и обычно уменьшает количество запросов на реальном носителе. (GPLv3 § 6(b) разрешает распространение исходного кода исключительно через Интернет, без использования реальных носителей. Данный пункт будет обсуждаться в конце этой главы.)

Ниже приведено рекомендуемое предложение на получение исходного кода в соответствии с GPLv2 (а также GPLv3), которое вы можете добавить к печатным материалам, предоставляемых месте с бинарным кодом:

Данный продукт содержит ПО лицензированное GPL. Копия этой лицензии приведена в данном документе на стр. X. Вы можете получить у нас полный Соотвественный исходный Код в течении трех лет после последней поставки этого продукта, т.е. до 2011-08-01. Для этого вы должны выполнить денежный перевод или прислать чек на 5 долларов США по адресу:

Отдел вопросов лицензирования GPL
Ваша компания
Ваш Город, Страна, Почтовый индекс

Пожалуйста, не забудьте указать цель платежа «исходный код для продукта Y»

Вы можете загрузить копию исходного кода по ссылке http :// www.example.com/sources/Y/.

Предложение действительно для всех получателей данной информации.

 

Существует несколько важных замечаний об описанном выше предложении. Первое, оно включает оплату накладных расходов. GPLv2 разрешает «взимать оплату не превышающую накладных расходов на предоставление исходного кода». Эта оплата должна быть разумной. Если ваши расходы на изготовление копии исходного кода и почтовые расходы на отправку CD превышают 10 долларов США, вам следует попытаться уменьшить эти издержки. Не в ваших интересах заставлять переплачивать сообщество, т.к. попытки получения прибыли на поставках исходного кода обычно вызывают иски о нарушении условий лицензии.

Во-вторых, последняя строка предложения (на получение исходного кода) обозначает, что кто угодно может потребовать исходный код, в соответствии с v2 § 3(b), которое обязывает «предоставлять третьим лицам» копии Соответственного Кода. GPLv3 имеет сходное требование, которое обязывает предоставлять исходный код «всем, кто получил бинарный код». Требования, описанные в v2 § 3(c) и v3 § 6(c), позволяют не-коммерческим компаниям, занимающимся распространением бинарного кода, распространять предложения на получение исходного кода. Таким образом, эти предложения должны быть доступны не только для конечных пользователей, но и для кого угодно, кто получил копию бинарного кода от них. Многие распространители упускают это требование и ошибочно предполагают, что они могут обслуживать запросы на получение исходного кожа только от конечных пользователей.

[… не переведено …]

Описанная ситуация демонстрирует, что предложение на получение исходного кода часто плохой выбор для продуктов, которые ваши клиенты будут распространять. Если вы включаете исходный код в ваши продукты, то ваш комплект поставки для вашего клиента соответствует условиям лицензии, и их (неизменный) комплект поставки для их клиентов тоже соответствует условиям лицензии, потому что оба комплекта содержат исходный код. Если вы включаете только предложение на получение исходного кода, то ваш комплект поставки будет соответствовать условиям лицензии, но комплект поставки клиента не «наследует» это соответствие, потому что он (клиент) не сможет включить ваше предложение (на получение исходного кода) к своему комплекту поставки.

[… не переведено …]

Неприемлемо использовать вариант b) по причине неготовности Соответствующего Кода. Мы встречали (существуют) компании которые выбирают этот вариант только потому что проще написать предложение на получение исходного кода, хотя предоставить исходный код будет затруднительно из-за плохо организованного процесса разработки. Предложение на получение исходного кода на должно использоваться как временное (stop-gap) решение для компаний которые торопятся вывести на рынок продукт нарушающий права. В отношении вас может быть инициирован иск, если вы распостраняете предложение на получение исходного кода, но не готовы немедленно предоставить исходный код.

4.1.3 Вариант c) Некоммерческое предложение

Как было обсуждено в последней главе, параграфы GPLv2 § 3(c) и GPLv3 § 6(c) применимы только для некоммерческого использования и, соответственно, не применимы для коммерческого распространения ПО лицензированного GPL. Поэтому компании, распространяющие ПО предоставленное другим производителем, должны распространять собственное предложение на получение исходного кода и не могут просто передавать запросы на исходный код к этому производителю. Детальное обсуждение этого требования ниже в главе 7.2.

4.1.4 Параграф 6(d) в GPLv3: Распостранение через Интернет

В соответствии с GPLv2 ваши возможности по предоставлению Соответственного Кода ограничивались § 3(c). Но даже для GPLv2, распространение через Интернет широко использовалось и, в основном, считалось законным, хотя оно не было прямо разрешено. Как было объяснено ранее, это упущение обусловлено историческими причинами: в 1991 года, когда была написана v2, распространениее через Интернет было исключением из правила. Существовали FTP серверы, но в основном ПО распространялось на CD или лентах. GPLv2 явно не предполагала, что бинарный код будет распространяться через Интернет и, в основном, предполагала что бинарный код будет распространяться на реальном носителе. Напротив, GPLv3 § 6(d) прямо разрешает распространение через Интернет, которое рассматривалось сообществом в случае v2, приемлемым, но, строго говоря, не разрешенным.

[… не переведено …]

4.1.5 Параграф 6(e) в GPLv3: Торренты

Пиринговые сети возникли после GPLv2 и не попадают не под один способ распространения исходного кода, описанного в v2. GPLv3 § 6(e) прямо разрешает распространять исходный и бинарный коды через пиринговые сети, даже если это единственный способ распространения. Однако, нужно учесть, что не прямые (non-peer-to-peer) получатели бинарного кода не смогут получить исходный код, распространяемый для прямых (peer-to-peer) получателей. Т.е. вы должны быть уверены, что и исходный, и бинарный коды присутствуют в первичном комплекте поставки для пиринговой сети.

В большинстве исков компании-ответчики не реализуют процедуры описанные в гл. 3 данных рекомендаций и не предоставлют исходный код ни каким образом. Чтобы выполнить условия иска, им приходится получать исходный код из бинарного. С другой стороны, наши рекомендации из гл.3 нацелены на упрощение создания Соответственного Кода с самого начала. Таким образом, будет проще достичь соотвествия условиям лицензии, если следовать этим инструкциям в процессе разработки ПО. Иначе вам может потребоваться выполнить большой объем работ по востанновлению исходного кода.

[… не переведено …]

GPL не содержит условий которые требуют распостранять используемый комилятор. Включение компилятора для упрощения сборки бинарного кода из исходного, поощряется, но не требуется. Описание Соотвественного Кода — и в GPLv2, и в GPLv3 — не включает в себя компилятор, но предполагает включение средств типа makefile-файлов, скриптов для построения и сборки ПО.

[… не переведено …]

Сноски.

1. Как пример, публичное осуждение попытки NeXT сделать Objective-C фронтенд к GCC проприетарным.

2. Этот документ направлен на совместимость с GPLv2, GPLv3, LGPLv2, и LGPLv3. Советы по избежанию распространенных ошибок слабо различаются для этих четырех лицензий. Параграф 7.1 рассматривает ключевые различия между GPL и LGPL.

3. Было много юридических дискуссий о копилефте и производных работах. На практике, однако, этот вопрос не имеет отношения к большинству компаний, распространяющих GPL-программы.

4. Тем не менее эти программы часто комбинируют с библиотеками под лицензией LGPL. Детально это обсуждается в параграфе 7.1.

5. Если вам нужно больше информации о применении понятия «производная работа» в программном обеспечении, обратитесь к детальному юридическому обсуждению в статье нашего коллеги Дена Равичера (Dan Ravicher) «Software Derivative Work: A Circuit Dependent Determination»

[… не переведено …]

8 «Linux» относится только к ядру, а не ко всей системе целиком.

[… не переведено …]

10 Обсуждается тот факт, что iPhone, устройство созданное в основном для ограничения пользовательской свободы модифицировать его, был разблокирован и модифицирован в течение 48 часов после его выпуска.