Jonathan Nieder wrote:
> Your call, of course.  I personally consider it minor.  But so I
> understand for the future: isn’t this a policy “must” directive?  I am
> thinking of [1], which says the copyright information and license must
> be reproduced verbatim in the copyright file.

There are several discussion points.  One is that "serious" needs to
actually be serious.  Serious means that you would hold up releasing
the next Debian Stable because it.  Even you agreed that you thought
this was only "minor".  When in doubt, "normal" is the best place to
start.

The format of the Debian package copyright file is not dictated by
Debian Policy however the content is dictated by section 12.5
"Copyright information" which requires a verbatim copy of the packages
copyright and distribution license.

The program license was reproduced verbatim.  The unifdef project
license is stated as the 2-clause license contained in unifdef.c.
That is the project copyright and distribution license.  That content
was reproduced verbatim and was current.  (Additionally the copyright
from the previously combined strlcpy code was also included.  That
should not have been there.  But by itself was not the big issue.)

Here is the important part of your bug report.  It is understood that
the copyright file must document the names of all authors, the years
of copyright, the licenses used, references to upstream such as the
URL of the upstream source.  This isn't specifically stated as such in
Policy 12.5 but it has been a long standing interpretation of it that
those must be present.  This was incomplete.  It was incomplete in the
new upstream distribution that I pulled the updated notices from.  (I
should have caught the omission that when I switched to the new
upstream bundle but I didn't.  My bad.)  However all of the licenses
used were DFSG-free, all permissive, and compatible with the project
license.

There are many reasons for needing that level of detail.  This is
because those parts may be useful in isolation from the greater whole.
This is because it is important to be able to identify if software
licenses are incompatible, or become incompatible.  For example the
GPLv3 incompatibility with GPLv2.  This is because a user may want to
avoid a certain type of license even if it is DFSG-free and also
compatible with the project license.  An example might be the Affero
GPL.  If the license were to be changed all of the owners would need
to agree.  Also including all of the details of the contents of the
source code make the auditing of the package for meeting DFSG easier.
Including all of the details facilitates NEW processing.

[A side discussion point is that there are a many uniquely different
licenses used on various projects.  That is unfortunate.  One of the
problems that we have today is a proliferation of too many different
licenses.  Every unique license used requires those downstream to
expend time and energy analyzing and understanding it.  Creating a
good license is hard.  Many people create licenses with inadvertent
but severe problems.  The best thing a free software project can do is
to select one of the already existing, well known and well understood
licenses and use it without creating their own uniquely different one.
Then all of those using the same license can be grouped together and
understood as a whole.]

> > Tony's test harness has been released into the public domain.
> 
> AIUI that is considered legally problematic in some places, so he used
> the “CC0 public domain explanation”.  Where releasing code to the
> public domain is valid, that is what that means; elsewhere, it is a
> license.  It was probably the right choice to make it clear to
> everyone what their rights are.  Doing that requires a long document,
> unfortunately.

There is some FUD that circulates concerning content in the public
domain.  IANAL but I have been told that even in non-PD jurisdictions
the likelihood is that PD would be treated as a "very permissive
copyright".  I will not debate it further here.  But even Debian
considers PD to be DFSG-free.  :-)

Some people choose distributing in the public domain because it
relieves the burden of needing to keep the years in a copyright
statement up to date.

In any case...

I didn't like the messiness that was going to result from the current
situation.  Going forward in the future as more contributions were
collected I could see things only getting more complex.  Therefore I
have been working with Tony on this issue to simplify the situation.
  - I have changed the license on my contributions to match the
    project license.
  - Tony changed the license on the one test harness PD file to match
    the project license.  
Those changes converged and simplified the number of licenses to the
one shared 2-clause license leaving only the unifdefall file with the
legacy 3-clause license.  Much simpler.

Additionally and most importantly Tony has now added a new file
COPYING containing the full and complete license for all works in the
project.

With these changes not only is the packaging cleaner but all other
distributions using the upstream benefit.  The next packaging will
contain the new upstream version with these changes.

Bob



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to