public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
* License text in finished built toolchain?
@ 2012-04-20  8:16 Per Arnold Blaasmo
  2012-04-20 14:03 ` Thierry Moreau
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Per Arnold Blaasmo @ 2012-04-20  8:16 UTC (permalink / raw)
  To: crossgcc

Hi,
I have a question regarding the finished built toolchain and
redistribution if that.

If I use Crosstool-ng to build a GNU Toolchain and redistribute that
with my own product.

Do we need to have the license files in the finished build tree?
Should crosstool-ng copy those in to the finished tree?

What about crosstool-ng's license?
Do we need to add that to the finished built toolchain?

Do anyone have any thought on this?

Best Regards
Per A.

-- 
Per Arnold Blåsmo
Senior Design Engineer, Atmel Norway


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-20  8:16 License text in finished built toolchain? 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-23 17:19 ` Yann E. MORIN
  2 siblings, 1 reply; 9+ messages in thread
From: Thierry Moreau @ 2012-04-20 14:03 UTC (permalink / raw)
  To: Per-Arnold.Blaasmo; +Cc: crossgcc

Per Arnold Blaasmo wrote:
> Hi,
> I have a question regarding the finished built toolchain and
> redistribution if that.
> 
> If I use Crosstool-ng to build a GNU Toolchain and redistribute that
> with my own product.
> 
> Do we need to have the license files in the finished build tree?
> Should crosstool-ng copy those in to the finished tree?
> 
> What about crosstool-ng's license?
> Do we need to add that to the finished built toolchain?
> 
> Do anyone have any thought on this?
> 
> Best Regards
> Per A.
> 

May I suggest that the business decision to use the GCC technology (in 
my opinion perhaps the greatest mankind achievement in the field of 
software engineering) should have been taken with due consideration for 
the legal framework called *GPL*.

Then, to "redistribute a GNU toolchain" means compliance to the GPL, 
which obviously requires the copyright statements and license files, and 
more useful to the community in practice, the availability (through the 
redistributing organization, as detailed in the license provisions) of 
the source code that allowed the distributor to come up with the 
finished built toolchain.

If you don't abide by the license terms, you should stop redistributing 
GCC toolchains and rely on proprietary compiler technology.

You may need legal advice to get a full understanding or the situation.

I don' se the point for crossgcc developers/maintainers to delve into 
these issues for you. Their time is best used elsewhere.

Regards,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-20 14:03 ` Thierry Moreau
@ 2012-04-20 16:02   ` Bill Pringlemeir
  0 siblings, 0 replies; 9+ messages in thread
From: Bill Pringlemeir @ 2012-04-20 16:02 UTC (permalink / raw)
  To: Thierry Moreau; +Cc: Per-Arnold.Blaasmo, crossgcc


Per Arnold Blaasmo wrote:

>> Do we need to have the license files in the finished build tree?
>> Should crosstool-ng copy those in to the finished tree?

>> What about crosstool-ng's license?
>> Do we need to add that to the finished built toolchain?

>> Do anyone have any thought on this?

On 20 Apr 2012, thierry.moreau@connotech.com wrote:

> I don' se the point for crossgcc developers/maintainers to delve into
> these issues for you. Their time is best used elsewhere.

I don't think it is a bad idea for crosstool-ng to copy a licence
file(s) to the finished tree.  I don't see one for anything but 'ltrace'
in my trees in '<tuple>/debug-root/usr/share/doc/ltrace/COPYING'.  CT-NG
is already putting a compressed build log there.  There is no 'choice'
of licence.  It is GPL/LGPL/GCC and having those files present in the
finished tree makes sense doesn't it?

I don't think it is a pressing matter, but I wouldn't say that Per
Arnold's suggestion was *not* worth any attention.  Actually, I am
surprised that the GCC, etc build files haven't installed a licence file
somewhere... but maybe I missed something in the finished tree.

Debian/Ubuntu provide on in /usr/share/doc/gcc-4.4-base/copyright.  I
guess getting the constituent package licences right for an aggregate
license might be an issue; if it is a simple 'cp' how could it not be
worth the time?

fwiw,
Bill Pringlemeir.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-20  8:16 License text in finished built toolchain? Per Arnold Blaasmo
  2012-04-20 14:03 ` Thierry Moreau
@ 2012-04-20 18:28 ` Michael Eager
  2012-04-21 22:27   ` Oron Peled
  2012-04-23 17:19 ` Yann E. MORIN
  2 siblings, 1 reply; 9+ messages in thread
From: Michael Eager @ 2012-04-20 18:28 UTC (permalink / raw)
  To: crossgcc

On 04/20/2012 01:16 AM, Per Arnold Blaasmo wrote:
> Hi,
> I have a question regarding the finished built toolchain and
> redistribution if that.
>
> If I use Crosstool-ng to build a GNU Toolchain and redistribute that
> with my own product.
>
> Do we need to have the license files in the finished build tree?
> Should crosstool-ng copy those in to the finished tree?
>
> What about crosstool-ng's license?
> Do we need to add that to the finished built toolchain?
>
> Do anyone have any thought on this?

You do *not* need to include licenses in the tool chain installation
tree.  Most distributions do not include licenses with the binaries.

You *do* need to provide the licenses to your users in some fashion.
Many companies distribute these licenses as one or more text files
along with their program (for example, on the CD/DVD) or include them
as an appendix to the documentation for the program.  Some, like Mozilla,
have the license displayed when the program is installed.

Each of the licenses describe what you must do to conform to the
license.  You may need to include copyright notices in your documentation,
output a copyright notice (required for interactive programs licensed
under the GPL), or include license files with your program.  In particular,
the GPL requires that you provide the source used to build the binaries
or provide a reasonable means to obtain the source.

You can find crosstool-ng's license in crosstool-ng/licenses.d/by-sa.
Since the build tree generated by crosstool-ng does not contain
crosstool-ng, and it is unlikely that you would redistribute crosstool-ng
with your program, there would not appear to be any requirement to include
this license.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-20 18:28 ` Michael Eager
@ 2012-04-21 22:27   ` Oron Peled
  2012-04-22  0:01     ` Michael Eager
  0 siblings, 1 reply; 9+ messages in thread
From: Oron Peled @ 2012-04-21 22:27 UTC (permalink / raw)
  To: crossgcc; +Cc: Michael Eager

On Friday, 20 בApril 2012 21:28:26 Michael Eager wrote:
> You do *not* need to include licenses in the tool chain installation
> tree.  Most distributions do not include licenses with the binaries.

The last statement is wrong. Someone else on this thread already
mentioned the /usr/share/doc/<package>/copyright files on Debian
(and Debian derived distros like Ubuntu). May I add my Fedora:
$ find /usr/share/doc -name 'COPYING' | wc -l
1107
(which obviously applies to derived distributions like RHEL/Centos).

The responsibility for complying with a copyright license (including
providing a copy of it where needed) is on the one who distributes
the copyrighted work. However, it would be a nice service if crosstool-ng
could copy all the license files into the x-toolchain tree under
a well defined common directory (e.g: <datadir>/doc/crosstool-ng/licenses.d)
This would help prospective toolchain packagers.

-- 
Oron Peled                                 Voice: +972-4-8228492
oron@actcom.co.il                  http://users.actcom.co.il/~oron
"If it's not source, it's not software." -- www.gnu.org

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-21 22:27   ` Oron Peled
@ 2012-04-22  0:01     ` Michael Eager
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Eager @ 2012-04-22  0:01 UTC (permalink / raw)
  To: Oron Peled; +Cc: crossgcc

On 04/21/2012 03:26 PM, Oron Peled wrote:
> On Friday, 20 בApril 2012 21:28:26 Michael Eager wrote:
>> You do *not* need to include licenses in the tool chain installation
>> tree.  Most distributions do not include licenses with the binaries.
>
> The last statement is wrong. Someone else on this thread already
> mentioned the /usr/share/doc/<package>/copyright files on Debian
> (and Debian derived distros like Ubuntu). May I add my Fedora:
> $ find /usr/share/doc -name 'COPYING' | wc -l
> 1107
> (which obviously applies to derived distributions like RHEL/Centos).

Yes, you are correct.  Perhaps I should have said that most embedded
distributions do not include the licenses with the binaries.

> The responsibility for complying with a copyright license (including
> providing a copy of it where needed) is on the one who distributes
> the copyrighted work. However, it would be a nice service if crosstool-ng
> could copy all the license files into the x-toolchain tree under
> a well defined common directory (e.g:<datadir>/doc/crosstool-ng/licenses.d)
> This would help prospective toolchain packagers.

Not a good idea in an embedded environment where space is limited.
This is the target for crosstool-ng, not building Fedora or Debian.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-20  8:16 License text in finished built toolchain? Per Arnold Blaasmo
  2012-04-20 14:03 ` Thierry Moreau
  2012-04-20 18:28 ` Michael Eager
@ 2012-04-23 17:19 ` Yann E. MORIN
  2012-04-23 21:46   ` Michael Hope
  2012-04-23 22:21   ` Oron Peled
  2 siblings, 2 replies; 9+ messages in thread
From: Yann E. MORIN @ 2012-04-23 17:19 UTC (permalink / raw)
  To: crossgcc, Per-Arnold.Blaasmo

Per, All,

Firts off, the usual disclaimer: I am not a lawyer, you should consult a
competent lawyer and/or your company's legal departement for definitive
advice.

On Friday 20 April 2012 10:16:00 Per Arnold Blaasmo wrote:
> If I use Crosstool-ng to build a GNU Toolchain and redistribute that
> with my own product.
> 
> Do we need to have the license files in the finished build tree?

That's my understanding that the license texts for GPL and LGPL components
be made available alongside with the distributed binaries. The same goes
with the license texts for the BSD-like components.

Whether you want to include these license texts in the same archive (a
tarball or any other packaging of your choice), or as files residing
side-by-side with the distributed archive, is up to you to decide.

I for one would suggest that you bundle in the same archive, because:
  - you have the guarantee that the recipient of the archive does get
    the license texts, without requiring additional downloads;
  - if you distribute the archive on a physical medium, you are sure
    that the license texts wil actually *be* on the distribution medium;
  - the license texts will follow any subsequent distribution of the
    archive, if the recipient chooses to do so.

> Should crosstool-ng copy those in to the finished tree?

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;
  - some components are multi-licensed; for example part of gcc are
    GPLv3+ while some other parts are LGPLv3+;
  - 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+;
  - 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);
  - 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).

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.

> What about crosstool-ng's license?
> Do we need to add that to the finished built toolchain?

This is a tricky question.

The toolchain is generated by crosstool-NG, so the license of crosstool-NG
does *not* apply to the toolchain (the same way that the license of gcc
does not apply to the binary generated by gcc).

However, the license of crosstool-NG explicitly states that crostool-NG is
what the GPL names "scripts used to control compilation and installation
of the executable." In my understanding, for example in the gcc context,
this sentence applies to the scripts used to build gcc. I believe that
crosstool-NG is what the GPL refers to in the sentence quoted above.

So, it is my understanding that, if you distribute a toolchain built with
crosstool-NG, you have to pass the complete and corresponding source code
for the crosstool-NG you used to build said toolchain.

Also, it is my understanding that the crosstool-NG's .config file is part
of the afore-mentioned scripts, and that you have to distribute it as if
it were part of crosstool-NG. This is already done automatically for you
by crosstool-NG, which installs the script bin/<tuple>.ct-ng.config in
the toolchain install directory.

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.

So, with respect to crosstool-NG, I would suggest that you put the archive
of the crosstool-NG you used, prominently side-by-side with the archive
of the toolchain you distribute.

You may of course decide to distribute a single archive with everything in
it:
  - the toolchain, in binary form
  - the crosstool-NG sources
  - the crosstool-NG's .config
  - the components' complete and corresponding source codes
  - the many license texts

Using an existing packaging scheme (eg. rpm and/or deb) /may/ make this easy
for you. YMMV, as they say.

Again, *none* of the was legal advice. You should really consult seek legal
advice from your lawyer and/or your company's legal departement.

Should you not know lawyers competent in the field, you may ask me, and I
would happily point you to some I know, and that you may be able to contract
to help you.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-23 17:19 ` Yann E. MORIN
@ 2012-04-23 21:46   ` Michael Hope
  2012-04-23 22:21   ` Oron Peled
  1 sibling, 0 replies; 9+ messages in thread
From: Michael Hope @ 2012-04-23 21:46 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc, Per-Arnold.Blaasmo

On 24 April 2012 05:19, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Per, All,
>
> Firts off, the usual disclaimer: I am not a lawyer, you should consult a
> competent lawyer and/or your company's legal departement for definitive
> advice.
>
> On Friday 20 April 2012 10:16:00 Per Arnold Blaasmo wrote:
>> If I use Crosstool-ng to build a GNU Toolchain and redistribute that
>> with my own product.
>>
>> Do we need to have the license files in the finished build tree?
>
> That's my understanding that the license texts for GPL and LGPL components
> be made available alongside with the distributed binaries. The same goes
> with the license texts for the BSD-like components.
>
> Whether you want to include these license texts in the same archive (a
> tarball or any other packaging of your choice), or as files residing
> side-by-side with the distributed archive, is up to you to decide.
>
> I for one would suggest that you bundle in the same archive, because:
>  - you have the guarantee that the recipient of the archive does get
>    the license texts, without requiring additional downloads;
>  - if you distribute the archive on a physical medium, you are sure
>    that the license texts wil actually *be* on the distribution medium;
>  - the license texts will follow any subsequent distribution of the
>    archive, if the recipient chooses to do so.
>
>> Should crosstool-ng copy those in to the finished tree?
>
> 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;
>  - some components are multi-licensed; for example part of gcc are
>    GPLv3+ while some other parts are LGPLv3+;
>  - 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+;
>  - 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);
>  - 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).
>
> 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.
>
>> What about crosstool-ng's license?
>> Do we need to add that to the finished built toolchain?
>
> This is a tricky question.
>
> The toolchain is generated by crosstool-NG, so the license of crosstool-NG
> does *not* apply to the toolchain (the same way that the license of gcc
> does not apply to the binary generated by gcc).
>
> However, the license of crosstool-NG explicitly states that crostool-NG is
> what the GPL names "scripts used to control compilation and installation
> of the executable." In my understanding, for example in the gcc context,
> this sentence applies to the scripts used to build gcc. I believe that
> crosstool-NG is what the GPL refers to in the sentence quoted above.
>
> So, it is my understanding that, if you distribute a toolchain built with
> crosstool-NG, you have to pass the complete and corresponding source code
> for the crosstool-NG you used to build said toolchain.
>
> Also, it is my understanding that the crosstool-NG's .config file is part
> of the afore-mentioned scripts, and that you have to distribute it as if
> it were part of crosstool-NG. This is already done automatically for you
> by crosstool-NG, which installs the script bin/<tuple>.ct-ng.config in
> the toolchain install directory.
>
> 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.
>
> So, with respect to crosstool-NG, I would suggest that you put the archive
> of the crosstool-NG you used, prominently side-by-side with the archive
> of the toolchain you distribute.
>
> You may of course decide to distribute a single archive with everything in
> it:
>  - the toolchain, in binary form
>  - the crosstool-NG sources
>  - the crosstool-NG's .config
>  - the components' complete and corresponding source codes
>  - the many license texts

For reference, we distribute:
 * The binaries themselves
 * A tarball holding all source tarballs used in the build
 * The crosstool-NG scripts used to build them
 * A README that covers reproducing the binaries using the source
tarballs and build scripts
 * Enough information to reproduce the build host
 * The full license text of all licenses as a page in the installer

We handle the .config problem via samples: the
'linaro-arm-linux-gnueabi' sample holds the config used to build the
binary.

See:
 https://launchpad.net/linaro-toolchain-binaries/+download

We should start including the licenses in $doc as well.

-- Michael

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: License text in finished built toolchain?
  2012-04-23 17:19 ` Yann E. MORIN
  2012-04-23 21:46   ` Michael Hope
@ 2012-04-23 22:21   ` Oron Peled
  1 sibling, 0 replies; 9+ messages in thread
From: Oron Peled @ 2012-04-23 22:21 UTC (permalink / raw)
  To: crossgcc; +Cc: Yann E. MORIN, Per-Arnold.Blaasmo

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-04-23 22:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-20  8:16 License text in finished built toolchain? 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 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).