From: Oron Peled <oron@actcom.co.il>
To: crossgcc@sourceware.org
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>, Per-Arnold.Blaasmo@atmel.com
Subject: Re: License text in finished built toolchain?
Date: Mon, 23 Apr 2012 22:21:00 -0000 [thread overview]
Message-ID: <201204240120.55537.oron@actcom.co.il> (raw)
In-Reply-To: <201204231919.32752.yann.morin.1998@free.fr>
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
prev parent reply other threads:[~2012-04-23 22:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 8:16 Per Arnold Blaasmo
2012-04-20 14:03 ` Thierry Moreau
2012-04-20 16:02 ` Bill Pringlemeir
2012-04-20 18:28 ` Michael Eager
2012-04-21 22:27 ` Oron Peled
2012-04-22 0:01 ` Michael Eager
2012-04-23 17:19 ` Yann E. MORIN
2012-04-23 21:46 ` Michael Hope
2012-04-23 22:21 ` Oron Peled [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201204240120.55537.oron@actcom.co.il \
--to=oron@actcom.co.il \
--cc=Per-Arnold.Blaasmo@atmel.com \
--cc=crossgcc@sourceware.org \
--cc=yann.morin.1998@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).