Hi,

as discussed on debian-devel [1] I would like to request that more DFSG
licenses are added to /usr/share/common-licenses and that package
maintainers are allowed to reference them.

License: OFL-1.1
Source: https://opensource.org/licenses/OFL-1.1
Example packages:
https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License

Regards,

Markus

[1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Markus Koschany wrote:

Seconded.

Thanks,
Jonathan

Jonathan Nieder <jrnieder@gmail.com> writes:

license-count says this makes sense:

SIL OFL 1.0              12
SIL OFL 1.1             159

via the historic criteria of more usage than the least popular license
already in common-licenses (GFDL 1.3 at 138 packages).

Jonathan Nieder <jrnieder@gmail.com> writes:

license-count says this makes sense:

SIL OFL 1.0              12
SIL OFL 1.1             159

via the historic criteria of more usage than the least popular license
already in common-licenses (GFDL 1.3 at 138 packages).

This is not an entirely reasonnable criterion, though. The GFDL is losing
popularity. At some point there might be zero packages under the
GFDL 1.3, at which point the criterion would dictate that all licenses
should be included.

Also If you look at the license-count email archive, you will see that the
GFDL 1.3 should probably not have been included in the first place
(it was expected that more packages would migrate from 1.2 to 1.3).
So it makes better sense to count GFDL 1.2+1.3 as a single number.

The usual threshold for inclusion was much higher than 138.

Cheers,

This is not an entirely reasonnable criterion, though. The GFDL is losing
popularity. At some point there might be zero packages under the
GFDL 1.3, at which point the criterion would dictate that all licenses
should be included.

Also If you look at the license-count email archive, you will see that the
GFDL 1.3 should probably not have been included in the first place
(it was expected that more packages would migrate from 1.2 to 1.3).
So it makes better sense to count GFDL 1.2+1.3 as a single number.

The usual threshold for inclusion was much higher than 138.

Cheers,

Am 28.12.2017 um 11:21 schrieb Bill Allombert:
non-popular DFSG licenses. Nowadays nobody in the project can tell
within seconds how many DFSG-free licenses there are. Under my original
proposal we would add _all_ licenses which were accepted by the FTP team
to /usr/share/common-licenses.

This has two main advantages. First of all we could easily answer the
question what licenses are accepted by the Debian project and could
encourage other people to use them for their own projects. For a project
which prides itself for its Social Contract and Free Software Guidelines
it is kind of embarrassing that we cannot immediately tell our users and
contributors what licenses we consider to be free. Just by adding them
to /usr/share/common-licenses we could improve the documentation for one
of the legal cornerstones of this project.

The second point is: The current Policy punishes maintainers for
maintaining large and diverse packages with fonts, images, data and
media files, multiple contributors and software licenses. IMO we should
value developer time much more than disk space and current popularity of
a license.

Also the criterion of popularity does not take into account that some
licenses are more frequently used in specific fields of endeavor. If you
don't maintain a lot of -data or documentation packages with fonts,
images or other media files, this is probably not an issue for you. But
the current state surely is annoying for contributors who are interested
to develop parts of Debian where the OFL or CC licenses are very popular
and common.

Regards,

Markus

Markus Koschany wrote:
[...]
[...]

I am confident that we lack consensus for that original proposal.

I have some sympathy for moving to a different threshold or a
different criterion for inclusion in common-licenses.  But let me just
say now to avoid wasted time: I am not going to be supportive of
turning base-files into a compendium of all DFSG licenses.  There are
multiple reasons that I don't think that's in users' best interests.
I've already discussed some of them and haven't heard any convincing
new points in response.

As I've already said multiple times, if you are using copyright-format
1.0 to maintain multiple packages and it is getting in your way,
please please please, fix your workflow and improve documentation so
others can benefit from the same workflow changes.  Work with upstream
to ensure they have high quality license documentation that you can
use as-is (or that you can use after some mechanical transformations
--- e.g. I've heard of R module packagers having some success with
that approach).  Changing the list of licenses in base-files does not
change this at all.

All that said, I still support including the SIL OFL 1.1 in
common-licenses.  I also agree with you that number of packages is an
imperfect criterion --- the OFL 1.1 is not only used by a large number
of packages but many of those packages are popular, so the resource
savings (archive space in partial mirrors, bandwidth, CD size, etc) is
greater than it might seem at first glance.

Thanks,
Jonathan

Am 28.12.2017 um 20:39 schrieb Jonathan Nieder:

Agreed. At the moment I would already be happy if we could find
consensus for the few licenses I have filed bugs for.

Maybe this is the reason why we haven't found consensus yet. Why do you
think that adding all DFSG licenses to /usr/share/common-licenses is not
in our users best interests?

I recall the following arguments against this proposal:

1. Waste of disk space (especially for embedded systems)

I think we have already debunked this myth and it appears to me that at
least Sean and you agree that this is actually not an issue for this
specific target group and in fact we would _save_ disk space because
some of those licenses are present in very important and popular packages.

2. A license can only be included when a certain threshold is reached

First of all nobody seems to know what this threshold actually is.
Apparently it is something between gut feeling and the popularity of our
least preferred license in common-licenses. What negative impact is
expected when we just add all DFSG licenses? At least you seem to agree
that "included in number of packages" is an imperfect criterion.

3. Very short licenses should not be included

This was mentioned by Russ for the MIT and zlib licenses because it
"adds indirection to no real purpose and won't really save maintainers
significant time."

Why do we add the BSD license to common-licenses but not MIT and zlib?
At the moment we have a situation where we can reference some licenses
but have to quote others verbatim. I believe this is the real
indirection here. It would be much simpler (and more natural) to
introduce a rule to reference every DFSG license text than requiring to
check whether a license is a so called common license or not.

I don't understand what you mean by changing my workflow. Bill also
suggested that I just should not use copyright format 1.0. What would
that change? I still have to quote license texts verbatim. The only
"advantage" of the old format is that I can format d/copyright more
freely but the same information must be present anyway. It is simply not
feasible to educate all upstreams in existence to write a Debian-like
copyright file. They rightly say that it is not their problem how
downstreams process and treat their copyright information.

Though if you allowed to reference a license text on the local system
instead of quoting it verbatim this would allow myself and others to
save time in producing the Debian specific copyright file. In no way is
this related to upstream.

Yes, I'm happy that you support the inclusion of SIL OFL 1.1.

Regards,

Markus

Hi,

Markus Koschany wrote:

This may be the source of my confusion.  I am used to upstreams being
cooperative when I ask them for a clear LICENSE file, especially when I
provide them with a patch to do so.

Some licenses even require that.  Upstream has to follow the license,
too, when they incorporate code from third parties.  Even in a
situation where they wrote all the code themselves, making license
compliance easy for downstream users helps adoption of their code.

In other words, I have almost never experienced the kind of resistance
you are talking about.

Even a package that adopts copyright-format 1.0 does not need to put
per-file license information in debian/copyright.  It is perfectly
okay to have a single 'Files: *' paragraph with the project's license.
Some maintainers prefer to maintain per-file license information since
they think it makes their lives easier.

Thanks,
Jonathan

Markus Koschany <apo@debian.org> writes:

I'm not sure why the BSD license was included in common-licenses
originally.  My theory was that it was to include all the licenses
mentioned by name in the DFSG.  However, the version in common-licenses is
specific to code whose copyright is held by the University of California,
so it's not very useful.  Including it there in that form was probably a
mistake.

We found multiple packages in Debian that referred to the common-licenses
version of the BSD license but weren't actually released under that
license.  That's why Policy now says to not reference the version of the
BSD license in common-licenses.

We haven't removed it because it's very hard to do that.  There are still
quite a few packages in the archive that reference it (many possibly
incorrectly).

See https://bugs.debian.org/284340.

Am 28.12.2017 um 22:19 schrieb Jonathan Nieder:
neither Java packages or games. :)

Sure there are nice upstreams and I have certainly encountered more
helpful than obnoxious ones in the past. But you have to consider the
following: The more packages you (team-)maintain the more likely it is
that your scenario becomes less and less ideal. A few examples:

freeorion: [1]

Rather sophisticated game GPL-2 licensed but with various contributions
/ incorporations under different licenses. So I can't just write Files:
* -> GPL-2. I have to list all licenses with separate paragraphs and
there is no way to change that without sacrificing accuracy. But
d/copyright would be a lot more readable if I did not have to quote some
of those licenses verbatim.

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.

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.

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.

From my perspective every simplification of d/copyright helps. If you
think my workflow is to blame here, I'm all ears now how I could be more
efficient in maintaining just these four packages. ;)

Regards,

Markus



[1]
http://metadata.ftp-master.debian.org/changelogs/main/f/freeorion/unstable_copyright
[2]
http://metadata.ftp-master.debian.org/changelogs/main/b/bullet/unstable_copyright
[3]
http://metadata.ftp-master.debian.org/changelogs/main/u/ufoai-maps/unstable_copyright
[4]
http://metadata.ftp-master.debian.org/changelogs/main/n/netbeans/unstable_copyright

Markus Koschany wrote:
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

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).

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.

copyright-format 1.0 is not mandatory.  Why not ship upstream's
copyright file as is?

*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.

Some of the pain is essential pain due to the way copyright works and
the complexity of conveying authors' wishes.  But other parts are
self-imposed.  I agree with your goal of removing self-imposed pain. :)

Thanks,
Jonathan

Jonathan Nieder wrote:
[...]

Fortunately [1] says

  Not all copyright notices may apply to every individual file

so a pointer to there might be enough to remove the ambiguity for the
Copyright field.

[2] says

  This field should include all text needed in order to fulfill both
  Debian Policy's requirement for including a copy of the software's
  distribution license (12.5), and any license requirements to include
  warranty disclaimers or other notices with the binary package.

but doesn't speak to what to do when e.g. license requirements or
warranty disclaimers vary between files matching the file pattern.

Thanks,
Jonathan

[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
[2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-field

Hello Jonathan,

There's a long thread on d-devel right now where it has been pointed out
that the ftp-masters frequently reject packages that summarise in this
way, which I suspect the reason why Markus isn't considering this
feature of the copyright format helpful in addressing his concerns.

Am 29.12.2017 um 00:06 schrieb Jonathan Nieder:
[...]

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.
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.

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.

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.

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

Am 28.12.2017 um 23:10 schrieb Russ Allbery:

I see. Thanks for your explanation.

Apparently including more DFSG-licenses is a recurring theme. It is
telling that this even goes back to 2004. One faction would like to see
BSD/MIT/zlib aka permissive short-licenses included, the other side
believes this could be ambiguous and mistakes are inevitable.

*sigh*

This is like prohibiting cars for transportation because they could be
used as weapons or football matches because someone could get hurt. I
believe we make life for us more difficult than necessary. Well, I guess
it can't be helped...

Markus Koschany <apo@debian.org> writes:

That's not what "and" means.  That would be "or".  "and" means you have to
follow all of those licenses when using a work composed of those files,
which sounds correct to me.

It's not correct if you take one of the files from the group in isolation;
in that case, you probably only have to follow one of the licenses.  But
that gets back to the question of just what we're supposed to be
documenting in debian/copyright.

Policy does not require that.  ftpmaster might, which is not quite the
same thing.

The Expat license grants *anyone* the right to do that, so the Debian
package maintainer can do this just as easily as upstream can.

Am 29.12.2017 um 23:35 schrieb Russ Allbery:

Of course. My bad! Still in the case of freeorion Jonathan's suggestion
would be incorrect. Nobody is obliged to adhere to _all_ license
conditions for _all_ files. If there are images licensed under CC-BY,
then I certainly don't have to follow all license conditions of the GPL
when I create a derivative work based on those images.

That's a bold claim.

"Every package must be accompanied by a verbatim copy of its copyright
information and distribution license in the file
/usr/share/doc/package/copyright"

Experience tells me that packages are rejected if they don't mention
_each and every_ copyright information.

I'm absolutely certain this warrants rejects by the FTP team. In my
opinion Policy should always be in sync with ftpmasters decisions. I
understand that this is not always easy to achieve but if your statement
is true, it is kind of shocking because it means the ftpmasters are
above Policy.

This is correct and sounds completely sensible to me. From my personal
experience I can say this is not the reality though. We are required to
mention public-domain licensed files and very permissive licensed files
in d/copyright too. I can't just write the package is licensed under the
GPL-2. I have to mention _all_ the different licenses in one package,
otherwise my package gets rejected.

Perhaps this should be clarified. I would really like to see this happen.

Markus

Markus Koschany <apo@debian.org> writes:

I think there's an active project debate of the meaning of just about
every word in that sentence, and most of those debates have gone on for
years.  For example, does "verbatim" mean that collapsing multiple
copyright statements into one as allowed by copyright-format 1.0 is a
Policy violation, since that makes the copy not "vertabim"?

Anyway, the point that I was trying to make is that Policy says you have
to copy the copyright information and distribution license.  There's
nothing in there that says this means every license in the source package;
even ftpmaster doesn't require the licenses in, say, configure and
Makefile.in be copied.  An equally valid interpretation is that this is
the license under which the package is distributed, which is probably the
most restrictive of the set of licenses that cover the material that went
into the derivative work, or the union of them, depending on the exact
wording of the licenses.

In other words, if you have a few public domain files, a few GPL-2+ files,
and a few GPL-3+ files, there's nothing in Policy right now that says you
can't just put the GPL-3 into /usr/share/doc/package/copyright of the
resulting binary package and be done with it, since that's the effective
distribution license for the binary package.  However, that's not the
current ftpmaster policy, and ftpmaster both predates Policy and is the
decision-making body in Debian responsible for this.

That means Policy is at best horribly ambiguous and at worst wrong and
should be fixed to state the actual requirements, which I think everyone
agrees on.  Fixed to say *what* is the problem.

We would love to bring Policy in sync with ftpmaster decisions as soon as
we can figure out how to describe them.  That sounds flippant, but it's
the essence of the current situation: Policy says the bare minimum (and
the same thing it's said for years) because we don't have a more accurate
description of the actual requirements that everyone has signed off on.

This isn't ftpmaster's fault, in that I don't think they have a concrete
guide either.  It's more an apprenticeship and tradition thing, which
doesn't seem to be standardized sufficiently to turn into Policy language.
I feel like that would be a good goal for the project, but this has also
been something we've all wanted for years and years now.  It's clearly
quite hard to achieve, and I'm not sure the right path that would get us
there.

That's why I've been arguing in debian-devel in favor of a working group
to try to analyze this and produce a written policy we can get consensus
on.  Then we can put that into Policy and hopefully everyone will finally
be on the same page.
silent on this.

Please note: I'm not saying Policy *contradicts* ftpmaster either.  I'm
saying that Policy basically doesn't document the requirements for
debian/copyright.

I think you're confusing this with a disjunction (dual/multi-license),
which is "GPL-2 or Permissive-License-1 or ..." in copyright-format.

"License: GPL-2 and Permissive-License-1 and Permissive-License-2 ..."
means you can only redistribute the file(s) in question if
you simultaneously do everything GPL-2 requires, everything
Permissive-License-1 requires, everything Permissive-License-2 requires,
and so on. In the case of the GPL, in practice that collapses into
"everything GPL-2 requires", unless the file is a GPL violation due to
the other licenses being non-GPL-compatible - but my understanding is
that the ftp team still require us to quote all the licenses, even if
they have no practical effect.

There are a couple of real-world examples of the "and" syntax in
src:darkplaces, where permissively-licensed code was copied into a
GPL-2+ project, resulting in files that are partly GPL-2+ and partly
some permissive license.
ftp team (and then uploaded the split parts through NEW), they didn't
object to the copyright files being identical, with each source package
listing some copyright holders and licenses that actually only exist
in the other source packages from the same group.

However, I can see that d-mentors wouldn't like that: people sponsoring
random packages (that they themselves aren't necessarily involved or
interested in) will tend to assume that this particular package doesn't
deserve to be a special case, because 95% of the time it doesn't. Making
pragmatic decisions like "this is not what I'd usually do, but in this
case it makes more sense" requires enough context to understand the
costs and benefits that apply.

    smcv

Yes, cost/benefit should be considered (and was in this case).  But
please, one should not only evaulate _their_ cost but also the cost this
creates on other parties. The goal should be to reduce the overall
cost-sum.

For example, this particular issue was causing literally thouesands of
lintian stuff, so basically rasing the noise level far above the signal.
And it would have been easily fixed, as d/copyright was script-generated
and the script could have a check implemented to filter the output to
the respective packages.

Hi,

Am 30.12.2017 um 01:24 schrieb Simon McVittie:
use in some of my packages. I corrected this in a previous reply to Russ.

In a nutshell: My point is that I appreciate Jonathan's idea and would
really like to use that format in my packages but as we have already
found out and agreed on, this is not the reality because people would
either file RC bugs against my packages or reject them right off the
bat. We teach Debian maintainers to document all license information in
d/copyright who spend hours and days of their life to compose various
copyright files but our most veteran developers tell me that's basically
all shenanigans and we could write much simpler documents. This looks
like a call for action to me.

Russ mentioned that we should create a working group to revise our
Policy in regard to copyright information and document our requirements
properly. Sounds great. I'm all in favor for this proposal. Let's do
it..yesterday. That's my greatest wish right now. Shall I file another
bug report for this issue?