| Message ID | 1454443064-14269-6-git-send-email-fhunleth@troodon-software.com |
|---|---|
| State | Accepted |
| Headers | show |
Hi Frank, All, Le 02/02/2016 20:57, Frank Hunleth a écrit : > Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> > --- > package/erlang-rebar/erlang-rebar.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/erlang-rebar/erlang-rebar.mk b/package/erlang-rebar/erlang-rebar.mk > index f29eb75..06a7800 100644 > --- a/package/erlang-rebar/erlang-rebar.mk > +++ b/package/erlang-rebar/erlang-rebar.mk > @@ -4,7 +4,7 @@ > # > ################################################################################ > > -ERLANG_REBAR_VERSION = 2.5.1 > +ERLANG_REBAR_VERSION = 2.6.1 > > # Upstream publishes a release, but we can not use it as it is a release of > # a generated rebar script, when we want the sources. So we have to use the > There is an error with the variable used for licensing: s/ERLANG_LICENSE/ERLANG_REBAR_LICENSE/ Otherwise the license file and license type are not defined and produce a warning with legal-info: # WARNING: erlang-rebar: cannot save license (HOST_ERLANG_REBAR_LICENSE_FILES not defined) Also it override the one defined in erlang package :-/ Best regards, Romain
Hi Romain, On Sat, Feb 6, 2016 at 5:39 PM, Romain Naour <romain.naour@gmail.com> wrote: > Hi Frank, All, > > Le 02/02/2016 20:57, Frank Hunleth a écrit : >> Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> >> --- >> package/erlang-rebar/erlang-rebar.mk | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/package/erlang-rebar/erlang-rebar.mk b/package/erlang-rebar/erlang-rebar.mk >> index f29eb75..06a7800 100644 >> --- a/package/erlang-rebar/erlang-rebar.mk >> +++ b/package/erlang-rebar/erlang-rebar.mk >> @@ -4,7 +4,7 @@ >> # >> ################################################################################ >> >> -ERLANG_REBAR_VERSION = 2.5.1 >> +ERLANG_REBAR_VERSION = 2.6.1 >> >> # Upstream publishes a release, but we can not use it as it is a release of >> # a generated rebar script, when we want the sources. So we have to use the >> > > There is an error with the variable used for licensing: > s/ERLANG_LICENSE/ERLANG_REBAR_LICENSE/ Good catch. Will be fixed in the next patch set. 'make legal-info' now gives no erlang related warnings or errors for me. > > Otherwise the license file and license type are not defined and produce a > warning with legal-info: > > # WARNING: erlang-rebar: cannot save license (HOST_ERLANG_REBAR_LICENSE_FILES > not defined) > > Also it override the one defined in erlang package :-/ > > Best regards, > Romain
Romain, Frank, On Sat, 6 Feb 2016 23:39:28 +0100, Romain Naour wrote: > > -ERLANG_REBAR_VERSION = 2.5.1 > > +ERLANG_REBAR_VERSION = 2.6.1 > > > > # Upstream publishes a release, but we can not use it as it is a release of > > # a generated rebar script, when we want the sources. So we have to use the > > > > There is an error with the variable used for licensing: > s/ERLANG_LICENSE/ERLANG_REBAR_LICENSE/ > > Otherwise the license file and license type are not defined and produce a > warning with legal-info: > > # WARNING: erlang-rebar: cannot save license (HOST_ERLANG_REBAR_LICENSE_FILES > not defined) > > Also it override the one defined in erlang package :-/ I've fixed this in the master branch, since this is really a bug. See commit https://git.busybox.net/buildroot/commit/?id=498055a8c2e66a8a36b6205555b1c7e806b4d31f. However, I am not sure about the license information of erlang-rebar. We currently have: # Although the file LICENSE state Apache-2.0, a lot (if not all) the files # in src/ bear the MIT licence. ERLANG_LICENSE = Apache-2.0, MIT ERLANG_LICENSE_FILES = LICENSE But the LICENSE file is really only the text of Apache-2.0. It is not because many of the source files carry the MIT license that the whole is not licensed under Apache-2.0. The MIT license is a permissive license, so MIT code can be included into a project that is redistributed only under the Apache 2.0 license. (I've added Yann and Luca in Cc to get their opinion on the matter.) Thanks! Thomas
Thomas, All On 2016-02-20 18:37 +0100, Thomas Petazzoni spake thusly: [--SNIP--] > However, I am not sure about the license information of erlang-rebar. > We currently have: > > # Although the file LICENSE state Apache-2.0, a lot (if not all) the files > # in src/ bear the MIT licence. > ERLANG_LICENSE = Apache-2.0, MIT > ERLANG_LICENSE_FILES = LICENSE > > But the LICENSE file is really only the text of Apache-2.0. It is not > because many of the source files carry the MIT license that the whole > is not licensed under Apache-2.0. The MIT license is a permissive > license, so MIT code can be included into a project that is > redistributed only under the Apache 2.0 license. IANAL, TTYL and so on... ;-) Well, that's not how licensing works. Individual files have their own licenses, and they retain those licenses even when they are combined together. So, if you have two files under two licenses, like so: file-1.c MIT file-2.c Apache-2.0 If the two licenses are "compatible", then you are allowed to combine the two files to produce a derived work. That derived work is then governed by both licenses. In effect, the most stringent license will dominate, but the other will still apply. Let's take two hypotetical licenses: - the Hello License, which states: If you use that file, you must say Hello to the closest Human being. - the Tea-Now License, which states: If you use that file, you must drink a tea now. Those two licenses are compatible (i.e. you can say Hello and drink a tea), so you can combine them. Still, you have to do both, not either. So yes, we need to specify *all* the licenses that govern files used to generate the output. Note that the licenses list in Buildroot is to be interpreted as: The combined work generated from this package is governed by those licenses. It is not to be interpreted as: You may redistribute the combined work of this program under those licenses. Regards, Yann E. MORIN.
Dear Frank Hunleth, On Tue, 2 Feb 2016 14:57:31 -0500, Frank Hunleth wrote: > Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> > --- > package/erlang-rebar/erlang-rebar.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to next, thanks. Thomas
Dear Thomas, Thanks for applying some of the Erlang patches. I've had a really busy week, but as soon as I get back today, I'll see what's missing and send a patch set with any residual changes that didn't make your cut. I know that I had several changes that various people had requested. Thanks, Frank > On Feb 20, 2016, at 1:24 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > > Dear Frank Hunleth, > >> On Tue, 2 Feb 2016 14:57:31 -0500, Frank Hunleth wrote: >> Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> >> --- >> package/erlang-rebar/erlang-rebar.mk | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Applied to next, thanks. > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com
Hello Frank, On Sat, 20 Feb 2016 13:31:47 -0500, Frank Hunleth wrote: > Thanks for applying some of the Erlang patches. I've had a really > busy week, but as soon as I get back today, I'll see what's missing > and send a patch set with any residual changes that didn't make your > cut. I know that I had several changes that various people had > requested. No problem. I've applied all of them, but had to do some changes on a few of them (I've replied to each patch individually to let you know). Please double check my change on the fast_tls vs. p1-tls dependency change in p1-stun. I have left on the side the ejabberd update for the moment, since Romain had some comments. I'll mark this patch as "Changes Requested", so please respin. Regarding the erlang atomic operations patch, I haven't had a look yet. Best regards, Thomas
On 02/20/16 19:08, Yann E. MORIN wrote: > Thomas, All > > On 2016-02-20 18:37 +0100, Thomas Petazzoni spake thusly: > [--SNIP--] >> However, I am not sure about the license information of erlang-rebar. >> We currently have: >> >> # Although the file LICENSE state Apache-2.0, a lot (if not all) the files >> # in src/ bear the MIT licence. >> ERLANG_LICENSE = Apache-2.0, MIT >> ERLANG_LICENSE_FILES = LICENSE >> >> But the LICENSE file is really only the text of Apache-2.0. It is not >> because many of the source files carry the MIT license that the whole >> is not licensed under Apache-2.0. The MIT license is a permissive >> license, so MIT code can be included into a project that is >> redistributed only under the Apache 2.0 license. > > IANAL, TTYL and so on... ;-) > > Well, that's not how licensing works. > > Individual files have their own licenses, and they retain those licenses > even when they are combined together. So, if you have two files under > two licenses, like so: > file-1.c MIT > file-2.c Apache-2.0 Actually, I think it's not really the files that carry a license. It is how you got it. This shows in packages that are dual licensed (i.e., with an OR), where it is possible that you got it under only one of those licenses (e.g. because it was combined with another work that puts constraints on it). And unfortunately, it is not very clear under which license you received the code when you got it through a combined work. You _could_ claim that because you received these files as part of the erlang-rebar package, you have only received file-1.c under the MIT license. However, you could also claim that the distributors of erlang-rebar never intended to change the license of file-1.c, so that that individual file can still be used under the MIT license. So: situation is not clear IMHO. > If the two licenses are "compatible", then you are allowed to combine > the two files to produce a derived work. That derived work is then > governed by both licenses. In effect, the most stringent license will > dominate, but the other will still apply. > > Let's take two hypotetical licenses: > > - the Hello License, which states: If you use that file, you must say > Hello to the closest Human being. > > - the Tea-Now License, which states: If you use that file, you must > drink a tea now. > > Those two licenses are compatible (i.e. you can say Hello and drink a > tea), so you can combine them. Still, you have to do both, not either. > > So yes, we need to specify *all* the licenses that govern files used to > generate the output. > > Note that the licenses list in Buildroot is to be interpreted as: > The combined work generated from this package is governed by those > licenses. I don't think we can put that strong a claim, I think it is: the combined work generated from this package may be governed by those licenses. One example where the 'may' is important is when you configured out some file, and that was the only file under a particular license, then that license doesn't apply anymore to the combined work. Regards, Arnout > > It is not to be interpreted as: > You may redistribute the combined work of this program under those > licenses. > > Regards, > Yann E. MORIN. >
Arnout, All, On 2016-02-21 00:05 +0100, Arnout Vandecappelle spake thusly: > On 02/20/16 19:08, Yann E. MORIN wrote: [--SNIP--] > > Well, that's not how licensing works. > > > > Individual files have their own licenses, and they retain those licenses > > even when they are combined together. So, if you have two files under > > two licenses, like so: > > file-1.c MIT > > file-2.c Apache-2.0 > > Actually, I think it's not really the files that carry a license. It is how you > got it. This shows in packages that are dual licensed (i.e., with an OR), where > it is possible that you got it under only one of those licenses (e.g. because it > was combined with another work that puts constraints on it). Again, IANAL, TTYL, and so on... However, if some "other work" puts constraints on the file, then that file still retains its own license; the rights you had under that license are just diminished by those "constraints" of the license for that "other work". > And unfortunately, it is not very clear under which license you received the > code when you got it through a combined work. You _could_ claim that because you > received these files as part of the erlang-rebar package, you have only received > file-1.c under the MIT license. However, you could also claim that the > distributors of erlang-rebar never intended to change the license of file-1.c, > so that that individual file can still be used under the MIT license. So: > situation is not clear IMHO. No, it's definitely not clear, as all licensing issues! :-) Still, I think we should not take the responisibility to do such an in-depth licensing analysis, and that we should dtride of the safe side by just listing all those licenses that apply (see below). > > If the two licenses are "compatible", then you are allowed to combine > > the two files to produce a derived work. That derived work is then > > governed by both licenses. In effect, the most stringent license will > > dominate, but the other will still apply. > > > > Let's take two hypotetical licenses: > > > > - the Hello License, which states: If you use that file, you must say > > Hello to the closest Human being. > > > > - the Tea-Now License, which states: If you use that file, you must > > drink a tea now. > > > > Those two licenses are compatible (i.e. you can say Hello and drink a > > tea), so you can combine them. Still, you have to do both, not either. > > > > So yes, we need to specify *all* the licenses that govern files used to > > generate the output. > > > > Note that the licenses list in Buildroot is to be interpreted as: > > The combined work generated from this package is governed by those > > licenses. > > I don't think we can put that strong a claim, I think it is: the combined work > generated from this package may be governed by those licenses. > > One example where the 'may' is important is when you configured out some file, > and that was the only file under a particular license, then that license doesn't > apply anymore to the combined work. I see your point. But we usually try to make that license conditional in this case, like dtc, ffmpeg, kmod and a few others. Not saying that we always do so, but we tend to. Regards, Yann E. MORIN.
On 02/21/16 00:19, Yann E. MORIN wrote: > Arnout, All, > > On 2016-02-21 00:05 +0100, Arnout Vandecappelle spake thusly: >> On 02/20/16 19:08, Yann E. MORIN wrote: > [--SNIP--] >>> Well, that's not how licensing works. >>> >>> Individual files have their own licenses, and they retain those licenses >>> even when they are combined together. So, if you have two files under >>> two licenses, like so: >>> file-1.c MIT >>> file-2.c Apache-2.0 >> >> Actually, I think it's not really the files that carry a license. It is how you >> got it. This shows in packages that are dual licensed (i.e., with an OR), where >> it is possible that you got it under only one of those licenses (e.g. because it >> was combined with another work that puts constraints on it). > > Again, IANAL, TTYL, and so on... > > However, if some "other work" puts constraints on the file, then that > file still retains its own license; the rights you had under that > license are just diminished by those "constraints" of the license for > that "other work". > >> And unfortunately, it is not very clear under which license you received the >> code when you got it through a combined work. You _could_ claim that because you >> received these files as part of the erlang-rebar package, you have only received >> file-1.c under the MIT license. However, you could also claim that the >> distributors of erlang-rebar never intended to change the license of file-1.c, >> so that that individual file can still be used under the MIT license. So: >> situation is not clear IMHO. > > No, it's definitely not clear, as all licensing issues! :-) > > Still, I think we should not take the responisibility to do such an > in-depth licensing analysis, and that we should dtride of the safe side > by just listing all those licenses that apply (see below). +1 to that. Regards, Arnout [snip]
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> No, it's definitely not clear, as all licensing issues! :-) >> >> Still, I think we should not take the responisibility to do such an >> in-depth licensing analysis, and that we should dtride of the safe side >> by just listing all those licenses that apply (see below). > +1 to that. Yes, agreed. We're after all developers, not lawyers ;)
diff --git a/package/erlang-rebar/erlang-rebar.mk b/package/erlang-rebar/erlang-rebar.mk index f29eb75..06a7800 100644 --- a/package/erlang-rebar/erlang-rebar.mk +++ b/package/erlang-rebar/erlang-rebar.mk @@ -4,7 +4,7 @@ # ################################################################################ -ERLANG_REBAR_VERSION = 2.5.1 +ERLANG_REBAR_VERSION = 2.6.1 # Upstream publishes a release, but we can not use it as it is a release of # a generated rebar script, when we want the sources. So we have to use the
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com> --- package/erlang-rebar/erlang-rebar.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)