Можете ли вы изменить код, распространяемый по лицензии MIT, и повторно распространять его по лицензии GPL? [закрыто]

Можно ли изменить код плагина Chili , последний выпуск которого был выпущен в июле 2008 года и лицензирован по лицензии MIT, чтобы затем лицензировать его по лицензии GPL?

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

В моем случае я бы изменил плагин jQuery в обычном коде Javascript, который выполняется в CMS. По сути это означает, что, помимо прочего:

Код не будет использовать пространство имен «ChiliBook».
Функция будет вызываться не как $($element).chili(), а как GlobalObject.ChiliHighlighter.process($jquery_element), где «GlobalObject» - это объект JavaScript, используемый в CMS.
Код позволит другим модулям изменять GlobalObject.ChiliHighlighterобъект для добавления функций, которые при необходимости вызываются GlobalObject.ChiliHighlighter.process()при их определении.

В качестве альтернативы, поскольку репозиторий, который я использую, позволяет мне включать код, не лицензированный по лицензии GPL 2 или выше, когда код больше не поддерживается, можно ли считать, что плагин больше не поддерживается, так как его последняя версия была выпущена три года назад?

licensing gpl mit-license

— kiamlaluno
источник

Если вы действительно хотите получить авторитетный ответ, вам следует проконсультироваться с юристом (например, в соответствующей юрисдикции ответ может быть другим в Италии, чем в США)

— MarkJ

Ответы:

Это технически законно.

Лицензия MIT (Expat) накладывает на вас несколько ограничений. Это часть лицензии GPL. Поэтому, если вы повторно лицензируете код в соответствии с GPL и сохраняете уведомление MIT, то вы выполнили условия лицензии MIT и можете законно распространять код.

Обратите внимание, что вы не можете претендовать на право собственности; вам придется признать оригинальное авторское право.

[править] Некоторые люди, похоже, не понимают, как F / OSS работает в сочетании с законом об авторском праве и лицензии. Все начинается с авторского права, хотя бы потому, что это по умолчанию. Согласно доктрине авторского права, автор получает право делать копии исходного кода. По лицензии MIT это право предоставляется мне, а также право рекурсивно предоставлять его другим. Обратите внимание, что лицензия MIT явно включает в себя право на сублицензию. Цитирование:"the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell"

Когда я сублицензирую код, я не могу предоставить права, которые у меня изначально не было. В случае GPL, мне явно запрещено сублицензировать только некоторые права. Но ни по закону, ни по лицензии MIT я не обязан сублицензировать все права в целом.

Поэтому лицензия MIT предоставляет мне явное право на сублицензионные права, и ни закон, ни лицензия MIT не запрещают мне сублицензировать только некоторые права. Кроме того, ни один не ограничивает форму, в которой я делаю. Поэтому я имею неоспоримое право предоставлять сублицензию GPL на этот код.

— MSalters
источник

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

— Дэвид Шварц

@vartec: По сути, вы утверждаете, что лицензия на авторское право, которая предоставляет право на сублицензию, на самом деле не дает права на сублицензию. Я не уверен, на каком основании вы делаете этот аргумент, хотя. Есть ли у вас какие-либо ссылки на какие-либо соответствующие юридические органы? Вы говорите, что правообладатель не может предоставить другим право лицензировать его работу? Или вы думаете, что лицензия MIT как-то не в состоянии это сделать или не собирается?

— Дэвид Шварц

@ Дэвид: вы, кажется, не понимаете, что означает «сублицензирование».

— vartec

@vartec: Ссылка на источник, объясняющий, что это было бы здорово, потому что я думаю, что вы не понимаете, что это значит.

— Дэвид Шварц

В лицензии MIT есть такой бит: «Вышеуказанное уведомление об авторских правах и это уведомление о разрешении должны быть включены во все копии или существенные части Программного обеспечения». Это означает, что любой форк должен быть доступен под лицензией MIT. Изменения могут быть перечислены как GPL. Разветвление может быть указано как GPL + MIT. Но вилка не может быть указана только как GPL - это явное нарушение лицензии MIT.

— Джонатан Ванаско

Да. Но эффект может быть не таким, как вы думаете.

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

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

Таким образом, вы не преобразовали защищенные авторским правом элементы из лицензии MIT в лицензию GPL. Вы просто добавили новые, которые предлагаются только по лицензии GPL, и выпустили элементы в смешанной / комбинированной работе.

— Дэвид Шварц
источник

поэтому на практике я бы сделал это: скопируйте проект MIT, замените все MIT на GPL (чтобы от проекта, который был MIT, не осталось следов), а затем дополнительно добавьте ссылку на исходный проект MIT в нескольких важных местах (не в каждом) хотя и исходный файл), упоминая, что базовый проект доступен в MIT. это будет нормально / законно (учитывая, что я сохраняю исходные заявления владельца авторских прав)?

— hoijui

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

— jmiserez

@jmiserez хорошо. Итак, давайте посмотрим на один файл моего проекта, затем: я оставляю заголовок MIT, делаю некоторые изменения и добавляю заголовок GPL (так как я хочу, чтобы мои изменения были доступны только под GPL). Теперь третье лицо, пришедшее по поводу моего файла, должно будет соблюдать и MIT, и GPL? я никогда не видел файл с двумя заголовками лицензий, и я подумал бы, что большинство людей просто выберут лицензию, которая им нравится, поскольку они не знают, каков юридически правильный путь. Кроме того, почему я должен включить MIT, если, соблюдая GPL, каждый автоматически также уважает MIT?

— Hoijui

@hoijui Любые права, которыми вы обладаете по лицензии MIT, сопровождаются ограничением «Вышеуказанное уведомление об авторских правах и это уведомление о разрешении должны быть включены во все копии или существенные части Программного обеспечения». Но, честно говоря, я не уверен, нужно ли вам сохранять все из уведомлений, или только один, IANAL. Но я уверен, что вам нужно куда-то включить уведомление. Если вы этого не сделаете, вы больше не будете соответствовать лицензии MIT, а это значит, что вы потеряете все права на использование кода в своем проекте. К сведению, в ядре Linux есть файлы с несколькими лицензиями, они используют заголовки SPDX

— jmiserez

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

— Эндрю Финнелл

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

2.2 Добавление GPL-модификаций в разрешительно-лицензированные файлы

Более сложный случай возникает, когда разработчик вносит изменяемые авторским правом изменения в файл с разрешающей лицензией, который разработчик включает в программу GPL. Разработчики в этой ситуации обычно применяют GPL к своим модификациям. (Однако разработчик может вместо этого внести новый код на разрешающих условиях, таких как разрешающая лицензия, которая управляет неизмененным файлом. Мы обсуждаем этот случай в п. 2.3.)

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

/*  
 * Copyright (c) 2007  GPL Project Developer Who Made Changes   
 *  
 *  This file is free software: you may copy, redistribute and/or modify it  
 *  under the terms of the GNU General Public License as published by the  
 *  Free Software Foundation, either version 2 of the License, or (at your  
 *  option) any later version.  
 *  
 *  This file is distributed in the hope that it will be useful, but  
 *  WITHOUT ANY WARRANTY; without even the implied warranty of  
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU  
 *  General Public License for more details.  
 *  
 *  You should have received a copy of the GNU General Public License  
 *  along with this program.  If not, see .  
 *  
 * This file incorporates work covered by the following copyright and  
 * permission notice:  
 *  
 *     Copyright (c) YEARS_LIST, Permissive Contributor1   
 *     Copyright (c) YEARS_LIST, Permissive Contributor2   
 *  
 *     Permission to use, copy, modify, and/or distribute this software  
 *     for any purpose with or without fee is hereby granted, provided  
 *     that the above copyright notice and this permission notice appear  
 *     in all copies.  
 *  
 *     THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL  
 *     WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED  
 *     WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE  
 *     AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR  
 *     CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS  
 *     OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,  
 *     NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN  
 *     CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.  
 */

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

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

— hoijui
источник