stringtranslate.com

Лицензия с открытым исходным кодом

Круговая диаграмма отображает наиболее часто используемые лицензии с открытым исходным кодом: Apache (30%), MIT (26%), GPL (18%), BSD (8%), LGPL (3%), MPL (2%) и оставшиеся 13% лицензий с долей рынка менее 1% каждая.
Популярные лицензии с открытым исходным кодом включают Apache License , MIT License , GNU General Public License (GPL), BSD Licenses , GNU Lesser General Public License (LGPL) и Mozilla Public License (MPL).

Лицензии с открытым исходным кодом — это лицензии на программное обеспечение , которые позволяют использовать, изменять и распространять контент. Они способствуют разработке свободного и открытого программного обеспечения (FOSS). Законы об интеллектуальной собственности (ИС) ограничивают изменение и распространение творческих работ. Лицензии с открытым исходным кодом используют эти существующие правовые структуры для обратной цели. Они предоставляют получателю права использовать программное обеспечение, изучать исходный код , изменять его и распространять модификации. Эти критерии изложены в Определении открытого исходного кода .

После 1980 года Соединенные Штаты начали рассматривать программное обеспечение как литературное произведение, защищенное законом об авторском праве. Ричард Столлман основал движение за свободное программное обеспечение в ответ на рост проприетарного программного обеспечения . Термин «открытый исходный код» использовался Инициативой открытого исходного кода (OSI), основанной разработчиками свободного программного обеспечения Брюсом Перенсом и Эриком С. Рэймондом . «Открытый исходный код» подчеркивает сильные стороны модели открытой разработки, а не свободы программного обеспечения. Хотя цели, стоящие за этими терминами, различны, лицензии с открытым исходным кодом и лицензии свободного программного обеспечения описывают один и тот же тип лицензий. [1]

Две основные категории лицензий с открытым исходным кодом — разрешительные и копилефт . Обе предоставляют разрешение на изменение и распространение программного обеспечения. Обычно они требуют указания авторства и отказа от ответственности . Разрешительные лицензии исходят из академических кругов. Лицензии копилефт исходят из движения за свободное программное обеспечение. Лицензии копилефт требуют , чтобы производные работы распространялись вместе с исходным кодом и по аналогичной лицензии. С середины 2000-х годов суды во многих странах поддержали условия обоих типов лицензий. Разработчики программного обеспечения подали иски как о нарушении авторских прав и как о нарушении контракта.

Фон

Ученый-юрист Эбен Моглен об истории авторского права

Интеллектуальная собственность (ИС) — это правовая категория, которая рассматривает творческий результат как собственность, сравнимую с частной собственностью . [2] Правовые системы предоставляют владельцу ИС право ограничивать доступ многими способами. [3] Владельцы могут продавать, сдавать в аренду, дарить или лицензировать свою собственность. [4] Различные типы права ИС охватывают программное обеспечение, включая товарные знаки , патенты и авторские права . [4]

Большинство стран, включая Соединенные Штаты (США), создали законы об авторском праве в соответствии с Бернской конвенцией . [5] Эти законы присваивают авторское право всякий раз, когда произведение выпущено в любом фиксированном формате. [6] Согласно закону США об авторском праве, первоначальный выпуск считается оригинальной работой . [7] Создатель или его работодатель владеет авторским правом на это оригинальное произведение и, следовательно, имеет исключительное право делать копии, выпускать измененные версии, распространять копии, публично исполнять или демонстрировать произведение публично. Измененные версии оригинального произведения являются производными произведениями . [8] Когда создатель изменяет существующее произведение, он владеет авторским правом на свои модификации. [9] Если оригинальное произведение не находилось в общественном достоянии, производное произведение может распространяться только с разрешения каждого владельца авторских прав. [10]

В 1980 году правительство США внесло поправки в закон, чтобы рассматривать программное обеспечение как литературное произведение. Программное обеспечение, выпущенное после этого момента, ограничивалось законами об интеллектуальной собственности. [11] В то время американский активист и программист Ричард Столлман работал аспирантом в Лаборатории компьютерных наук и искусственного интеллекта Массачусетского технологического института . Столлман стал свидетелем раздробленности среди разработчиков программного обеспечения. Он обвинил в этом распространение проприетарного программного обеспечения и закрытые модели разработки. Чтобы противостоять этим тенденциям, Столлман основал движение за свободное программное обеспечение . [12] В течение 1980-х годов он начал проект GNU по созданию свободной операционной системы, писал эссе о свободе, основал Фонд свободного программного обеспечения (FSF) и написал несколько лицензий на свободное программное обеспечение. [13] FSF использовал существующие законы об интеллектуальной собственности для противоположной своей предполагаемой цели ограничения. Вместо того чтобы налагать ограничения, свободное программное обеспечение явно предоставляло свободы получателю. [14]

Фотография Брюса Перенса на конференции
Брюс Перенс , автор Open Source Definition

В 90-х годах термин «open source» был придуман как альтернативное обозначение свободного программного обеспечения, и были разработаны конкретные критерии для определения того, какие лицензии охватывают свободное и открытое программное обеспечение. [15] [16] Два активных члена сообщества свободного программного обеспечения, Брюс Перенс и Эрик С. Рэймонд , основали Open Source Initiative (OSI). [17] В Debian Перенс предложил Debian Free Software Guidelines (DFSG). [18] DFSG были разработаны для предоставления более конкретного и объективного стандарта для FOSS, который Debian будет размещать в своих репозиториях. [19] OSI принял DSFG и использовал его в качестве основы для своего Open Source Definition. [20] Free Software Foundation поддерживает конкурирующий набор критериев, Free Software Definition. [21] Исторически эти три организации и их наборы критериев были известными авторитетами в определении того, охватывает ли лицензия свободное и открытое программное обеспечение. [22] Существует значительное разнообразие между отдельными лицензиями, но мало различий между конкурирующими определениями. [16] Каждое из трех определений требует, чтобы лица, получающие защищенное программное обеспечение, имели возможность использовать, изменять и распространять защищенную работу. [23]

Эрик С. Рэймонд был сторонником термина « открытый исходный код » вместо «свободного программного обеспечения». Он считал, что открытый исходный код более привлекателен для бизнеса и больше отражает ощутимые преимущества разработки FOSS. Одной из целей Рэймонда было расширение существующего сообщества хакеров за счет включения крупных коммерческих разработчиков. [24] В книге «Собор и базар» Рэймонд сравнил разработку с открытым исходным кодом с базаром , открытым публичным рынком. [25] Он утверждал, что помимо этики, открытая модель предоставляет преимущества, которые не может воспроизвести проприетарное программное обеспечение. [26] [27] Рэймонд уделял большое внимание обратной связи , тестированию и отчетам об ошибках . [28] Он противопоставлял проприетарную модель, в которой небольшие группы скрытных работников выполняли эту работу, разработке Linux, в которой группа тестировщиков потенциально включала весь мир. [29] Он резюмировал эту силу следующим образом: «При достаточном количестве глаз все ошибки неглубоки». [30] OSI удалось предоставить разработку с открытым исходным кодом корпоративным разработчикам, включая Sun Microsystems, IBM , Netscape, Mozilla , Apache , Apple Inc., Microsoft и Nokia. Эти компании выпустили код по существующим лицензиям и разработали свои собственные для одобрения OSI. [31] [32]

Типы

Лицензии с открытым исходным кодом подразделяются на лицензии с копилефтом и разрешительные . [33] Лицензии с копилефтом требуют, чтобы производные работы включали исходный код под аналогичной лицензией. Разрешительные лицензии этого не требуют, и поэтому код может использоваться в проприетарном программном обеспечении. Копилефт можно далее разделить на сильный и слабый в зависимости от того, определяют ли они производные работы широко или узко. [34] [35]

Лицензии фокусируются на авторском праве, но код также покрывается другими формами ИС. [36] Основные лицензии с открытым исходным кодом, написанные с конца 1990-х годов, содержат патентные гранты. Эти патентные гранты с открытым исходным кодом охватывают патенты, принадлежащие разработчикам. [37] Патенты на программное обеспечение охватывают идеи и, а не конкретную реализацию, охватывают любую реализацию заявки . Патентные заявки дают владельцу право исключать других из создания, использования, продажи или импорта продуктов, основанных на идее. Поскольку патенты предоставляют право исключать, а не право создавать, можно иметь патент на идею, но все равно не иметь возможности юридически реализовать ее, если изобретение опирается на другую запатентованную идею. Таким образом, патентные гранты с открытым исходным кодом могут предлагать разрешение только из охваченных патентов. Они не могут гарантировать, что третья сторона не запатентовала какие-либо концепции, воплощенные в коде. [36] Более старые разрешительные лицензии не обсуждают патенты напрямую и предлагают только неявные патентные гранты в своих предложениях использовать или продавать охваченный материал. [38] Более новые лицензии с копилефтом и лицензия Apache 2004 года предлагают явные патентные гранты и ограниченную защиту от патентных судебных разбирательств. [39] Эти положения о возмездии за патенты защищают разработчиков, прекращая гранты для любой стороны, которая инициирует патентный иск в отношении защищенного программного обеспечения. [39]

Товарные знаки — единственная форма интеллектуальной собственности, не разделяемая свободным и открытым программным обеспечением. Товарные знаки на FOSS функционируют так же, как и любые другие товарные знаки. [40] Товарный знак — это дизайн, который идентифицирует отдельный источник продукта. Поскольку они различают продукты, одни и те же дизайны могут использоваться в разных областях, где нет риска смешения схожих источников. [41] Отказ от контроля над товарным знаком приведет к потере этого товарного знака. Поэтому ни одна лицензия с открытым исходным кодом не предлагает свободное использование товарного знака. [42]

Ограничения на товарные знаки могут перекрывать авторские права и влиять на материалы, которые в противном случае были бы свободно доступны. [43] Верховный суд США описал использование закона о товарных знаках для ограничения контента, являющегося общественным достоянием, как «мутантное авторское право». [44] В деле Dastar Corp. против Twentieth Century Fox Film Corp. суд «предостерег от неправильного использования или чрезмерного расширения права на товарные знаки», не вынося твердого решения по этим мутантным авторским правам. [45] [46] Перекрытие товарных знаков может сделать проекты с открытым исходным кодом и бесплатным контентом уязвимыми для «враждебного поглощения», если внешние стороны подадут заявку на регистрацию товарных знаков на производные работы. [47] В частности, Андрей Дуськин подал заявку на регистрацию товарных знаков в SCP Foundation , совместном писательском проекте, при создании производных работ на основе историй SCP. [48]

Разрешительный

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

Разрешительные лицензии , также известные как академические лицензии, [49] позволяют получателям использовать, изменять и распространять программное обеспечение без обязательств предоставлять исходный код. Учреждения создали эти лицензии для распространения своих творений среди общественности. [49] Разрешительные лицензии обычно короткие, часто меньше страницы текста. Они налагают мало условий. Большинство из них включают отказ от гарантий и обязательств по указанию авторов. Некоторые включают явные положения о патентах, товарных знаках и других формах интеллектуальной собственности. [50]

Калифорнийский университет в Беркли создал первую лицензию с открытым исходным кодом, когда начал распространять свою операционную систему Berkeley Software Distribution (BSD). Лицензия BSD и ее более поздние вариации разрешают модификацию и распространение защищенного программного обеспечения. Лицензии BSD привнесли концепцию академической свободы идей в вычисления. Ранние авторы академического программного обеспечения делились кодом на основе подразумеваемых обещаний. Беркли сделал эти концепции явными с четкими отказами от ответственности и гарантий вместе с условиями или пунктами для распространения. В оригинале было четыре пункта, но последующие версии еще больше сократили ограничения. В результате принято указывать, использует ли защищенное программное обеспечение версию с 2 или 3 пунктами. [51] [52]

Массачусетский технологический институт (MIT) создал академическую лицензию на основе оригинала BSD. Лицензия MIT прояснила условия, сделав их более явными. [53] Например, лицензия MIT описывает право на сублицензирование. [54] Одной из сильных сторон разработки с открытым исходным кодом является непрерывный процесс, в котором разработчики могут основываться на производных работах друг друга и объединять свои проекты в коллективные работы. Явное указание сублицензируемости защищенного кода дает юридическое преимущество при отслеживании цепочки авторства. [53] BSD и MIT являются шаблонными лицензиями, которые можно адаптировать к любому проекту. Они широко адаптированы и используются многими проектами FOSS. [51]

Apache License более всеобъемлюща и ясна. Apache Software Foundation написала ее для своего Apache HTTP Server . Версия 2, опубликованная в 2004 году, предлагает юридические преимущества по сравнению с простыми лицензиями и предоставляет аналогичные гранты. [55] В то время как лицензии BSD и MIT предлагают неявную выдачу патента, [56] Apache License включает раздел о патентах с явной выдачей от участников. [57] Кроме того, это одна из немногих разрешительных лицензий с пунктом о возмездии за патент. [58] Пункты о возмездии за патент или приостановлении действия патента вступают в силу, если лицензиат инициирует судебный процесс о нарушении патентных прав на защищенный код. В этой ситуации патентные гранты аннулируются. Эти пункты защищают от патентного троллинга . [59]

Копилефт

На наклейке написано: «Копилефт, обведенная буква L».
Наклейка Copyleft с конверта, который Дон Хопкинс отправил Ричарду Столлману в 1984 году.

Лицензии Copyleft требуют, чтобы исходный код распространялся вместе с программным обеспечением, а также чтобы исходный код был доступен по аналогичной лицензии. [34] [60] Как и разрешительные лицензии, большинство лицензий Copyleft требуют указания авторства. [61] Большинство из них, включая GPL, отказываются от подразумеваемых гарантий. [62]

Copyleft использует ограничения закона об интеллектуальной собственности — вопреки их обычной цели — чтобы обязать код оставаться открытым. [63] Термин и связанный с ним слоган «Все права отменены» ранее использовались в игровой манере Principia Discordia и Tiny BASIC ; современное использование начинается с усилий Ричарда Столлмана по созданию свободной операционной системы. В 1984 году программист Дон Хопкинс отправил Столлману руководство с наклейкой «Copyleft Ⓛ». Столлман, работавший над операционной системой GNU, принял этот термин. [64] Ранняя версия лицензирования copyleft использовалась для выпуска GNU Emacs в 1985 году . [14] [65] Термин стал ассоциироваться с более поздними взаимными лицензиями FSF, в частности с GNU General Public License (GPL). [66]

Традиционные лицензии на проприетарное программное обеспечение пишутся с целью увеличения прибыли , но Столлман написал GPL, чтобы увеличить объем доступного свободного программного обеспечения. Его взаимные лицензии предлагают права на использование, изменение и распространение работы при условии, что люди должны выпускать производные работы по лицензии, предлагающей эти же свободы. Программное обеспечение, созданное на основе копилефта, должно поставляться с исходным кодом, а исходный код должен быть доступен по той же или аналогичной лицензии. Это обеспечивает защиту от использования кода проприетарным программным обеспечением без возврата. [67] [68] Ричард Столлман заявил, что «центральная идея копилефта заключается в использовании закона об авторском праве, но переворачивании его так, чтобы он служил противоположной его обычной цели: вместо средства приватизации программного обеспечения [авторское право] становится средством сохранения программного обеспечения свободным». [69] Лицензии на свободное программное обеспечение также являются лицензиями на программное обеспечение с открытым исходным кодом. [70] Отдельные термины «свободное программное обеспечение» и «программное обеспечение с открытым исходным кодом» отражают разные ценности, а не юридическое различие. [71] Оба движения и их формальные определения требуют, чтобы защищенная работа была доступна с исходным кодом и с разрешением на модификацию и распространение. [16] Иногда бывают крайние случаи, когда только один из FSF или OSI принимает лицензию, но популярные лицензии свободного программного обеспечения являются лицензиями с открытым исходным кодом, включая GPL . [72]

Портрет Митчелла Бейкера
Митчелл Бейкер разработал проект публичной лицензии Mozilla, работая в юридической команде Netscape. [73]

Практические преимущества лицензий copyleft привлекли коммерческих разработчиков. Корпорации использовали и писали взаимные лицензии с более узкой областью применения, чем GPL. [74] Например, Netscape разработала собственные условия copyleft после отклонения разрешительных лицензий для проекта Mozilla. [75] GPL остается самой популярной лицензией этого типа, но есть и другие значимые примеры. FSF разработал Lesser General Public License (LGPL) для библиотек . Mozilla использует Mozilla Public License (MPL) для своих релизов, включая Firefox . IBM разработала Common Public License (CPL) и позже приняла Eclipse Public License (EPL). Разница между GPL и другими взаимными лицензиями заключается в том, как они определяют производные работы, охватываемые взаимными положениями. GPL и основанная на ней лицензия Affero (AGPL) используют широкую область применения для описания затронутых работ. AGPL расширяет взаимное обязательство в GPL, чтобы охватить программное обеспечение, предоставляемое по сети. [74] [32] Их называют сильными лицензиями copyleft в отличие от более слабых лицензий copyleft, часто используемых корпорациями. Слабые лицензии copyleft используют более узкие, явные определения производных работ. [76] [35] MPL использует определение на основе файлов, CPL и EPL используют определение на основе модулей, а собственная лицензия LGPL FSF относится к библиотекам программного обеспечения. [77]

Совместимость

Таблица совместимости лицензий, полная информация в разделе.
Лицензии на программное обеспечение с открытым исходным кодом и как они взаимодействуют

Совместимость лицензий определяет, как код с разными лицензиями может распространяться вместе. Целью лицензирования с открытым исходным кодом является обеспечение свободного доступа к работе, но это усложняется при работе с несколькими терминологиями, налагающими разные требования. [78] Существует много необычно используемых лицензий , и некоторые проекты пишут свои собственные индивидуальные соглашения. В результате это вызывает больше путаницы, чем другие юридические аспекты. При выпуске коллекции приложений каждая лицензия может рассматриваться отдельно. Однако при попытке объединить программное обеспечение код из другого проекта может быть лицензирован только в том случае, если проект использует совместимые положения и условия. [79]

При объединении баз кода исходные лицензии могут быть сохранены для отдельных компонентов, а более крупная работа выпущена под совместимой лицензией. [80] Эта совместимость часто односторонняя. Содержимое общественного достояния может быть использовано где угодно, поскольку нет претензий на авторские права, но код, приобретенный на практически любых условиях, не может быть передан в общественное достояние. Разрешительные лицензии могут использоваться в работах с копилефтом, но материал с копилефтом не может быть выпущен под разрешительной лицензией. Некоторые слабые лицензии с копилефтом могут использоваться под GPL и считаются совместимыми с GPL. Программное обеспечение GPL может использоваться только под GPL или AGPL. [78] Разрешительные лицензии широко совместимы, поскольку они могут охватывать отдельные части проекта. Несколько лицензий, включая GPL и Apache License, были пересмотрены для улучшения совместимости. [81]

Проблемы перевода, неоднозначность условий лицензирования и несовместимость некоторых лицензий с законодательством в определенных юрисдикциях усугубляют проблему совместимости лицензий. [82] Загрузка модуля с открытым исходным кодом проста, но соблюдение условий лицензирования может быть более сложным. [83] Из-за большого количества зависимостей программного обеспечения инженеры, работающие над сложными проектами, часто полагаются на программное обеспечение для управления лицензиями, чтобы добиться соответствия условиям лицензирования компонентов с открытым исходным кодом. [84] Во многих файлах программного обеспечения с открытым исходным кодом лицензия указана недвусмысленно, что усложняет соблюдение. [83]

Исполнение

Портрет Харальда Вельте
Ранние юридические победы программиста Харальда Вельте создали прецедент для судебных разбирательств по программному обеспечению с открытым исходным кодом в Германии. [85]

Лицензии на свободное и открытое программное обеспечение успешно применялись в гражданских судах с середины 2000-х годов. [86] В паре ранних судебных исков — Jacobsen v. Katzer в Соединенных Штатах и ​​Welte v. Sitecom в Германии — ответчики утверждали, что лицензии на открытое программное обеспечение были недействительными. [87] [88] Sitecom и Katzer по отдельности утверждали, что лицензии были неисполнимыми. И суды США , и суды Германии отклонили эти иски. Они постановили, что ответчики не могли законно распространять программное обеспечение, если лицензии были неисполнимыми. [86] [85]

Суды установили, что распространение программного обеспечения указывает на принятие условий лицензии. [89] Физические выпуски программного обеспечения могут получить согласие потребителя с уведомлениями, размещенными на обертке . Онлайн-распространение может использовать clickwrap , цифровой эквивалент, где пользователь должен щелкнуть, чтобы принять. [90] Программное обеспечение с открытым исходным кодом имеет дополнительный механизм принятия. Без разрешения владельца авторских прав закон запрещает распространение. [91] Поэтому суды рассматривают распространение как принятие условий лицензии. Они могут включать положения об атрибуции или положения об исходном коде для лицензий copyleft. [92] [93]

Разработчики обычно добиваются соответствия без судебных исков. Социального давления, например, потенциальной реакции общества, часто бывает достаточно. [94] Письма о прекращении и воздержании являются распространенным методом возвращения компаний к соблюдению, особенно в Германии. [95] В немецкой правовой системе разработан стандартный процесс. Разработчики FOSS представляют компаниям письмо о прекращении и воздержании. В этих письмах описывается, как вернуться к соблюдению после нарушения. Немецкие судьи могут выдать предписанный судом приказ о прекращении и воздержании неотвечающим компаниям. Гражданские дела продолжаются, если эти первые шаги не удались. Немецкие процессуальные законы ясны и благоприятны для истцов. [96]

Остается неопределенность в том, как различные суды будут рассматривать определенные аспекты лицензирования. [97] Что касается программного обеспечения в целом, ведутся дебаты о том, что может быть запатентовано, а что может быть защищено авторским правом. Что касается интерфейса прикладного программирования (API), Европейский суд в деле SAS Institute 2012 года отметил , что «идеи и принципы, лежащие в основе интерфейсов [компьютерных программ], не защищены авторским правом». [98] В аналогичном деле 2021 года Верховный суд США разрешил воссоздание API в преобразующем продукте в условиях добросовестного использования . [99]

Долго обсуждаемый вопрос в сообществе FOSS заключается в том, являются ли лицензии с открытым исходным кодом «голыми лицензиями» или контрактами . [97] Голая лицензия — это набор условий, при которых разрешены действия, которые в противном случае ограничены законами об интеллектуальной собственности. [86] Согласно толкованию голой лицензии, за которое выступает FSF, иск подается в суд владельцем авторских прав как нарушение авторских прав . [86] Согласно толкованию контракта, иск может быть подан в суд вовлеченной стороной как нарушение контракта . [100] Суды США и Франции рассматривали дела в соответствии с обоими толкованиями. [101] Некоммерческие организации, такие как FSF и Software Freedom Conservancy, предлагают удерживать права на проекты разработчиков для обеспечения соблюдения. [96]

Программное обеспечение, являющееся общественным достоянием

Космические корабли и звезды на круглом мониторе
Ранние компьютерные программы, такие как новаторская видеоигра Spacewar!, находятся в общественном достоянии. [102]

Когда срок действия авторских прав истекает, работа переходит в общественное достояние и становится свободно доступной любому человеку. [103] Некоторые творческие работы не защищены авторским правом и сразу переходят в общественное достояние. В ранней истории вычислительной техники это относилось к программному обеспечению. [11] Раннее компьютерное программное обеспечение часто отдавалось вместе с оборудованием. [104] Разработанная изначально в Массачусетском технологическом институте, новаторская видеоигра Spacewar! использовалась для маркетинга и тестирования компьютера PDP-1 . [105]

По словам адвоката Лоуренса Розена , законы об авторском праве не были написаны с расчетом на то, что создатели будут размещать свои работы в общественном достоянии. Таким образом, законы об интеллектуальной собственности не предусматривают четких путей отказа от авторских прав. Высокоразрешительные лицензии, описываемые как «общественное достояние», могут юридически функционировать как односторонние контракты , которые предлагают что-то, но не налагают никаких условий. [106] [107]

Эквивалентная лицензия общественного достояния , например Creative Commons CC0, предоставляет отказ от претензий на авторские права в общественное достояние вместе с разрешительной лицензией на программное обеспечение в качестве запасного варианта. В юрисдикциях, которые не принимают отказ от общественного достояния, вступает в силу разрешительная лицензия. [108] Отказы от общественного достояния разделяют ограничения с простыми академическими лицензиями. Это создает возможность того, что внешняя сторона может попытаться контролировать работу общественного достояния с помощью патентного или товарного права. [109] Отказы от общественного достояния обрабатывают гарантии иначе, чем любой тип лицензии. Даже очень разрешительные, такие как лицензия MIT, отказываются от гарантии и ответственности. Любой, кто использует свободное программное обеспечение, должен принять этот отказ от ответственности как условие. Поскольку контент общественного достояния доступен всем, отказ от авторских прав не может налагать отказ от ответственности. [103]

Использование в фирменном программном обеспечении

Лицензии с открытым исходным кодом позволяют другим предприятиям коммерциализировать защищенное программное обеспечение. [110] Работа, выпущенная по разрешительной лицензии, может быть включена в проприетарное программное обеспечение. [111] Разрешительные лицензии разрешают добавлять новые условия, включая проприетарные. [112] [113] Проприетарное программное обеспечение имеет сильно интегрированный открытый исходный код, выпущенный по лицензиям Apache, BSD и MIT. [114] Открытое ядро ​​— это бизнес-модель, в которой разработчики выпускают основную часть программного обеспечения как открытое исходное код и монетизируют продукт, содержащий его, как проприетарное программное обеспечение. [115] Строгая лицензия GPL с копилефтом написана для предотвращения распространения в рамках проприетарного программного обеспечения. [116] [117] Слабая лицензия с копилефтом налагает особые требования на производные работы, которые могут позволить распространять защищенный код в рамках проприетарного программного обеспечения при определенных обстоятельствах. [78]

Облачные вычисления опираются на бесплатное и открытое программное обеспечение и избегают распространения, которое запускает большинство лицензий. Облачное программное обеспечение размещается, а не распространяется. [118] Поставщик размещает программное обеспечение в сети, и его конечным пользователям не нужно загружать, получать доступ или даже знать об используемом коде. [119] Копилефт GNU Affero General Public License (AGPL) активируется, когда покрытый код размещается или распространяется. [120] Некоторые разработчики приняли AGPL, а другие перешли на проприетарные лицензии с функциями лицензирования с открытым исходным кодом. [121] Например, разработчик открытого ядра Elastic перешел с лицензии Apache на «исходно-доступную» Server Side Public License . [122] Исходно-доступное программное обеспечение поставляется с исходным кодом в качестве ссылки. [123]

С 2010 года облачная модель приобрела большую популярность. [118] Разработчики критиковали облачные компании, которые получают прибыль от размещения программного обеспечения с открытым исходным кодом, не внося при этом деньги или код в исходное состояние, сравнивая эту практику с добычей полезных ископаемых . [124] Лидер в области облачных вычислений Amazon Web Services заявил, что они соблюдают лицензии и действуют в интересах своих клиентов. [124] [125]

Смотрите также

Примечания

  1. ^ Байфилд 2008.
  2. ^ Розен 2005, стр. 22.
  3. Розен 2005, стр. 22–23.
  4. ^ ab Rosen 2005, стр. 15.
  5. ^ «Бернское соглашение». Wex . Юридическая школа Корнелла. Ноябрь 2021 г.
  6. ^ Фагундес и Перзановский 2020, с. 529.
  7. ^ Розен 2005, стр. 17.
  8. Розен 2005, стр. 27–28.
  9. Розен 2005, стр. 28–29.
  10. ^ Розен 2005, стр. 28.
  11. ^ ab Оман 2018, стр. 641–642.
  12. Уильямс 2002, гл. 1.
  13. Уильямс 2002, гл. 7.
  14. ^ ab Williams 2002, гл. 9.
  15. ^ Гринбаум 2016, § IA
  16. ^ abc Маракке 2019, § 2.2.
  17. Карвер 2005, стр. 448–450.
  18. ^ Перенс 1999, ¶ 16.
  19. ^ Гринбаум 2016, стр. 1302–1303.
  20. ^ Гринбаум 2016, стр. 1304–1305.
  21. ^ Гринбаум 2016, стр. 1305.
  22. ^ Фонтана 2010, стр. 2.
  23. ^ Коулман 2004, «Политический агностицизм».
  24. Рэймонд 1999, «Мемы и мифотворчество».
  25. Микер 2020, 2:33–3:06.
  26. Рэймонд 2001, «Собор и базар».
  27. ^ Брок 2022, § 16.3.4.
  28. ^ Рэймонд 2001.
  29. ^ Рэймонд 2001, «Социальный контекст программного обеспечения с открытым исходным кодом».
  30. ^ Рэймонд 2001, стр. 19.
  31. ^ Онетти и Верма 2009, стр. 69.
  32. ^ ab Hammerly, Paquin & Walton 1999.
  33. ^ Смит 2022, § 3.2.
  34. ^ ab Сен, Субраманиам и Нельсон 2008, стр. 211–212.
  35. ^ ab Meeker 2020, 16:13.
  36. ^ ab Rosen 2005, стр. 22–24.
  37. ^ Бэйн и Смит 2022, § 10.4.3.
  38. ^ Бэйн и Смит 2022, § 10.4.2.
  39. ^ ab Bain & Smith 2022, § 10.4.4.
  40. ^ Честек 2022, стр. 30.
  41. ^ Честек 2022, стр. 184–185.
  42. ^ Розен 2005, стр. 38.
  43. Джой 2022, стр. 986.
  44. Джой 2022, стр. 989.
  45. Dastar Corp. против Twentieth Century Fox Film Corp. , 539 US 23, 34 (2003).
  46. Джой 2022, стр. 987–988.
  47. Джой 2022, стр. 1004–1006.
  48. Джой 2022, стр. 979, 1002.
  49. ^ ab Rosen 2005, стр. 69.
  50. Розен 2005, стр. 101–102.
  51. ^ ab Smith 2022, § 3.2.1.1.
  52. ^ OSI 2023.
  53. ^ ab Rosen 2005, стр. 73–90.
  54. ^ OSI 2023, «Лицензия MIT».
  55. ^ Смит 2022, § 3.2.1.2.
  56. ^ Бэйн и Смит 2022, § 10.4.2.
  57. ^ OSI 2023, «Лицензия Apache, версия 2.0».
  58. Bain & Smith 2022, гл. 10.
  59. ^ Бэйн и Смит 2022, § 10.4.4.
  60. Сен-Лоран 2004, стр. 38–39.
  61. ^ Балльхаузен 2019, стр. 86.
  62. ^ Розен 2005, стр. 135.
  63. ^ Розен 2005, стр. 103–106.
  64. ^ Китс 2010, стр. 64.
  65. ^ «Полный текст уведомления о разрешении копирования GNU Emacs». 1985.
  66. Китс 2010, стр. 63–67.
  67. ^ Розен 2005, стр. 103–109.
  68. Микер 2020, 6:00–7:22.
  69. Джой 2022, стр. 990–992.
  70. ^ Онетти и Верма 2009, стр. 71.
  71. Сен-Лоран 2004, стр. 81–83, 114.
  72. ^ Балльхаузен 2019, стр. 82.
  73. Сен-Лоран 2004, стр. 68, 75.
  74. ^ Аб Цай 2008, стр. 564–570.
  75. ^ Хаммерли, Пакуин и Уолтон 1999, ¶ 23.
  76. ^ Сен, Субраманиам и Нельсон 2008, стр. 212–213.
  77. ^ Розен 2005, см. соответствующие главы.
  78. ^ abc Smith 2022, § 3.3.
  79. ^ Розен 2005, стр. 243–247.
  80. Сен-Лоран 2004, стр. 159–163.
  81. См. Smith 2022, стр. 102 для: Apache License версии 2.0 в 2004 г., GPL версии 3 в 2007 г., LGPL версии 3 в 2007 г. и AGPL версии 3 в 2007 г. См. Smith 2022, стр. 95–101 для: MPL версии 2.0 в 2012 г. и EPL версии 2 в 2017 г.
  82. ^ Бернелин 2020, стр. 100, 102.
  83. ^ ab Ombredanne 2020, стр. 105.
  84. ^ Ombredanne 2020, стр. 106.
  85. ^ ab Ballhausen 2022, § 5.3.
  86. ^ abcd Смит 2022, § 3.4.1.
  87. ^ Якобсен против Катцера , 535 F.3d 1373 ( Федеральный округ, 2008 г.).
  88. ^ Welte против Sitecom (Окружной суд Мюнхена 2004 г.), № 21 O 6123/04.
  89. ^ Смит 2022, стр. 106.
  90. ^ Розен 2005, стр. 137.
  91. ^ Розен 2005, стр. 138.
  92. ^ Розен 2005, гл. 6.
  93. ^ Микер 2020, 17:04.
  94. Сен-Лоран 2004, стр. 158–159.
  95. ^ Балльхаузен 2022, стр. 127.
  96. ^ ab Ballhausen 2022, § 5.4.
  97. ^ ab Walden 2022, § 1.1.
  98. ^ Смит 2022, § 3.1.3.
  99. ^ Google LLC против Oracle America, Inc. , 593 US, 1203 (2021).
  100. ^ Смит 2022, § 3.4.2.
  101. ^ Смит 2022, § 3.4.
  102. ^ Росс 2021, «Космическая война: Конец разработки».
  103. ^ ab Rosen 2005, стр. 36.
  104. ^ Уолден 2022, стр. 3.
  105. ^ Смит 2019, стр. 55–56.
  106. ^ Розен 2005, стр. 74–77.
  107. ^ Сен-Лоран 2004, стр. 98.
  108. ^ Фагундес и Перзановский 2020, с. 524.
  109. Джой 2022, стр. 1008–1010.
  110. ^ Брок 2022, § 16.3.3.
  111. ^ Сен-Лоран 2004, стр. 14.
  112. Сен-Лоран 2004, стр. 22.
  113. ^ Онетти и Верма 2009, стр. 81.
  114. Сен-Лоран 2004, стр. 30.
  115. ^ Брок 2022, § 16.4.2.3.
  116. ^ Цай 2008, стр. 550.
  117. ^ Сен-Лоран 2004, стр. 39.
  118. ^ ab Brock 2022, § 16.5.2.
  119. ^ Брок 2022, § 16.4.2.8.
  120. ^ Брок 2022, § 16.4.2.2.
  121. ^ Брок 2022, § 16.5.3.
  122. ^ Брок 2022, § 16.5.3.8.
  123. ^ Кунерт 2022.
  124. ^ ab Вакабаяси 2019.
  125. ^ Брок 2022, § 16.5.3.2.

Ссылки