Est-il possible de modifier le code du Chili plugin , qui a eu sa dernière version en juillet 2008, et il est autorisé sous la licence MIT, pour ensuite le licencier sous GPL?
Pour autant que je puisse voir, il n'y a aucune restriction quant à la licence du nouveau code sous la même licence. En est-il vraiment ainsi ou y a-t-il un nombre minimum de changements?
Dans mon cas, je changerais le plugin jQuery en code Javascript normal qui est exécuté dans un CMS. Cela signifie essentiellement que, entre autres:
$($element).chili()
, mais en tant que GlobalObject.ChiliHighlighter.process($jquery_element)
, où "GlobalObject" est un objet JavaScript utilisé à partir du CMS.GlobalObject.ChiliHighlighter
Pour ajouter des fonctions qui sont éventuellement appelées à partir de GlobalObject.ChiliHighlighter.process()
lorsqu'elles sont définies.Comme alternative, comme le référentiel que j'utilise me permet d'inclure du code non autorisé sous GPL 2 ou une licence supérieure lorsque le code n'est plus maintenu, le plugin pourrait-il être considéré comme n'étant plus maintenu, car sa dernière version a été publiée il y a trois ans?
C'est techniquement légal.
La licence MIT (Expat) vous impose quelques restrictions. Il s'agit d'un sous-ensemble de la licence GPL. Par conséquent, si vous remettez le code sous licence GPL, et gardez l'avis MIT, alors vous avez satisfait aux termes de la licence MIT et pouvez redistribuer légalement le code.
Notez que vous ne pouvez pas revendiquer la propriété des droits d'auteur; vous devrez reconnaître le droit d'auteur d'origine.
[modifier] Certaines personnes ne semblent pas comprendre comment F/OSS fonctionne conjointement avec la loi sur les droits d'auteur et les licences. Tout commence par le droit d'auteur, ne serait-ce que parce que c'est la valeur par défaut. En vertu de la doctrine du droit d'auteur, l'auteur obtient le droit de faire des copies du code source. Sous la licence MIT, ce droit m'est accordé, ainsi que le droit de l’accorder récursivement à d’autres. Notez que la licence MIT explicitement inclut le droit de sous-licence. Citation: "the rights to use, copy, modify, merge, publish,distribute,
sublicense,
and/or sell"
Lorsque je sous-licencie du code, je ne peux pas accorder de droits que je n'avais pas à l'origine. Dans le cas de la GPL, il m'est explicitement interdit de sous-licencier seulement certains droits. Mais ni dans la loi ni dans la licence MIT), je n'ai l'obligation de sous-licencier tous les droits dans leur ensemble.
Par conséquent, la licence MIT me confère le droit explicite de sous-licencier des droits, et ni la loi ni la licence MIT ne m'interdit de sous-licencier uniquement certains droits. De plus, aucun ne restreint la forme sous laquelle je le fais. Par conséquent, j'ai le droit indéniable d'accorder une sous-licence GPL sur ce code.
Oui. Mais l'effet peut ne pas être ce que vous pensez qu'il est.
La licence MIT comprend tous les droits accordés par la GPL et bien plus encore. Et tandis que les personnes qui reçoivent votre distribution ne reçoivent une licence GPL qu'aux éléments que vous avez ajoutés, elles reçoivent toujours une MIT licence (des auteurs originaux, pas de vous) à tous les éléments contenus dans le travail que les auteurs ont offert sous cette licence.
Ils ne le savent peut-être pas, et pour autant que je sache, aucune loi ne vous oblige à le leur dire. Mais s'ils "violent" la licence GPL en ce qui concerne l'expression protégeable contenue dans le travail que vous n'avez pas écrit (ou qui n'a pas été contribué par d'autres à la version GPL uniquement), ils n'ont pas violé votre licence ou votre droit d'auteur. (En fait, cela devrait être assez évident - vous ne détenez le droit d'auteur que sur les expressions que vous avez créées.)
Vous n'avez donc converti aucun élément sous copyright de la licence MIT en licence GPL. Vous en avez simplement ajouté de nouveaux qui ne sont proposés que sous la licence GPL et publié les éléments dans une version mixte/travail combiné.
Rien à ajouter aux explications dans les réponses déjà données, mais voici des instructions pour façonner vos en-têtes de fichier source ( source =):
2.2 Ajout de modifications GPL aux fichiers sous licence permissive
Un cas plus compliqué se produit lorsqu'un développeur apporte des modifications sous copyright à un fichier sous licence permissive que le développeur incorpore dans un programme GPL. Les développeurs dans cette situation appliquent généralement la GPL à leurs modifications. (Cependant, il est possible que le développeur fournisse à la place un nouveau code selon des termes permissifs, tels que la licence permissive qui régit le fichier non modifié. Nous discutons de ce cas au § 2.3.)
Même si la licence permissive du projet externe accorde l'autorisation légale d'incorporer le code de ce projet dans un projet GPL'd, le développeur du projet GPL'd doit néanmoins se conformer à l'exigence de conservation des avis dans la licence permissive. Dans un projet qui utilise la méthode fichier par fichier, un développeur qui apporte des modifications sous copyright à un fichier sous licence permissive doit placer un nouvel avis de droit d'auteur et un avis d'autorisation au-dessus de celui existant et doit indiquer clairement que le développeur a modifié le fichier. Le haut du fichier apparaîtra alors comme suit:
/*
* 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.
*/
Il est très important que le développeur conserve l'intégralité de l'avis de droit d'auteur, de l'autorisation et de la clause de non-responsabilité de garantie tels qu'ils figuraient dans le code d'origine, comme l'exige la licence d'autorisation. Nous voyons parfois des avis GPL mélangés avec des avis de licence permissifs - une pratique déroutante qui obscurcit à la fois la provenance du code et les autorisations précises accordées par les différents titulaires de droits d'auteur répertoriés dans les avis. Lorsque différents titulaires de droits d'auteur ont publié leurs contributions selon des conditions différentes, les conditions que chacun a imposées à sa contribution particulière doivent être spécifiées. Nous recommandons de faire une séparation claire et d'utiliser une indentation, comme dans l'exemple ci-dessus.
Cette manière d'organiser les avis dans le fichier permet aux développeurs de choisir entre contribuer selon des termes permissifs ou sous GPL. S'ils souhaitent rendre leurs contributions disponibles dans des conditions permissives, ils peuvent ajouter leurs avis de droits d'auteur au groupe inférieur. S'ils souhaitent contribuer sous la GPL, ils peuvent ajouter leurs avis de droits d'auteur en haut. Notez, cependant, que dans un seul fichier source, il est généralement très difficile, et souvent totalement impossible, de déterminer quelles parties d'un tel fichier sont couvertes par des termes facultatifs. Si l'objectif est de rendre le code supplémentaire disponible uniquement sous des termes facultatifs, la méthode décrite au § 2.3 doit être utilisée.