您可以更改根据MIT许可证分发的代码，然后根据GPL许可证重新分发吗？[关闭]

是否有可能更改Chili插件的代码（该软件的最新发布时间为2008年7月，并且已获得MIT许可），然后又根据GPL对其进行了许可？

据我所知，对新代码以相同许可证进行许可没有任何限制。真的是这样，还是有最少的变更？

就我而言，我将更改在CMS中执行的普通Javascript代码中的jQuery插件。这基本上意味着：

• 该代码将不使用“ ChiliBook”命名空间。
• 该函数将不会以方式调用$($element).chili()，而是以方式调用GlobalObject.ChiliHighlighter.process($jquery_element)，其中“ GlobalObject”是CMS中使用的JavaScript对象。
• 该代码将允许其他模块更改GlobalObject.ChiliHighlighter对象，以添加自GlobalObject.ChiliHighlighter.process()定义功能时调用的功能。

作为替代方案，由于我正在使用的存储库允许我在不再维护代码时包括未根据GPL 2或更高许可授权的代码，是否可以认为该插件不再维护，因为其最新版本是在三年前发布的？

从技术上讲这是合法的。

MIT（外国人）许可证对您设置了一些限制。这些是GPL许可的子集。因此，如果您根据GPL重新授权该代码并保留MIT声明，则您已满足MIT许可证的条款，并可以合法地重新分发该代码。

请注意，您可能不主张版权所有权；您必须承认原始版权。

[edit]有些人似乎不了解F / OSS如何与版权法和许可法结合使用。一切都是从版权开始的，如果仅仅是因为那是默认的。根据版权法，作者有权复制源代码。根据MIT许可，该权利被授予我，以及递归授予他人的权利。请注意，MIT许可证明确包含分许可证的权利。报价："the rights to use, copy, modify, merge, publish,distribute, sublicense, and/or sell"

当我再许可代码时，我无法授予原本没有的权限。就GPL而言，我明确禁止仅对某些权利进行再许可。但是无论是在法律上还是在MIT许可中，我都没有义务对所有权利进行再许可。

因此，MIT许可证授予我明确的再许可权利，而法律和MIT许可证都不禁止我仅对某些权利进行再许可。同样，两者都不限制我的工作形式。因此，我拥有授予该代码GPL分许可证的不可否认的权利。

是。但是效果可能不是您想的那样。

MIT许可证包括GPL赋予的所有权利以及更多。而且，虽然收到您的分发的人员仅会获得您添加的元素的GPL许可，但他们仍会获得MIT许可（由原始作者而非您提供），该许可证由作者根据该许可提供的作品中包含的任何元素。

他们可能不知道这一点，据我所知，没有法律要求您告诉他们。但是，如果他们就您未创作的作品中包含的受保护表达而“违反”了GPL许可（或者不是其他人对仅GPL发行的稿件做出的贡献），则他们没有违反您的许可或版权。（实际上，这应该是很明显的-您只拥有著作权才能创作。）

因此，您尚未将任何可版权保护的元素从MIT许可证转换为GPL许可证。您仅添加了仅在GPL许可下提供的新功能，并在混合/组合工作中发布了这些元素。

在已经给出的答案中，没有任何补充说明，但是这里是有关如何调整源文件头（source）的说明：

2.2将GPL修改添加到许可文件

当开发人员对开发人员将其合并到GPL程序中的许可许可文件进行版权更改时，会发生更为复杂的情况。在这种情况下，开发人员通常将GPL应用于他们的修改。（但是，开发人员可以改用许可性条款来贡献新代码，例如管理未修改文件的许可性许可。我们将在第2.3节中讨论这种情况。）

即使外部项目的许可许可证授予了将该项目的代码合并到GPL's项目中的法律许可，但GPL'd项目的开发人员仍必须遵守许可许可证中的通知保留要求。在使用逐个文件方法的项目中，对许可许可文件进行版权修改的开发人员应在现有文件之前放置新的版权声明和许可声明，并应明确开发人员已修改文件。然后，文件顶部将显示如下：

/*  
 * 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节中描述的方法。