Re: License text in finished built toolchain?

[Oron Peled <oron at actcom dot co dot il>]

Hi,

I'd like to clarify better the suggestion to install license
by crosstool-NG.

On Monday, 23 ×April 2012 20:19:32 Yann E. MORIN wrote:
>
  <snip> very good summary of license bundling practices </snip>
>
> 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 source
>     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 binaries
(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 you,
> 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 does
> 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?
> 
> This is a tricky question.
> 
  <snip> Excelent summary of the said issue </snip>
>
> 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 easy
> 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 = @licensedir@
          license_DATA = COPYING COPYING.LIB

      configure.ac:
          licensedir = /usr/share/doc/$PACKAGE_NAME/licenses
          # TODO: add --with-licensedir=<dir> 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 = COPYING COPYING.LIB

   Than packagers may follow some hypothetic distro specific policy
   by running:
      ./configure --licensedir=/usr/share/legal-info/mypackage-1.3
   instead of:
      ./configure --with-licensedir=/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=", 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 legal
> advice from your lawyer and/or your company's legal departement.

Yes, I am in the IANAL department too ;-)

-- 
Oron Peled                                 Voice: +972-4-8228492
oron@actcom.co.il                  http://users.actcom.co.il/~oron
Linux lasts longer!
                        -- "Kim J. Brand" <kim@kimbrand.com>

--
For unsubscribe information see http://sourceware.org/lists.html#faq