[Buildroot] [RFC v2 00/31] Automatically produce legal compliance info
Luca Ceresoli
luca at lucaceresoli.net
Fri Mar 9 09:12:35 UTC 2012
Thomas De Schampheleire wrote:
[...]
>> However I hit a few issues that still need to be sorted out, see the "ISSUE"
>> sections below.
>>
>> My approach is based on two per-package constants in eack .mk file, such as:
>> FOOBAR_LICENSE = GPLv3 + LGPLv2.1
>> FOOBAR_LICENSE_FILES = COPYING.LGPL demo-app/COPYING.GPL3
>> or:
>> MYAPP_LICENSE = PROPRIETARY
>> # MYAPP_LICENSE_FILES not relevant in this case
>> This is the only effort required to the package creator. If<PKG>_LICENSE is
>> not specified it defaults to "unknown".
>>
>> After running 'make legal-info', the following things will be produced in
>> $(O)/legal-info/:
>> $ find legal-info/ -type f
>> legal-info/README # Lists saved stuff, warns about unsaved stuff
>> legal-info/licenses.txt # Text of all licenses
>> legal-info/buildroot.config # The buildroot config
>> legal-info/licenses/buildroot/COPYING # License files, one dir per pkg
>> legal-info/licenses/busybox/LICENSE # ...
>> legal-info/licenses/...other packages... # ...
>> legal-info/manifest.csv # CSV table summarizing all info
>> legal-info/sources/busybox-1.19.4.tar.bz2 # tarballs
>> legal-info/sources/kmod-5.tar.xz # ...
>> legal-info/sources/libtool-2.2.10.tar.gz # ...
>> legal-info/sources/...other packages... # ...
> I'm a bit confused by licenses.txt: if we already have each individual
> license file in the licenses/<package> directory, why do we need an
> aggregated set in licenses.txt ?
Producing many output formats makes it more likely that one finds his preferred
one...
Consider a product that's shipped without any CD-ROM, and no screen, no GUI, so
no capability to show licenses on-screen. The only way to comply to the GPL
would be to print licenses in the paper documentation. In such a case the
documentation writers would probably prefer to receive a single file they just
need to copy-paste in their typesetting software, fix fonts and title
formatting and they're done. If they were fed 30~40 files to copy-paste from,
add titles or at least separators between each other etc, they would have more
boring work to do, and also error-prone.
>> Given the technical difficulties, the toolchain and the BR sources are not
>> saved. Warnings are generated to make sure the user is aware of this.
>>
>> Following is an explanation of the open issues and future development
>> directions. Actually issue 3 is the one where I mostly would like to have
>> comments, so you may skip to it if your time is limited. Otherwise seat down
>> comfortably and read on.
>>
>>
>> ISSUE 1: the License Repository Feature
>> =======================================
>>
>> The original idea that came out of the last Buildroot Developer Day was to
>> maintain in BR a "license repository" holding those licenses that are used
>> without change by many projects, such as the GPL family.
>> Packages that cannot use this mechanism would need to explicitly define the
>> license file in<PKG>_LICENSE_FILES.
>>
>> The idea of implementation was:
>> if (<PKG>_LICENSE_FILES defined):
>> copy $(<PKG>_LICENSE_FILES)
>> else if (<PKG>_LICENSE = *GPL*, or any other known that's always equal):
>> copy file from a "license repo dir" (one copy only per file);
>> else:
>> copy nothing and warn user
>>
>> Unfortunately, as Will Moore also pointed out, I discovered that the same
>> license (e.g. GPLv2) is not always identical between two packages, although
>> the differences might be not substantial.
>>
>> I do not have precise figures, but the number of variations might be quite
>> large. In a config with ~25 packages enabled I got this:
>> $ make external-deps|wc -l
>> 39
>> $ find . -iname "COPYING*" -o -iname "LICENSE*" | \
>> xargs grep -l 'Version 2,' | xargs md5sum | \
>> awk '{print $1}'|sort|uniq|wc -l
>> 20
>>
>> These are 20 different GPLv2 files! Some only have whitespace changes, some
>> have other little differences. An example:
>>
>> $ diff -u0 -b ./binutils-2.21.1/COPYING ./libtool-2.2.10/COPYING
>> --- ./binutils-2.21.1/COPYING 2005-07-14 03:24:56.000000000 +0200
>> +++ ./libtool-2.2.10/COPYING 2010-05-20 23:18:41.000000000 +0200
>> @@ -4 +4 @@
>> - Copyright (C) 1989, 1991 Free Software Foundation, Inc.
>> + Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
>>
>> An added comma.
>>
>> @@ -18 +18 @@
>> -the GNU Library General Public License instead.) You can apply it to
>> +the GNU Lesser General Public License instead.) You can apply it to
>>
>> This updates a reference to another license.
>>
>> @@ -306,4 +306,3 @@
>> - You should have received a copy of the GNU General Public License
>> - along with this program; if not, write to the Free Software
>> - Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
>> -
>> + You should have received a copy of the GNU General Public License along
>> + with this program; if not, write to the Free Software Foundation, Inc.,
>> + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>>
>> Just formatting changes here.
>>
>> @@ -339 +338 @@
>> -library. If this is what you want to do, use the GNU Library General
>> +library. If this is what you want to do, use the GNU Lesser General
>>
>> Same as above.
>>
>> Another example:
>>
>> $ diff -u0 -b ./binutils-2.21.1/COPYING ./iostat-2.2/LICENSE
>> --- ./binutils-2.21.1/COPYING 2005-07-14 03:24:56.000000000 +0200
>> +++ ./iostat-2.2/LICENSE 2004-11-25 11:53:11.000000000 +0100
>> @@ -5 +5 @@
>> - 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
>> + 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>>
>> Apparently the FSF offices have moved some time in the past.
>>
>> @@ -308 +308 @@
>> - Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
>> + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>>
>> Same as above.
>>
>> I did not investigate a lot to discover if there are more substantial
>> differences. I wanted to stay on the safe side, so I just did not implement the
>> "license repository" and the second step of the algorithm. All packages that
>> want their license files copied must define<PKG>_LICENSE_FILES. Full stop.
>>
>> The license repository feature may still be added in the future, but I think
>> it should be discussed before. Asking the FSF may be an option, I guess they
>> listen to an active community developing free software.
> For me treating each license as a different one is OK. As you say,
> it's for sure the safest option. It will keep the logic in buildroot
> simple.
>
>>
>> ISSUE 2: Packages with multiple licenses
>> ========================================
>>
>> Some packages (e.g. freetype, qt) allow to choose among different licenses.
>> - Should we add an option in menuconfig for choosing the license? This would
>> allow to generate "customized" manifest and license files.
>> - Or should we save all licenses and and define the package license as, for
>> instance:
>> QT_LICENSE = GPLv3 or LGPLv2.1 or COMMERCIAL?
>>
>> I think the first option is more nice and still legally correct, so I
>> implemented it for Qt to see how it would look. You can see the implementation
>> in a patch near the bottom of this set. It's not currently documented at all,
>> I'd first like to know if the approach is good or option 2 (or whatever else)
>> is better.
> In any case, a commercial license cannot be used without having a
> legal agreement with the package author. Since this is a rare case, I
> don't think we should try to handle this in buildroot. I'd let the
> user handle this case.
Yes, I wrote commercial there just for example, I don't think it's
so necessary.
> Personally, I don't think that many people will be careful in
> selecting the appropriate license from the config system. We'd need a
> default, and the question becomes what's the default? Some people will
> prefer v3 and others v2.
> I'd keep it up to the user to fix the csv and related files to reflect
> their choice. We can already copy all licenses as you suggest, but I
> don't know whether a user should remove the non-appropriate files or
> not to be legally ok...
Not sure I agree here. Having a menuconfig knob makes the
user conscious about his right to choose, as well as his "need"
to choose.
Say I release a product using Qt and I distribute it with both
license files, GPLv3 and LGPLv2. Since I also distribute it under
GPLv3 too, can a customer ask me to release the sources for
mt Qt-based proprietary application?
If I have proprietary applications, I would prefer to make things
clear in the beginning, and put only LGPL in my CD, printed
manual, About window, whatever.
[...]
> TODO in the next patchset before merging into mainline
> ======================================================
>
> - Add to the documentation:
> - some words of advice from Buildroot developers about how to comply to GPL
> and other open source licenses;
> - brief instructions on using this stuff ('make legal-info');
> - instructions in the GENTARGETS section about the _LICENSE and _LICENSE_FILES
> constants.
>
> - Write a few lines of explanation in the log message of the first big commit,
> the one that implements all the logic.
>
> - Save a defconfig instead of the whole .config for the Buildroot configuration?
> Which one would you better like?
> A full .config is better I think, as it doesn't depend on the defaults
> in buildroot (e.g. version bump).
Nice to see there's a point everybody agrees on. :-)
Luca
More information about the buildroot
mailing list