From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Ceresoli Date: Wed, 02 Oct 2013 18:33:24 +0200 Subject: [Buildroot] Some legal-info observations/problems In-Reply-To: <20131002172307.0d6f02ea@skate> References: <20131002172307.0d6f02ea@skate> Message-ID: <524C4AD4.9040902@lucaceresoli.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Dear ThomasDe Schampheleire, thanksfor the comments and detailed analysis. Find my comments below. Thomas Petazzoni wrote: > Dear Thomas De Schampheleire, > > (Skipping items 2 and 3, since they have been solved apparently.) > > On Wed, 2 Oct 2013 16:06:13 +0200, Thomas De Schampheleire wrote: > >> 1. there is no longer a provision to 'hide' proprietary packages from >> the manifest, and not get warnings on them. Previously you could mark >> a package as license: PROPRIETARY, but this has been removed. I still >> think that a similar feature is useful. > _REDISTRIBUTE = NO > > is what you're looking for, no? No,_REDISTRIBUTEonly prevents the source tarballfrom beingcopied. At the beginning we had a magic value: FOO_LICENSE = PROPRIETARY which would prevent /any/ info from being generated for FOO. Then we preferred to separatethingsfor license declaration (_LICENSE*)and source tarball copying trigger (_REDISTRIBUTE). I still think this change was good and it cleaned up a lot the code, so I wonldn't step back. Three ideas pop up in my mind. Option 1:introduce a new tag such as: FOO_SAVE_LEGAL_INFO = {YES|NO} defaulting to YES.If NO, nothing is saved for FOO: no manifest, no licenses.txt, no source tarball (and FOO_REDISTRIBUTE ignored). This somehow mimics the old behaviour, but with a new variable in lieu of a magic value. option 2, slightly different: FOO_LIST_IN_MANIFEST= {YES|NO} defaulting to YES.If NO, nothing is saved for the package in manifest and licenses.txt, but FOO_REDISTRIBUTE tells whether the source tarball is to be saved. The latter mode would keep things separate and orthogonal, which is cleaner. But it's probably infrequent that people want to save one part of the info and not the other. option 3, a mix the other two: FOO_SAVE_LEGAL_INFO = {YES|NO}, default YES FOO_REDISTRIBUTE= {YES|NO}, default $(FOO_SAVE_LEGAL_INFO) Meaning: * by default FOO_SAVE_LEGAL_INFO rules it all, and we do the same thing for manifest+licenses.txt and source tarball copying (save all or save nothing); * the two can be forced to behave differently by defining FOO_REDISTRIBUTE with a value opposite to FOO_SAVE_LEGAL_INFO. Comments? >> 4. Suppose that a package has no license files and explicitly declares >> this with FOO_LICENSE_FILES = >> In this case, you will still get a warning: "cannot save license >> (FOO_LICENSE_FILES not defined)", but in fact it is simply empty. >> I think it would be better to distinghuish the situation 'empty' and >> 'not defined'. > Agreed. However, in make, doing FOOBAR = or not defining FOOBAR leads > to the same thing: FOOBAR is an empty variable. So we have to decide on > an explicit magic value to use when no license files are available (and > ensure this magic value is never going to be used for the name of a > license file). > > FOO_LICENSE_FILES = N/A > FOO_LICENSE_FILES = not-available > FOO_LICENSE_FILES = none > FOO_LICENSE_FILES = NONE It's not clear to me whether this is the correct way to address the problem of packages having license file. I think usually that means they /do/ have a license, but it's only written in the top lines of source files and/or in a README containing other stuff. IOW, the license text is there, but we currently have no way to extract it. This topic was discussed with the first round of implementation of the legal-info stuff, sometime around FOSDEM 2012. At that time we concluded we could leave out this quite rare case. Unfortunately they are not so rare, so should we invent something now to handle them? Is it worth the effort? Some options are: * manually copy the license snippet in package/foo/COPYING and set FOO_LICENSE_FILES = $(TOPDIR)/package/foo/COPYING(just an idea, may not actually work);this would require checking if our file is in line with upstream at each version bump; * writing in FOO_LICENSE_FILES some instruction for BR to go in the sources and grab the snippet; say: FOO_LICENSE_FILES = src/foo-main.c at 20+14 meaning: pick 14 lines starting at line 20 from src/foo-main.c and that's your license text; * do nothing. I'm not super-happy with any of these, so I'm very open to discussionand other ideas. >> 5. the manifest also lists all host packages, like automake, autoconf, >> ... while these are not distributed on target. Strictly speaking you >> do not have to list these in the customer documentation of a product, >> in my interpretation. I find it confusing that both target and host >> packages are mixed like that. >> Of course, it's probably difficult to change this, because some >> packages can be built for host _and_ target, and the legal-info >> infrastructure does not know which of these was used for a particular >> project. > I think we discussed that the legal-info for target and host packages > should be separated: either the CSV should mention whether it's used > for the target or the host (or both), or there should be two separate > CSV files. Yeah, we did.it's on my todo list, but not quite getting close to the top ofit... -- Luca