All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Thomas De Schampheleire <patrickdepinguin+xenomai@gmail.com>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai-forge: multiple COPYING files
Date: Fri, 04 Oct 2013 11:09:34 +0200	[thread overview]
Message-ID: <524E85CE.1090309@siemens.com> (raw)
In-Reply-To: <CAAXf6LUfHA9aHe2FRngFJSKVXeKPVwxGLcRPYGNBqd7U1dMzKg@mail.gmail.com>

On 2013-10-02 13:42, Thomas De Schampheleire wrote:
> Hi,
> 
> The (L)GPL requires that every distribution of a derived work is
> accompanied with the license of the program (xenomai-forge).
> Currently, xenomai-forge contains several COPYING files:
> 
> ./kernel/cobalt/nucleus/COPYING
> ./kernel/cobalt/COPYING
> ./kernel/cobalt/rtdm/COPYING
> ./include/COPYING
> ./lib/alchemy/COPYING
> ./lib/psos/COPYING
> ./lib/vxworks/COPYING
> ./lib/analogy/COPYING
> ./lib/cobalt/COPYING
> ./lib/copperplate/COPYING
> 
> An embedded build system like buildroot [1] has legal-info facilities
> to mark for each package which license it uses, and where the license
> files is located. A user can easily generate an overview of the
> license information for all packages used in the system, and contains
> almost everything necessary to comply with the (L)GPL. In buildroot,
> this is done with 'make legal-info'.
> 
> In the case of buildroot, the license files are copied one by one in a
> directory named after the package. This would essentially mean:
> cp <xenomai-source>/kernel/cobalt/nucleus/COPYING licenses/xenomai/COPYING
> cp <xenomai-source>/kernel/cobalt/COPYING licenses/xenomai/COPYING
> cp <xenomai-source>/kernel/cobalt/rtdm/COPYING licenses/xenomai/COPYING
> ...
> 
> Clearly, the fact that all license files have the same name poses a
> problem here. In order to have all files, one would either need to
> rename them, or duplicate the directory structure.
> 
> Instead of moving this complexity outside of xenomai-forge (to the
> build system), I would like to discuss how it can be solved within
> xenomai-forge itself.
> 
> Here are two proposals:
> 1. Is it really necessary that there are multiple COPYING files? Is it
> not possible to have one COPYING file in the root of the project, and
> move the exception specified in include/COPYING to that file? This
> approach is similar to many many other open-source projects.
> 
> 2. Alternatively, what about renaming the license files to a unique
> name, e.g. COPYING.alchemy, COPYING.psos, COPYING.cobalt-nucleus ?
> Then, copying these files to one directory is possible without overwriting.

Having multiple, per-subdir COPYING files is by far not that uncommon.
So improving buildroot for such scenarios seems worthwhile.

That said, we need consolidation and clarification, specifically to
cover all files outside kernel/cobalt, include and lib. Will write a
patch, and another one to append suffixes to the subdir COPYING files.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux


  reply	other threads:[~2013-10-04  9:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-02 11:42 [Xenomai] xenomai-forge: multiple COPYING files Thomas De Schampheleire
2013-10-04  9:09 ` Jan Kiszka [this message]
2013-10-04  9:39   ` Thomas De Schampheleire
2013-10-04 10:02 ` Philippe Gerum

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=524E85CE.1090309@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=patrickdepinguin+xenomai@gmail.com \
    --cc=xenomai@xenomai.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.