| Message ID | 1382452676-2514-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, Oct 22, 2013 at 4:37 PM, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > U-Boot 2013.10 moved licenses into the Licenses/ directory. > However since we target many versions of u-boot (even non-upstream > versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place > without making mistakes. > So just remove it unforunately. Fixes: > http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/ > > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> > --- > package/uboot-tools/uboot-tools.mk | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk > index e19372a..96d2c8d 100644 > --- a/package/uboot-tools/uboot-tools.mk > +++ b/package/uboot-tools/uboot-tools.mk > @@ -8,7 +8,6 @@ UBOOT_TOOLS_VERSION = 2013.10 > UBOOT_TOOLS_SOURCE = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2 > UBOOT_TOOLS_SITE = ftp://ftp.denx.de/pub/u-boot > UBOOT_TOOLS_LICENSE = GPLv2+ > -UBOOT_TOOLS_LICENSE_FILES = COPYING > Maybe the legal-info target should warn for non-existing files, rather than error out. It seems more logical to support the latest versions than to support none, with respect to _LICENSE_FILES. Those who build older versions of u-boot should see the warning and handle it appropriately. Note that in either case, we can't trust the _LICENSE directive either: a project could change license along the way, and if buildroot allows to select an arbitrary version in the config, the specified LICENSE may be wrong. Best regards, Thomas
On 10/22/2013 11:57 AM, Thomas De Schampheleire wrote: > Maybe the legal-info target should warn for non-existing files, rather > than error out. > It seems more logical to support the latest versions than to support > none, with respect to _LICENSE_FILES. > Those who build older versions of u-boot should see the warning and > handle it appropriately. Yes, that's what i thought, this is the quick fix but maybe not the desired one. > Note that in either case, we can't trust the _LICENSE directive > either: a project could change license along the way, and if buildroot > allows to select an arbitrary version in the config, the specified > LICENSE may be wrong. Looking at Licenses/README in 2013.10 it seems there was some licensing cleanup done and not all the code is guaranteed to be GPLv2*. It's mostly accurate for uboot-tools but may not be so for target u-boot (which isn't covered by this issue, just bringing up the details here). Regards.
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > U-Boot 2013.10 moved licenses into the Licenses/ directory. > However since we target many versions of u-boot (even non-upstream > versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place > without making mistakes. > So just remove it unforunately. Fixes: > http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/ Ehh, we do support multiple versions of u-boot, but only a single version of uboot-tools, so it makes sense to just change it to Licenses/..
On 10/22/2013 01:39 PM, Peter Korsgaard wrote: > Ehh, we do support multiple versions of u-boot, but only a single > version of uboot-tools, so it makes sense to just change it to > Licenses/.. D'oh that's true, i'll fix it. Regards.
Peter Korsgaard <jacmet@uclibc.org> wrote: >>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > > > U-Boot 2013.10 moved licenses into the Licenses/ directory. > > However since we target many versions of u-boot (even non-upstream > > versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place > > without making mistakes. > > So just remove it unforunately. Fixes: > > http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/ > >Ehh, we do support multiple versions of u-boot, but only a single >version of uboot-tools, so it makes sense to just change it to >Licenses/.. Sure, but the mentioned problem remains for uboot proper right?
>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes: Hi, >> Ehh, we do support multiple versions of u-boot, but only a single >> version of uboot-tools, so it makes sense to just change it to >> Licenses/.. > Sure, but the mentioned problem remains for uboot proper right? Indeed, it does.
On 10/22/2013 02:01 PM, Thomas De Schampheleire wrote: >> Ehh, we do support multiple versions of u-boot, but only a single >> version of uboot-tools, so it makes sense to just change it to >> Licenses/.. > > > Sure, but the mentioned problem remains for uboot proper right? The problem is a bit more complicated for uboot proper. The README says the u-boot part is GPL, but some extras (preloaders, etc) might not be, so even if we fail silently to cover the different uboot versions that might not be enough (i.e. GPL won't be enough depending on the target). Regards.
Dear Thomas De Schampheleire, On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote: > Maybe the legal-info target should warn for non-existing files, rather > than error out. I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb ("legal-info: fail trying to copy a non-existent license file"), what was happening is exactly what you're suggesting. The problem is that we didn't notice when legal information were wrong, because nobody looks at warnings, and because autobuilders result were saying "OK" even though the legal info wasn't ok. So at the time (back in May this year), we discussed that, and we agreed that legal-info should error out if it cannot find a license file referenced by <pkg>_LICENSE_FILES, so that autobuilder results loudly say that something failed. And interestingly, the precise reason why we noticed the legal-info were wrong was because the autobuilder build failed, and we fixed it. I very much prefer that than having the <pkg>_LICENSE_FILES remain wrong for many weeks/months without anybody noticing. Best regards, Thomas
Hi Thomas, On Wed, Oct 23, 2013 at 11:39 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Thomas De Schampheleire, > > On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote: > >> Maybe the legal-info target should warn for non-existing files, rather >> than error out. > > I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb > ("legal-info: fail trying to copy a non-existent license file"), what > was happening is exactly what you're suggesting. > > The problem is that we didn't notice when legal information were wrong, > because nobody looks at warnings, and because autobuilders result were > saying "OK" even though the legal info wasn't ok. So at the time (back > in May this year), we discussed that, and we agreed that legal-info > should error out if it cannot find a license file referenced by > <pkg>_LICENSE_FILES, so that autobuilder results loudly say that > something failed. > > And interestingly, the precise reason why we noticed the legal-info > were wrong was because the autobuilder build failed, and we fixed it. I > very much prefer that than having the <pkg>_LICENSE_FILES remain wrong > for many weeks/months without anybody noticing. My comment was too one-sided. I still agree with the commit that changed the warning into an error. But now we are in a special situation: for packages that support multiple versions, we currently assume that these all have the same LICENSE and LICENSE_FILES, which is not necessarily true. For such packages, we _expect_ that the LICENSE_FILES definition will not be correct for some versions, and this will cause buildroot to fail on the legal-info. However, we cannot simply fix that failure by changing LICENSE_FILES, because it will fail on the other versions. We could envision a strategy where we can pass some version annotation to LICENSE(_FILES) that the legal-info infrastructure can recognize, which would work for packages with known versions only. However, in the case of linux, u-boot, and probably others, we allow the user to specify an arbitrary version, for which we don't know the license unless with some deeper checking of the base version. Maybe this last case is more of an exception, and we should warn the user that we are not sure which license to use if he is using an arbitrary version. Best regards, Thomas
Thomas De Schampheleire <patrickdepinguin@gmail.com> ha scritto: >Hi Thomas, > >On Wed, Oct 23, 2013 at 11:39 AM, Thomas Petazzoni ><thomas.petazzoni@free-electrons.com> wrote: >> Dear Thomas De Schampheleire, >> >> On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote: >> >>> Maybe the legal-info target should warn for non-existing files, >rather >>> than error out. >> >> I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb >> ("legal-info: fail trying to copy a non-existent license file"), what >> was happening is exactly what you're suggesting. >> >> The problem is that we didn't notice when legal information were >wrong, >> because nobody looks at warnings, and because autobuilders result >were >> saying "OK" even though the legal info wasn't ok. So at the time >(back >> in May this year), we discussed that, and we agreed that legal-info >> should error out if it cannot find a license file referenced by >> <pkg>_LICENSE_FILES, so that autobuilder results loudly say that >> something failed. >> >> And interestingly, the precise reason why we noticed the legal-info >> were wrong was because the autobuilder build failed, and we fixed it. >I >> very much prefer that than having the <pkg>_LICENSE_FILES remain >wrong >> for many weeks/months without anybody noticing. > >My comment was too one-sided. I still agree with the commit that >changed the warning into an error. >But now we are in a special situation: for packages that support >multiple versions, we currently assume that these all have the same >LICENSE and LICENSE_FILES, which is not necessarily true. For such >packages, we _expect_ that the LICENSE_FILES definition will not be >correct for some versions, and this will cause buildroot to fail on >the legal-info. However, we cannot simply fix that failure by changing >LICENSE_FILES, because it will fail on the other versions. > >We could envision a strategy where we can pass some version annotation >to LICENSE(_FILES) that the legal-info infrastructure can recognize, >which would work for packages with known versions only. >However, in the case of linux, u-boot, and probably others, we allow >the user to specify an arbitrary version, for which we don't know the >license unless with some deeper checking of the base version. Maybe >this last case is more of an exception, and we should warn the user >that we are not sure which license to use if he is using an arbitrary >version. Instead of special annotations in the _LICENSE* fields, I think we have two better options. First, we may conditionally define _LICENSE* fields based on versions. Simple, but this would never handle cases where the bootloader or kernel is obtained from a custom git repo. Or we may override the <pkg>-legal-info target for those few packages. The overridden target may do anything, e.g. try to copy a license file and, if not found, copy another one, failing only if both are missing. Or it could launch a script doing fancy things... Not tried any of the two, but I feel the latter is more flexible and still quite simple in terms of infrastructure. Both would let the "normal" packages be handled in the old, simple way.
On 24/10/13 10:20, Luca Ceresoli wrote: > > > Thomas De Schampheleire <patrickdepinguin@gmail.com> ha scritto: >> Hi Thomas, >> >> On Wed, Oct 23, 2013 at 11:39 AM, Thomas Petazzoni >> <thomas.petazzoni@free-electrons.com> wrote: >>> Dear Thomas De Schampheleire, >>> >>> On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote: >>> >>>> Maybe the legal-info target should warn for non-existing files, >> rather >>>> than error out. >>> >>> I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb >>> ("legal-info: fail trying to copy a non-existent license file"), what >>> was happening is exactly what you're suggesting. >>> >>> The problem is that we didn't notice when legal information were >> wrong, >>> because nobody looks at warnings, and because autobuilders result >> were >>> saying "OK" even though the legal info wasn't ok. So at the time >> (back >>> in May this year), we discussed that, and we agreed that legal-info >>> should error out if it cannot find a license file referenced by >>> <pkg>_LICENSE_FILES, so that autobuilder results loudly say that >>> something failed. >>> >>> And interestingly, the precise reason why we noticed the legal-info >>> were wrong was because the autobuilder build failed, and we fixed it. >> I >>> very much prefer that than having the <pkg>_LICENSE_FILES remain >> wrong >>> for many weeks/months without anybody noticing. >> >> My comment was too one-sided. I still agree with the commit that >> changed the warning into an error. >> But now we are in a special situation: for packages that support >> multiple versions, we currently assume that these all have the same >> LICENSE and LICENSE_FILES, which is not necessarily true. For such >> packages, we _expect_ that the LICENSE_FILES definition will not be >> correct for some versions, and this will cause buildroot to fail on >> the legal-info. However, we cannot simply fix that failure by changing >> LICENSE_FILES, because it will fail on the other versions. >> >> We could envision a strategy where we can pass some version annotation >> to LICENSE(_FILES) that the legal-info infrastructure can recognize, >> which would work for packages with known versions only. >> However, in the case of linux, u-boot, and probably others, we allow >> the user to specify an arbitrary version, for which we don't know the >> license unless with some deeper checking of the base version. Maybe >> this last case is more of an exception, and we should warn the user >> that we are not sure which license to use if he is using an arbitrary >> version. > > Instead of special annotations in the _LICENSE* fields, I think we have two better options. > > First, we may conditionally define _LICENSE* fields based on versions. Simple, but this would never handle cases where the bootloader or kernel is obtained from a custom git repo. > > Or we may override the <pkg>-legal-info target for those few packages. The overridden target may do anything, e.g. try to copy a license file and, if not found, copy another one, failing only if both are missing. Or it could launch a script doing fancy things... > > Not tried any of the two, but I feel the latter is more flexible and still quite simple in terms of infrastructure. Both would let the "normal" packages be handled in the old, simple way. The U-Boot issue is actually a symptom of a deeper problem: for situations where the user is able to change the source of a package, our license info may be incorrect. So it's not just about LICENSE_FILES, but also about the license itself. I don't think it's worth to spend much effort in dealing with variant licenses. Instead, it's more useful to detect situations where our license information is incorrect and mark it like that in the legal info. So where can the user override the source of a package? * _OVERRIDE_SRCDIR: I think we should add a warning to the manifest that the license information may be incorrect. * Custom versions of U-Boot, barebox, mxs-bootlets, linux - am I forgetting anything? I think we should treat these the same as _OVERRIDE_SRCDIR: put a warning in the manifest file. * External toolchains: we don't cover these anyway. * Patches passed in through package-specific config variables (e.g. linux and many bootloaders) or throught GLOBAL_PATCH_DIR: here we have to assume that the user knows what he's doing, but it would be good to add a reminder in the README if GLOBAL_PATCH_DIR or any of the other patch config variables is set (actually I would prefer to deprecate the other patch config variables and force users to switch to GLOBAL_PATCH_DIR). Anything else? Now, for the specific case of U-Boot, we can do better: if _VERSION is 2013.10 or larger, we can use the new license specification, else the old one (and due to U-Boot's versioning policy we can just use sort; custom has to be handled separately anyway). But another issue is that the license that we specify is just plain wrong (as so often): all the U-Boot versions contain code that is GPLv2 without + and that is BSD-3c, some also contain code that is eCos-2.0, IBM-pibs, LGPL. So we should probably fix the license spec for U-Boot regardless of where it comes from. Regards, Arnout
On 10/24/2013 09:24 AM, Arnout Vandecappelle wrote: > Now, for the specific case of U-Boot, we can do better: if _VERSION is > 2013.10 or larger, we can use the new license specification, else the > old one (and due to U-Boot's versioning policy we can just use sort; > custom has to be handled separately anyway). We don't use version choices any more, just a recommended version string, so matching might not be that easy. And there's custom tarball / git repo / etc too. > But another issue is that the license that we specify is just plain > wrong (as so often): all the U-Boot versions contain code that is GPLv2 > without + and that is BSD-3c, some also contain code that is eCos-2.0, > IBM-pibs, LGPL. So we should probably fix the license spec for U-Boot > regardless of where it comes from. The U-Boot licenses that apply rely on the selected target too which complicates things. I don't think we want to become license police here other than "one or more of X, Y, ..., please do your homework". Regards.
On 24/10/13 14:35, Gustavo Zacarias wrote: > On 10/24/2013 09:24 AM, Arnout Vandecappelle wrote: >> Now, for the specific case of U-Boot, we can do better: if _VERSION is >> 2013.10 or larger, we can use the new license specification, else the >> old one (and due to U-Boot's versioning policy we can just use sort; >> custom has to be handled separately anyway). > > We don't use version choices any more, just a recommended version > string, so matching might not be that easy. We don't? Then what does BR2_TARGET_UBOOT_CUSTOM_VERSION do? > And there's custom tarball / git repo / etc too. Exactly, for these the other considerations still apply. > >> But another issue is that the license that we specify is just plain >> wrong (as so often): all the U-Boot versions contain code that is GPLv2 >> without + and that is BSD-3c, some also contain code that is eCos-2.0, >> IBM-pibs, LGPL. So we should probably fix the license spec for U-Boot >> regardless of where it comes from. > > The U-Boot licenses that apply rely on the selected target too which > complicates things. > I don't think we want to become license police here other than "one or > more of X, Y, ..., please do your homework". I agree completely. But currently it just says GPLv2+, which is plain wrong. Regards, Arnout > Regards. > >
diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk index e19372a..96d2c8d 100644 --- a/package/uboot-tools/uboot-tools.mk +++ b/package/uboot-tools/uboot-tools.mk @@ -8,7 +8,6 @@ UBOOT_TOOLS_VERSION = 2013.10 UBOOT_TOOLS_SOURCE = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2 UBOOT_TOOLS_SITE = ftp://ftp.denx.de/pub/u-boot UBOOT_TOOLS_LICENSE = GPLv2+ -UBOOT_TOOLS_LICENSE_FILES = COPYING define UBOOT_TOOLS_BUILD_CMDS $(MAKE) -C $(@D) \
U-Boot 2013.10 moved licenses into the Licenses/ directory. However since we target many versions of u-boot (even non-upstream versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place without making mistakes. So just remove it unforunately. Fixes: http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/ Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- package/uboot-tools/uboot-tools.mk | 1 - 1 file changed, 1 deletion(-)