Czy możesz zmienić kod rozpowszechniany na licencji MIT i ponownie rozpowszechniać go na licencji GPL? [Zamknięte]

Czy można zmienić kod wtyczki Chili , która miała najnowszą wersję w lipcu 2008 r. I jest licencjonowany na licencji MIT, aby następnie licencjonować go na licencji GPL?

Jak widzę, nie ma ograniczeń co do licencjonowania nowego kodu na tej samej licencji. Czy tak naprawdę jest, czy jest minimalna liczba zmian?

W moim przypadku zmieniłbym wtyczkę jQuery na normalny kod JavaScript, który jest wykonywany w CMS. Zasadniczo oznacza to, że między innymi:

Kod nie będzie używał przestrzeni nazw „ChiliBook”.
Funkcja nie zostanie wywołana jako $($element).chili(), ale jako GlobalObject.ChiliHighlighter.process($jquery_element), gdzie „GlobalObject” to obiekt JavaScript używany z CMS.
Kod pozwoli innym modułom na zmianę GlobalObject.ChiliHighlighterobiektu w celu dodania funkcji, które są opcjonalnie wywoływane, GlobalObject.ChiliHighlighter.process()gdy są zdefiniowane.

Alternatywnie, ponieważ repozytorium, z którego korzystam, pozwala mi dołączyć kod, który nie jest objęty licencją GPL 2 lub wyższą, gdy kod nie jest już utrzymywany, czy wtyczkę można uznać za nieobsługiwaną, ponieważ jej ostatnia wersja została wydana trzy lata temu?

licensing gpl mit-license kiamlaluno
źródło

Jeśli naprawdę chcesz uzyskać autorytatywną odpowiedź, powinieneś skonsultować się z prawnikiem (w odpowiedniej jurysdykcji, na przykład odpowiedź może być inna we Włoszech niż w Stanach Zjednoczonych)

MarkJ

Odpowiedzi:

Jest to technicznie legalne.

Licencja MIT (Expat) nakłada na ciebie kilka ograniczeń. Są to podzbiór licencji GPL. W związku z tym, jeśli licencjonujesz kod na licencji GPL i zachowujesz powiadomienie MIT, wówczas spełniasz warunki licencji MIT i możesz legalnie redystrybuować kod.

Pamiętaj, że nie możesz rościć sobie prawa własności do praw autorskich; musisz potwierdzić oryginalne prawa autorskie.

[edytuj] Niektóre osoby nie rozumieją, jak działa F / OSS w połączeniu z prawem autorskim i prawem licencyjnym. Wszystko zaczyna się od praw autorskich, choćby dlatego, że jest to ustawienie domyślne. Zgodnie z doktryną praw autorskich autor ma prawo do wykonywania kopii kodu źródłowego. Zgodnie z licencją MIT to prawo jest mi przyznane, a także prawo do rekurencyjnego przyznawania go innym osobom. Pamiętaj, że licencja MIT wyraźnie obejmuje prawo do sublicencjonowania. Cytowanie:"the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell"

Podlicencjonując kod, nie mogę udzielać praw, których pierwotnie nie miałem. W przypadku GPL wyraźnie zabronione jest sublicencjonowanie tylko niektórych praw. Ale ani na mocy prawa, ani na licencji MIT nie mam obowiązku udzielania podlicencji na wszystkie prawa jako całość.

Dlatego licencja MIT przyznaje mi wyraźne prawo do sublicencjonowania, a ani prawo, ani licencja MIT nie zabraniają mi sublicencjonowania tylko niektórych praw. Nie ogranicza też formy, w jakiej to robię. Dlatego mam niezaprzeczalne prawo do udzielenia sublicencji GPL na ten kod.

MSalters
źródło

@vartec: Nie zmieniasz licencji, na podstawie której otrzymałeś kod. Tworzysz nową licencję między tobą a nowym odbiorcą i może ona zawierać dowolne warunki. (Nowy odbiorca może uzyskać dodatkowe prawa wynikające z pierwotnej licencji, ale nie ma to wpływu na nową licencję.) Normą jest, że podlicencja udziela części ułamka praw wynikających z pierwotnej licencji. Na przykład sublicencja rzadko obejmuje prawo do sublicencji, które musiała zawierać oryginalna licencja, aby sublicencja była możliwa.

David Schwartz,

@vartec: Zasadniczo argumentujesz, że licencja na prawa autorskie, która daje prawo do sublicencji, w rzeczywistości nie przyznaje prawa do sublicencji. Nie jestem jednak pewien, na jakiej podstawie wysuwasz ten argument. Czy masz jakieś cytaty do jakiegokolwiek odpowiedniego organu prawnego? Czy mówisz, że właściciel praw autorskich nie może udzielić innym prawa do licencjonowania jego dzieła? A może uważasz, że licencja MIT jakoś tego nie robi lub nie zamierza?

David Schwartz

@ David: wydaje się, że nie rozumiesz, co oznacza „sublicencjonowanie”.

vartec,

@vartec: Link do źródła, który wyjaśnia, że byłoby świetnie, ponieważ myślę, że nie rozumiesz, co to znaczy.

David Schwartz,

Licencja MIT zawiera w sobie następujący fragment: „Powyższa informacja o prawach autorskich i ta informacja o pozwoleniu będą zawarte we wszystkich kopiach lub znacznych częściach Oprogramowania”. Oznacza to, że każdy widelec musiałby być dostępny na licencji MIT. Zmiany mogą być wymienione jako GPL. Widelec może być wymieniony jako GPL + MIT. Ale widelca nie można wymienić tylko na GPL - to wyraźne naruszenie licencji MIT.

Jonathan Vanasco

Tak. Ale efekt może nie być taki, jak myślisz.

Licencja MIT obejmuje wszystkie prawa przyznane przez GPL i więcej. I chociaż osoby, które otrzymają Twoją dystrybucję, otrzymują licencję GPL tylko na dodane przez Ciebie elementy, nadal otrzymują licencję MIT (od oryginalnych autorów, a nie od Ciebie) na dowolne elementy zawarte w dziele, które autorzy zaoferowali na podstawie tej licencji.

Mogą tego nie wiedzieć, a o ile mi wiadomo, żadne prawo nie zobowiązuje cię do tego. Ale jeśli „naruszą” licencję GPL w odniesieniu do chronionego wyrażenia zawartego w dziele, którego nie stworzyłeś (lub który nie został wniesiony przez innych do wydania tylko GPL), nie naruszyli twojej licencji ani twoich praw autorskich. (W rzeczywistości powinno to być dość oczywiste - masz prawa autorskie tylko do wyrażeń, których jesteś autorem).

Więc nie przekonwertowałeś żadnych elementów objętych prawem autorskim z licencji MIT na licencję GPL. Po prostu dodałeś nowe, które są oferowane tylko na licencji GPL i wypuściłeś elementy w pracy mieszanej / mieszanej.

David Schwartz
źródło

więc w praktyce zrobiłbym to: skopiuj projekt MIT, zamień wszystko MIT na GPL (więc nie pozostało śladu projektu, który był MIT), a następnie dodatkowo połącz z oryginalnym projektem MIT w kilku ważnych miejscach (nie co plik źródłowy), wspominając, że projekt podstawowy jest dostępny w ramach MIT. czy byłoby to w porządku / legalne (pod warunkiem zachowania oryginalnych oświadczeń właściciela praw autorskich)?

hoijui

@hoijui Musisz pozostawić nienaruszone wszystkie nagłówki licencji MIT i powiadomienia o pozwoleniach oraz dołączyć je do nowego projektu. I jeśli nie zamierzasz oszukiwać, nie rozumiem, dlaczego zastąpiłbyś wszystkie wzmianki o „MIT”. Nic to nie zmieni, części, które zabierzesz, nadal będą miały licencję MIT. Po prostu dodaj poniżej swój nagłówek licencji GPL, będzie on ważny dla wszystkich zmian chronionych prawem autorskim (tj. Nie tylko zmiany nazw zmiennych), które wprowadzisz do kodu źródłowego. BTW, dlatego większość projektów ma nagłówek praw autorskich w każdym pliku.

jmiserez

@jmiserez ok. więc spójrzmy na jeden plik mojego projektu: opuszczam nagłówek MIT, wprowadzam pewne zmiany i dodam nagłówek GPL (ponieważ chcę, aby moje zmiany były dostępne tylko na GPL). teraz trzecia strona o moim pliku musiałaby honorować zarówno MIT, jak i GPL? nigdy nie widziałem pliku z dwoma nagłówkami licencji i myślę, że większość ludzi wybrałaby licencję, którą lubią, ponieważ nie wiedzą, co jest prawnie właściwe. także, dlaczego muszę dołączyć MIT, jeśli honorując GPL, automatycznie honoruje również MIT?

hoijui

@hoijui Wszelkie prawa, które przysługują Ci na mocy licencji MIT, podlegają ograniczeniu „Powyższa informacja o prawach autorskich i ta informacja o zezwoleniu będą zawarte we wszystkich kopiach lub znacznych częściach Oprogramowania”. Ale szczerze mówiąc, nie jestem pewien, czy musisz zachować wszystkie zawiadomień lub tylko jednego, IANAL. Ale jestem pewien, że musisz gdzieś zawrzeć zawiadomienie. Jeśli tego nie zrobisz, nie będziesz już zgodny z licencją MIT, co oznacza, że stracisz wszelkie prawa do używania kodu w swoim projekcie. Dla twojej informacji jądro Linuksa ma pliki z wieloma licencjami, używają nagłówków SPDX

jmiserez

Jak to smutne, że ktoś chce spróbować kodu GPL zbudowanego na licencji MIT. Wydaje się to być sprzeczne ze wszystkim, co oznacza licencja MIT.

Andrew T Finnell,

Nic do dodania do wyjaśnień w już udzielonych odpowiedziach, ale oto instrukcje, jak kształtować nagłówki plików źródłowych ( źródło ):

2.2 Dodawanie modyfikacji GPL do plików licencjonowanych zezwalających

Bardziej skomplikowany przypadek występuje, gdy programista dokonuje zmian praw autorskich do pliku na licencji zezwalającego, który programista włącza do programu na licencji GPL. Programiści w takiej sytuacji zwykle stosują GPL do swoich modyfikacji. (Jednak deweloper może zamiast tego wnieść nowy kod na dozwolonych warunkach, takich jak licencja na zezwolenie, która reguluje niezmodyfikowany plik. Omawiamy tę sprawę w § 2.3.)

Mimo że licencja zezwalająca na projekt zewnętrzny przyznaje prawne zezwolenie na włączenie kodu z tego projektu do projektu GPL, twórca projektu GPL musi mimo to spełnić wymóg zachowania zawiadomienia w licencji zezwalającej. W projekcie korzystającym z metody „plik po pliku” programista, który dokonuje modyfikacji praw autorskich do pliku licencjonowanego zezwalającego, powinien umieścić nowe powiadomienie o prawach autorskich i powiadomienie o pozwoleniu powyżej istniejącego i wyjaśnić, że twórca zmodyfikował plik. Góra pliku pojawi się w następujący sposób:

/*  
 * 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.  
 */

Bardzo ważne jest, aby deweloper zachował całą informację o prawach autorskich, zezwolenie i zrzeczenie się gwarancji, tak jak pojawiły się w oryginalnym kodzie, zgodnie z wymogami dozwolonej licencji. Czasami widzimy, że powiadomienia GPL są pomieszane z dopuszczającymi ogłoszeniami licencyjnymi - myląca praktyka, która zaciemnia zarówno pochodzenie kodu, jak i dokładne uprawnienia przyznane przez różnych właścicieli praw autorskich wymienionych w ogłoszeniach. Gdy różni właściciele praw autorskich udostępnili swój wkład na różnych warunkach, należy określić warunki, które każdy umieścił na jego konkretnym wkładzie. Zalecamy wyraźne oddzielenie i użycie wcięć, jak w powyższym przykładzie.

Ten sposób organizowania powiadomień w pliku ułatwia programistom wybór, czy wnieść wkład na warunkach dozwolonych, czy na licencji GPL. Jeśli chcą udostępnić swój wkład na warunkach dozwolonych, mogą dodać swoje uwagi dotyczące praw autorskich do niższej grupy. Jeśli chcą wziąć udział w GPL, mogą dodać swoje uwagi dotyczące praw autorskich u góry. Należy jednak pamiętać, że w jednym pliku źródłowym określenie, które części takiego pliku są objęte dozwolonymi warunkami, jest zwykle bardzo trudne i często całkowicie niemożliwe. Jeżeli celem jest udostępnienie dodatkowego kodu wyłącznie na warunkach dozwolonych, należy zastosować metodę opisaną w § 2.3.

hoijui
źródło