Am 29.12.2017 um 00:06 schrieb Jonathan Nieder:
[...]
> Using 'Files: *' when different files are under different licenses
> sacrifices precision, but it doesn't sacrifice accuracy. You can say
>
> Files: *
> License: GPL-2 and Permissive-License-1 and Permissive-License-2 and ...
>
> Or you can even write
>
> Files: *
> License: Freeorion
Hi,
Ok I can see the misunderstanding now. The above statement would be
incorrect for freeorion because it translates to:
You are allowed to use the files under GPL-2 and Permissive-License-1
and Permissive-License-2 and ...
But this is not true. Not all files are dual/triple/-licensed. Actually
no file is even dual-licensed.
Even in the old format you would have to write something like this:
All code is covered by the GPL-2 license. The full license text can be
found in /usr/share/common-licenses/GPL-2. Exceptions are noted below:
bla.png
foo.ogg
licensed under CC-BY-SA-3.0 (must be quoted verbatim)
example.ogg
licensed under CC-BY-3.0 (must be quoted verbatim)
bar.xyz
licensed under MIT/Expat (must be quoted verbatim)
etc.
> and clarify what the terms are in the license text. At least that was
> my understanding of the intent behind copyright-format.
>
> Looking at the latest clarifications to copyright-format, I see
>
> Files: *
> Copyright: 1975-2010 Ulla Upstream
> License: GPL-2+
>
> In this example, copyright in all files is held by the upstream, and
> that copyright holder grants license under the GPL, version 2 or
> later.
>
> which I fear is ambiguous. If the copyright field names multiple
> copyright holders, do all files have to be copyright by all of them,
> or can the copyright to some files be held by some of them and to
> others by the other?> The latter is the only tenable way this can work
> in practice but the text could use some clarification (in a separate
> bug).
The above license paragraph translates to: All files are Copyright
1975-2010 Ulla Upstream licensed under the GPL-2 (or at your option any
later version)
If there are multiple copyright holders who have licensed their work
under the same license then you can just extend the Copyright field.
Files: *
Copyright: 1975-2010 Ulla Upstream
2002, Ulf Upstream
2007, Uli Upstream
License: GPL-2+
But if there is even one file which is differently licensed like
Files: src/parser.c
Copyright: 2009, John Jay
License: Expat
you have to mention that in d/copyright. Otherwise your copyright file
would be incomplete/incorrect under the current Policy requirements.
This is reject-worthy.
However upstream could simply state that all software is GPL-2+ licensed
because the Expat license grants them the right to sublicense parser.c.
As long as they don't remove the grant in parser.c they are in
compliance with the license. Adopting a Debian style copyright file
would simply increase their workload and they don't like to maintain that.
>> bullet: [2]
>>
>> C++ library under a permissive license with various contributions
>> licensed under different licenses. I became fed up with checking the
>> data and examples directories with each upstream release because of the
>> various licenses and copyright holders in those directories. Fortunately
>> we don't need those for a functioning library but it would have been
>> nice for someone who wants to build demos and examples on a local
>> system. -> forced trade-off between usefulness, d/copyright and my
>> maintenance time. Nothing upstream could help us with.
>
> Can't upstream help by hosting a LICENSE file that you and other
> distributors share the work of maintaining?
>
> If they prefer to treat the data and examples directories as
> independent components, they can put a LICENSE file in each, so that
> all that would be left on the Debian side to do is (1) concatenate
> them and (2) remove any directories that don't have a LICENSE file
> yet.
Provided that upstream would accept such a LICENSE file I would be in
charge for all the maintenance work upstream from now on. I can't
imagine that there is someone else in this world who would voluntarily
maintain such license information. The idea is charming but I fear in
the end I would just do the work elsewhere and nothing would be gained
from it.
>> ufoai-maps: [3]
>>
>> ~5000 files, a lot of CC licensed files. Only manageable because
>> upstream provides a copyright file in their own format. I had to write
>> my own little parser to make it suitable for d/copyright. Checking this
>> all by hand would be a nightmare. Nothing upstream could help us with.
>> From their point of view they have provided all legally required
>> information.
>
> copyright-format 1.0 is not mandatory. Why not ship upstream's
> copyright file as is?
Here is the file:
https://sources.debian.org/src/ufoai-maps/2.5-1/LICENSES/
I had to split the game into four digestible pieces (which are in total
1.2 GB large). My original idea was to duplicate the copyright file for
all three data packages but back then this proposal has been harshly
rejected on debian-mentors (when I wasn't a DD yet) because the
copyright file would have mentioned files which are not part of a
specific source package. So I had to write this program
https://sources.debian.org/src/ufoai/2.5-3/debian/ufoai_copyright.py/
to match the current files in the source package with the correct license.
Maybe the package would have been accepted if I just had copied the
LICENSES file and all non-common-licenses verbatim in d/copyright. I
don't know. The reality is that it depends on some DD whether your
package is uploaded to Debian or not. As a mere contributor you either
have to swallow that or give up.
>> netbeans: [4]
>>
>> ~80000 files with dozens of licenses and hundreds of contributors. This
>> is only maintainable copyright-wise because I remove lots of files when
>> repacking the tarball.
>
> *nod* This is a similar case to bullet. Upstream is likely not
> interested in creating a LICENSE file but they could be interested in
> accepting it as a contribution, especially if you set them up with a
> licensecheck-like workflow to keep it from bitrotting.
Yup. Same case as bullet. I'm positive that it would have been even more
difficult to educate upstream (Oracle) about the LICENSE file in this case.
Regards,
Markus
Attachment:
signature.asc
Description: OpenPGP digital signature