On 10/13/2013 01:12 PM, Jan Kiszka wrote:
On 2013-10-13 12:08, Philippe Gerum wrote:
On 10/11/2013 09:32 AM, Jan Kiszka wrote:
Hi Philippe,

The following changes since commit
926e0441446aae116bf5b0701753e4b87a5386a2:

    doc: update installation guidelines (2013-10-04 15:46:23 +0200)

are available in the git repository at:

    git://git.xenomai.org/xenomai-jki.git for-forge

for you to fetch changes up to f1559e40a39b1a54e0348732402a68eb0dfef0a4:

    Rename include and lib copying files (2013-10-10 15:15:56 +0200)

If you do not like COPYING.* renaming, just skip the second patch. The
first on is important as we currently have code that is formally under
no COPYING file.


Thanks for the heads up. However, I disagree with both patches. GPL has
never been our default license.

Where did we ever intentionally diverge from the pattern that everything
is GPL except those bits that need to be linked to or #included by
third-party programs?

The various lib/ test suites I did write are not GPL, but LGPL, although these are executables. You mention a rule you applied to your own contribution, which is fine by me. However, other contributors may see exceptions to this rule, so a default license makes no sense.

 I strongly believe that this is a very reasonable
pattern, so I don't understand your disagreement here. And see below
what damage a missing default license can cause.

The common rule for Xenomai is to state
the licensing terms on a per-file basis, explicitly. When present, the
COPYING files basically emphasize the fact that all files in the
relevant directory and below share that license. In other words, not
having COPYING file in some hierarchy does not mean that we have no
license, it's most often right there into each individual files.

Sure, I don't disagree that each source file should state its license.
We should not merge any more files in the future that lack this.
However, often we like to reference a COPYING file with the full license
term, thus it should be reachable, ideally by walking up the directory tree.

Also, having duplicate, slightly diverging COPYING files in subtrees
where all files require the same license anyway is not very elegant as well.


Legalese is not a matter of being elegant. It's a matter of being precise. Catch-all license files may be elegant, but they certainly aren't precise enough. The point is, as you mentioned, that all files merged in the future should bear an explicit license.

Besides, there is no "slightly diverging" licenses in -forge. It's either LGPL, or GPL, or GPL+exception for linking. As I mentioned a couple of times on this mailing list already, the latter is on its way out, since the introduction of the uapi/ section for the kernel files which may be shared with userland for common ABI definitions/constants, making the former exception useless. I'll push the proper patch accordingly.

All other headers outside the uapi/ areas shall be read from kernel code exclusively (GPL), or from userland Xenomai libraries exclusively (LGPL).

So, we'll shortly only have GPL or LGPL in the tree. Looking at the facts, I don't see any ambiguity.


The files which do not state any licensing terms in a way or another in
-forge are as follows:

./lib/boilerplate/tlsf/target.h
./utils/can/rtcansend.c
./utils/can/rtcanrecv.c
./utils/ps/rtps.c
./utils/analogy/wf_facilities.h
./utils/analogy/wf_facilities.c
./testsuite/*

The first one (target.h) is merely a build configuration file.
$top_srcdir/testsuite/* should not default to GPL, although it's
perfectly fine that contributors do state GPL licensing explicitly in
such code if they wish to. The few others implementing small utilities
are indeed lacking license information.

AFAICS, all other files state their license explicitly, or depend on a
COPYING file present in the file hierarchy they belong to. If the file
belongs to the kernel support, the additional requirement to have it
GPLv2 compatible is even implicit per the linux kernel licensing terms,
all of our kernel code abide by strictly.

At any rate, contributors may want to clarify licensing terms for the
code they authored if need be.

If you say that we never had GPL as the default, this has to be
rephrased: Contributors, it is required to clarify the license of those
files that do not carry any explicit license reference. We otherwise
have to remove them from the source tree!


Please stick to the facts: I mentioned a short list of files which lack explicit licensing information today. This means that by no mean your late addition of a catch-all COPYING file would solve anything retroactively with respect to this issue. All previous releases of this code would not fall under these terms. Therefore, the issue at stake is about fixing the current glitches - which are clearly not as "damaging" as you claimed - and clarify the policy for the future. This is the alternative solution to merging a catch-all COPYING file.

1. fixing the current issues means that contributors who authored these files are asked to provide the required fixup (and this includes myself). Only these people are entitled to pick the license for their code. What we may do is asking them politely to clarify the license. Such license would have to be compatible with the project, typically GPL/LGPL for userland utilities and GPL for all kernel space, LGPL for libraries which would be ok to link in 3rd party apps. This point is likely to be a no-brainer for these people, but you just may not force this decision on them by suddently covering their code with a license using this catch-all mechanism.

2. the policy is "explicit licensing". Terms should appear in the source files, and in addition as an external COPYING file in the relevant directories when that makes sense.

In any case, be sure that I've been taking Xenomai licensing issues very seriously for the past 12 years, and I'm willing to keep it that way.

This said, thanks again for the heads up. There is no reason to leave unlicensed code in the tree.

--
Philippe.

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to