A collaborator is arguing that it's a good idea to license one small component of a package under the MIT license, while the rest of it remains GPL >=2. Suppose this is feasible. How do I specify the license? As far as I can tell from https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing the DESCRIPTION file should have License: file LICENSE License_is_FOSS: yes License_restricts_use: no But I can't figure out what should go in the LICENSE file. The one file that contains the MIT-licensed components contains the relevant license text in its body. License: GPL (>=2) | MIT + file LICENSE doesn't seem right, because these are not *alternative* licenses. Would "GPL (>=2) + file LICENSE" be OK? We could explain the situation in LICENSE.note (WRE says "To include comments about the licensing rather than the body of a license, use a file named something like LICENSE.note. ") Could file LICENSE contain The code in this package is licensed under GPL >=2 (see https://www.r-project.org/Licenses/GPL-2, https://www.r-project.org/Licenses/GPL-3, except for <FILE xxx>, which is under the MIT license (see <FILE xxx for details>). ? Happy for advice or pointers to other packages that have successfully done something similar. Looks like igraphdata may have heterogeneous licensing? https://cran.r-project.org/web/packages/igraphdata/index.html Related: https://stackoverflow.com/questions/4314708/if-an-r-packages-licence-x-is-do-all-the-content-in-that-package-have-to-be-li
[R-pkg-devel] best practices for handling a mixed-licensed package
8 messages · Ben Bolker, Hadley Wickham, Dirk Eddelbuettel +1 more
On Fri, Oct 2, 2020 at 1:51 PM Ben Bolker <bbolker at gmail.com> wrote:
A collaborator is arguing that it's a good idea to license one small component of a package under the MIT license, while the rest of it remains GPL >=2. Suppose this is feasible. How do I specify the license? As far as I can tell from https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing the DESCRIPTION file should have License: file LICENSE License_is_FOSS: yes License_restricts_use: no But I can't figure out what should go in the LICENSE file. The one file that contains the MIT-licensed components contains the relevant license text in its body. License: GPL (>=2) | MIT + file LICENSE doesn't seem right, because these are not *alternative* licenses. Would "GPL (>=2) + file LICENSE" be OK? We could explain the situation in LICENSE.note (WRE says "To include comments about the licensing rather than the body of a license, use a file named something like LICENSE.note. ") Could file LICENSE contain The code in this package is licensed under GPL >=2 (see https://www.r-project.org/Licenses/GPL-2, https://www.r-project.org/Licenses/GPL-3, except for <FILE xxx>, which is under the MIT license (see <FILE xxx for details>). ?
I have some recommendations at https://r-pkgs.org/license.html#code-you-bundle, but in brief use License: GPL (>= 2) and then explain in LICENSE.note which components have more liberal licenses. Hadley
http://hadley.nz [[alternative HTML version deleted]]
Hadley offers what you _can_ do, but if you want clarity in the minds of _users_ I would beg you to split the code into two packages. People will likely either be afraid of the GPL bogey man and refrain from utilizing your MIT code as permitted or fail to honor the GPL terms correctly if both are in the same package.
On October 2, 2020 1:16:36 PM PDT, Hadley Wickham <h.wickham at gmail.com> wrote:
On Fri, Oct 2, 2020 at 1:51 PM Ben Bolker <bbolker at gmail.com> wrote:
A collaborator is arguing that it's a good idea to license one
small
component of a package under the MIT license, while the rest of it remains GPL >=2. Suppose this is feasible. How do I specify the license? As far
as I
can tell from
the DESCRIPTION file should have License: file LICENSE License_is_FOSS: yes License_restricts_use: no But I can't figure out what should go in the LICENSE file. The one file that contains the MIT-licensed components contains the relevant license text in its body. License: GPL (>=2) | MIT + file LICENSE doesn't seem right, because these are not *alternative* licenses.
Would
"GPL (>=2) + file LICENSE" be OK? We could explain the situation in LICENSE.note (WRE says "To include comments about the licensing
rather
than the body of a license, use a file named something like LICENSE.note. ") Could file LICENSE contain The code in this package is licensed under GPL >=2 (see https://www.r-project.org/Licenses/GPL-2, https://www.r-project.org/Licenses/GPL-3, except for <FILE xxx>,
which
is under the MIT license (see <FILE xxx for details>). ?
I have some recommendations at https://r-pkgs.org/license.html#code-you-bundle, but in brief use License: GPL (>= 2) and then explain in LICENSE.note which components have more liberal licenses. Hadley
Sent from my phone. Please excuse my brevity.
On 2 October 2020 at 14:44, Jeff Newmiller wrote:
| if you want clarity in the minds of _users_ I would beg you to split the code into two packages. People will likely either be afraid of the GPL bogey man and refrain from utilizing your MIT code as permitted or fail to honor the GPL terms correctly if both are in the same package. Have you read R's own doc/COPYRIGHTS ? https://github.com/wch/r-source/blob/trunk/doc/COPYRIGHTS In short the opposite of what you just suggest. Also, labels such as "more liberal" or "permissive" or "bogey man" are not exactly unambiguous. Different people can and do have different views here. I would suggest using simpler terms such as "different". What matters is that the licenses permit open source use while ensuring they are compatible which is generally the case these days. Dirk
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On Fri, Oct 2, 2020 at 5:26 PM Dirk Eddelbuettel <edd at debian.org> wrote:
On 2 October 2020 at 14:44, Jeff Newmiller wrote: | if you want clarity in the minds of _users_ I would beg you to split the code into two packages. People will likely either be afraid of the GPL bogey man and refrain from utilizing your MIT code as permitted or fail to honor the GPL terms correctly if both are in the same package. Have you read R's own doc/COPYRIGHTS ? https://github.com/wch/r-source/blob/trunk/doc/COPYRIGHTS In short the opposite of what you just suggest. Also, labels such as "more liberal" or "permissive" or "bogey man" are not exactly unambiguous. Different people can and do have different views here. I would suggest using simpler terms such as "different". What matters is that the licenses permit open source use while ensuring they are compatible which is generally the case these days.
I think this is a bit of an oversimplification, especially given that "compatibility" is not symmetric. For example, you can include MIT license code in a GPL licensed package; you can not include GPL licensed code inside an MIT licensed package. There are some rough guidelines at https://r-pkgs.org/license.html#license-compatibility. Hadley
http://hadley.nz [[alternative HTML version deleted]]
On 3 October 2020 at 09:54, Hadley Wickham wrote:
| I think this is a bit of an oversimplification, especially given that | "compatibility" is not symmetric. For example, you can include MIT license | code in a GPL licensed package; you can not include GPL licensed code | inside an MIT licensed package. There are some rough guidelines at | https://r-pkgs.org/license.html#license-compatibility. One approach for issues such as legal matters is to consult subject-matter experts which is why I pointed (in a prior private message spawned by this same thread) to sites such as https://tldrlegal.com/ https://choosealicense.com/ Dirk
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
You are addressing interpretation of "a license", while my concern is not with the licenses themselves but with the identification of which code goes with which license. Assuming that you will need to retain lawyers to decide how to handle a license in a particular use case may be reasonable, but assuming you will also use them to parse the files in the package seems rather less reasonable IMO when you have such a clear alternative (packaging).
On October 3, 2020 9:02:02 AM PDT, Dirk Eddelbuettel <edd at debian.org> wrote:
On 3 October 2020 at 09:54, Hadley Wickham wrote: | I think this is a bit of an oversimplification, especially given that | "compatibility" is not symmetric. For example, you can include MIT license | code in a GPL licensed package; you can not include GPL licensed code | inside an MIT licensed package. There are some rough guidelines at | https://r-pkgs.org/license.html#license-compatibility. One approach for issues such as legal matters is to consult subject-matter experts which is why I pointed (in a prior private message spawned by this same thread) to sites such as https://tldrlegal.com/ https://choosealicense.com/ Dirk
Sent from my phone. Please excuse my brevity.
This is why I recommend that if you copy an entire directory of code you include the LICENSE file for that directory; if you copy a single file, make the license clear at the comment in a top of the file. This is standard practice in most open source communities. If you?re writing open source code, I don?t think it?s necessary to retain a lawyer in order to handle these commonplace issues. (OTOH if you?re building a business on top of open source code, hiring a lawyer is absolutely essential). Hadley On Saturday, October 3, 2020, Jeff Newmiller <jdnewmil at dcn.davis.ca.us> wrote:
You are addressing interpretation of "a license", while my concern is not with the licenses themselves but with the identification of which code goes with which license. Assuming that you will need to retain lawyers to decide how to handle a license in a particular use case may be reasonable, but assuming you will also use them to parse the files in the package seems rather less reasonable IMO when you have such a clear alternative (packaging). On October 3, 2020 9:02:02 AM PDT, Dirk Eddelbuettel <edd at debian.org> wrote:
On 3 October 2020 at 09:54, Hadley Wickham wrote: | I think this is a bit of an oversimplification, especially given that | "compatibility" is not symmetric. For example, you can include MIT license | code in a GPL licensed package; you can not include GPL licensed code | inside an MIT licensed package. There are some rough guidelines at | https://r-pkgs.org/license.html#license-compatibility. One approach for issues such as legal matters is to consult subject-matter experts which is why I pointed (in a prior private message spawned by this same thread) to sites such as https://tldrlegal.com/ https://choosealicense.com/ Dirk
-- Sent from my phone. Please excuse my brevity.
http://hadley.nz [[alternative HTML version deleted]]