2008年7月に最新リリースがあった Chiliプラグイン のコードを変更することは可能であり、MITライセンスの下でライセンスされています。 GPLの下で?
私の知る限り、同じライセンスでライセンスされる新しいコードについての制限はありません。それは本当にそうですか、それとも最小限の変更がありますか?
私の場合、CMSで実行される通常のJavascriptコードでjQueryプラグインを変更します。これは本質的に、とりわけ次のことを意味します。
$($element).chili()
ではなくGlobalObject.ChiliHighlighter.process($jquery_element)
として呼び出されます。「GlobalObject」はCMSから使用されるJavaScriptオブジェクトです。GlobalObject.ChiliHighlighter
_オブジェクトを変更して、定義時にGlobalObject.ChiliHighlighter.process()
からオプションで呼び出される関数を追加できるようになります。別の方法として、使用しているリポジトリでは、コードがメンテナンスされなくなったときにGPL 2以降のライセンスでライセンスされていないコードを含めることができるため、プラグインは、その最後のバージョンが3年前にリリースされたため、もうメンテナンスされていないと見なされますか?
技術的には合法です。
MIT(Expat)ライセンスはいくつかの制限を課します。これらはGPLライセンスのサブセットです。したがって、GPLの下でコードを再ライセンスすると、とMIT通知を保持すると、MITライセンスの条件を満たし、合法的に再配布できる場合があります。コード。
著作権の所有権を主張することはできません。元の著作権を確認する必要があります。
[編集]一部の人々は、F/OSSが著作権およびライセンス法と連携してどのように機能するかを理解していないようです。すべてが著作権から始まりますが、それがデフォルトだからです。著作権の原則に基づいて、作成者はソースコードのコピーを作成する権利を取得します。 MITライセンスの下で、その権利は私に付与され、また他の人に再帰的に付与する権利も付与されます。MITライセンス明示的にはサブライセンスの権利を含みます。引用:"the rights to use, copy, modify, merge, publish,distribute,
sublicense,
and/or sell"
コードのサブライセンスを取得すると、本来持っていなかった権限を付与できません。 GPLの場合、私はexplicitly一部の権利のみをサブライセンスすることを禁じられています。しかし、法律でもMIT=ライセンスでも、私にはすべての権利を全体としてサブライセンスする義務がありますか?.
したがって、MITライセンスはサブライセンスの権利を私に明示的に付与し、法律もMITライセンスもサブライセンスのみを禁止しませんsome権利。また、どちらも私が行う形式を制限しないため、そのコードにGPLサブライセンスを付与する否認できない権利があります。
はい。しかし、その効果はあなたが思っているものとは違うかもしれません。
MITライセンスには、GPLが付与するすべての権利などが含まれます。また、ディストリビューションを受け取った人は、追加した要素に対してのみGPLライセンスを受け取りますが、MITライセンス(あなたからではなく、元の著者から)が、そのライセンスに基づいて著者が提供した作品に含まれるすべての要素。
彼らはこれを知らないかもしれません、そして私が知る限りでは、どの法律もあなたに彼らに話すことを義務づけません。しかし、あなたが作成していない(または他の人がGPLのみのリリースに貢献していない)作品に含まれる保護可能な表現に関してGPLライセンスに「違反」している場合、彼らはあなたのライセンスまたは著作権に違反していません。 (実際、それはかなり明白なはずです-あなたは自分が書いた表現に対する著作権のみを保持します。)
つまり、MITライセンスからGPLライセンスに著作権で保護されている要素を変換していません。GPLライセンスでのみ提供される新しい要素を追加し、混合/組み合わせ作業。
すでに与えられた回答の説明に追加するものはありませんが、ここにソースファイルヘッダーを整形する方法の指示があります( source =):
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で説明されている方法を使用する必要があります。