Re: [R-pkg-devel] best practices for handling a mixed-licensed package

2020-10-03 Thread Hadley Wickham
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 
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 
> 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]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] best practices for handling a mixed-licensed package

2020-10-03 Thread Jeff Newmiller
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  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.

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] best practices for handling a mixed-licensed package

2020-10-03 Thread Dirk Eddelbuettel


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 | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] best practices for handling a mixed-licensed package

2020-10-03 Thread Hadley Wickham
On Fri, Oct 2, 2020 at 5:26 PM Dirk Eddelbuettel  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]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel