From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17550 invoked by alias); 23 Apr 2012 22:21:24 -0000 Received: (qmail 17303 invoked by uid 22791); 23 Apr 2012 22:21:19 -0000 X-SWARE-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,TBC X-Spam-Check-By: sourceware.org Received: from out5.bezeqint.net (HELO out5.bezeqint.net) (192.115.188.200) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Apr 2012 22:21:02 +0000 Received: from argon.home.il (unknown [192.115.25.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by out5.bezeqint.net (Postfix) with ESMTPSA id 3FF7DBC8A80; Tue, 24 Apr 2012 01:20:57 +0300 (IDT) Received: from argon.localnet (argon.home.il [192.168.10.72]) by argon.home.il (8.14.5/8.14.4) with ESMTP id q3NMKu9r001064; Tue, 24 Apr 2012 01:20:56 +0300 From: Oron Peled To: crossgcc@sourceware.org Subject: Re: License text in finished built toolchain? Date: Mon, 23 Apr 2012 22:21:00 -0000 User-Agent: KMail/1.13.7 (Linux/2.6.42.12-1.fc15.i686.PAE; KDE/4.6.5; i686; ; ) Cc: "Yann E. MORIN" , Per-Arnold.Blaasmo@atmel.com References: <4F911B40.3000002@atmel.com> <201204231919.32752.yann.morin.1998@free.fr> In-Reply-To: <201204231919.32752.yann.morin.1998@free.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201204240120.55537.oron@actcom.co.il> X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00035.txt.bz2 Hi, I'd like to clarify better the suggestion to install license by crosstool-NG. On Monday, 23 =D7=91April 2012 20:19:32 Yann E. MORIN wrote: > very good summary of license bundling practices > > That's my opinion that crostool-NG should *not* do that automatically > for you. There are a few reasons for my position: > - you and/or your lawyer have to fully understand the licensing terms > of each component, and decide and your own what those licenses imply; Correct. crosstool-NG should *not* try to interpret any license information (i.e: it should not say "it's a GPLv2"), but only copy verbatim the license texts from the sources used for the build. This means the legal responsible party (distribution/company-lawyer/etc.) would *still* need to review, but crosstool-NG can make this review somewhat easier by having all license text installed under a common directory tree. > - some components are multi-licensed; for example part of gcc are > GPLv3+ while some other parts are LGPLv3+; That's OK. All license texts provided would appear in the centrally installed text. The responsible party may further review/modify it as they see fit before creating the final tarball/deb/rpm. > - the licensing terms for a specific component may vary with the > version of this component; for example gcc 4.2 and earlier were GPLv2+ > and LGPv2.1+, while gcc 4.3 and later are GPLv3+ and LGPLv3+; Again, I suggest that crosstool-NG would only copy what's provided by the constituent sources, so it would always copy the licensing terms provided by the sources it used. You are correct that this may pose some maintenance problem: * The implementation of this feature should be able to have different lists of licensing files for different versions of software. (IMO, this is similar requirement to what crosstool-NG already implements -- different patches for different versions). * A harder problem is -- can this list be *reliably* maintained when the sources changes/moves/renames license files between versions. * Which brings a related issue is -- does crosstool-NG becomese responsible in some legal way to the correctness of this list? Hmmm.... (more later) > - the licensing terms may change depending on the options you used > when building the toolchain (I do not have a example coming to mind > right now); That's not a problem if all crosstool-NG does is just collecting license files provided by the sources. As you said before, the license *applicability* (and to which parts of the software) should be done by a lawyer/engineer, not by any automatic tool. What I'd like the tool to provide is the raw license text collection so it's easier to do the manual work. > - you anyway have to make available the complete and corresponding sour= ce > code for the components that are used in the toolchain (at least those > that are under copyleft licenses, such as GPL or LGPL). Yes. But if you choose to provide them via alternative route from the binar= ies (e.g: sources via company website, binaries inside an embedded device), you still have legal obligation to provide the license text *with the binaries* (at least for the licenses you talked about). > So, in theory, crosstool-NG *could* copy some of the license texts for yo= u, > but you would always have to manually check that the correct licenses have > been copied, and that nothing was missing, and that a license text that d= oes > not apply was not copied. Totally agreed. So IMO the idea is viable only if this can be made crystal-clear. For example: * Copy the license text into clearly named directory: /usr/share/doc/crosstool-NG/license-files-found-in-source-tree * Maybe add there a very short README-LEGAL similar to: "For your convenience, the license files in this directory were collected from toolchain sources. It is your responsibility to verify and comply with the correct licensing terms required by the different components that were used to build this toolchain before distributing the result." > > What about crosstool-ng's license? > > Do we need to add that to the finished built toolchain? >=20 > This is a tricky question. >=20 Excelent summary of the said issue > > Also, do not forget that some components in the toolchain may also use a > .config-like file; for example uClibc has a .config file, so you must > provide it along with the uClibc sources, and eglibc can use config files > which you also must provide with eglibc's sources. Technical question for clarification: Isn't crosstool-NG *generating* those .config-like files as part of the build (according to its own .config)? If yes, than they are not required (just like we don't need to provide the intermediate .o files) > Using an existing packaging scheme (eg. rpm and/or deb) /may/ make this e= asy > for you. YMMV, as they say. A related, not-crosstool-NG-specific idea (somewhat utopic, but still): * There are standard places where packages install binaries, libraries, pkg-config files, man-pages. There isn't anything like this for license texts. * Let's assume the FOSS world *gradually* adopt something (licensedir) * For autotools based packages it would be trivial to implement it even before it becomes a "standard": Makefile.am: licensedir =3D @licensedir@ license_DATA =3D COPYING COPYING.LIB configure.ac: licensedir =3D /usr/share/doc/$PACKAGE_NAME/licenses # TODO: add --with-licensedir=3D functionality * If something like that is adopted by key autotools packages, it may later become standard autotools directory. Than the configure.ac code can be killed and the Makefile.am code becomes a one-liner: license_DATA =3D COPYING COPYING.LIB Than packagers may follow some hypothetic distro specific policy by running: ./configure --licensedir=3D/usr/share/legal-info/mypackage-1.3 instead of: ./configure --with-licensedir=3D/usr/share/legal-info/mypackage-1.3 * This also means anybody that want to provide licenses for specific package (e.g: eglibc) need not be concerned if she picked the right files as this is now maintained by the package itself. * while IANAL, this may also alleviate the following legal question: - Someone repackage free software (e.g: a distro) - Some new version of this software adds another mandatory license with its license text (e.g: relicense some code) - The packager fails to notice this (e.g: the upstream did not indicate it clearly in their release notes) - So the result is not in full compliance (does not contain required license text) - How much liability is on the distro? - Maby if the packager could "./configure --licensedir=3D", it would lower/eliminate the distro (implied) liability? - It would surely decrease the chance of such mistake from even happening in the first place. > Again, *none* of the was legal advice. You should really consult seek leg= al > advice from your lawyer and/or your company's legal departement. Yes, I am in the IANAL department too ;-) --=20 Oron Peled Voice: +972-4-8228492 oron@actcom.co.il http://users.actcom.co.il/~oron Linux lasts longer! -- "Kim J. Brand" -- For unsubscribe information see http://sourceware.org/lists.html#faq