Bug#883731: audacious: Debian packaging has incorrect license

Discussion:

Nicholas D Steeves

2017-12-08 03:39:41 UTC

Dear Debian Legal Team,

I've CCed you for my reply to this bug, because I don't have the
experience to be able to tell if Debian implicitly relicensed
Audacious as GPL-3 from 2012-2016, how potentially falling out of
BSD-2-clause license compliance might have affected this, and also how
this should be resolved. The Debian packaging is GPL-2+, so it's
possible to move to copyright-format/1.0 if that would simplify
things. Also, please reply to point 2. OTTO "ancient plugins...under
different licenses. I assume audacious-plugins will also need a
copyright review. Please CC John and I, Bug #883731, and
debian-legal as appropriate.

Hi John,

Hi Nicholas,

On this topic, would you please update contrib/audacious.appdata.xml
to reflect the current Audacious license (GPL3)? It claims the
project_license is BSD-2-Clause.

Sorry if my initial email was unclear. The current Audacious license *is*

Oh, now I see. Sorry I wasn't familiar with Audacious' upstream
relicensing, and thank you very much for confirming for the files I
asked about.

1. The embedded copy of libguess (which is an external project) is under
a BSD 3-clause license, with a separate copyright. I believe this is
not a problem so long as the libguess license is also included with
any distribution.
2. Some of the more ancient plugins are under different licenses, including
GPLv2+ and GPLv3. When we relicensed the main parts of Audacious to BSD
around 2012, we thought it impractical to contact all of the original
plugin authors since some of them go back to XMMS days (20 years ago now).
The plugins are compiled as separate binaries, and Debian has them in a
separate package (audacious-plugins).
Our upstream COPYING file makes note of these exceptions, which is one
reason why it's important for it to be included verbatim, and not replaced
with generic BSD 2-clause text as it is in the current Debian package.

Both BSD 3-clause and BSD 2-clause allow relicensing as GPL, thus so
long as the licensing terms are complied with correctly BSD code can
perpetually and unidirectionally flow to GPL projects. So from what I
can tell it's 100% ok for the Debian package (both src and bin) to be
GPL-3 from 2012-to-2016, and both the Debian source packages and
binaries from this time period might actually be implicitly relicensed
as GPL-3. If so, that's history that can't be changed. Also, I'm not
sure what debian-legal and ftpmaster's view of #2 will be in light of
the relicensing (and possible implied relicensing back to GPL-3).

On 2016-04-06 06:55:52
(***@124bf3bdccdac9d0eb78ce65b53c9a4ba128e052)
use-system-licenses.patch might have made Debian's implicit
relicensing invalid, not because of the deduplication patch per-se,
but because /usr/share/common-licenses/BSD is a 3-clause and not a
2-clause one like Audacious uses. It's the same style, but is a
different license altogether...and yeah, I think one can go
BSD-2-clause to BSD-3-clause to GPL-3, but only if the original
BSD-2-clause bits aren't stripped. I'm also unsure whether the patch
that changes the user-visible bits and the out-of-date
debian/copyright outweigh the 2-clause license that wasn't stripped
from the headers of various files. eg: not implicitly relicensed, and
just out of date copyright plus non-compliance with 2-clause BSD.

Regarding the plugins, I don't know the state of debian/copyright in the
audacious-plugins package, but my main concern here is that the one in
audacious is correct.

Conversely, what I found in debian/copyright was a project license of
GPL-3, with notable exceptions. eg: are really translations GPL-1+?

As I said, debian/copyright is out-of-date. We relicensed the project
from GPLv3 to BSD 2-clause back in 2012. Possibly we didn't make an
obvious enough announcement back then for Debian to take notice.

I haven't looked at audacious-plugins yet either. Re: "is correct", I
agree, and I'm hoping the fix will be to simply synchronise with
upstream Audacious' BSD 2-clause.

Translations are under the same license as the rest of Audacious.

Thank you for the confirmation.

To my eyes it looks like the upstream project license needs to be
clarified and disambiguated, debian/copyright needs work, and finally
that deduplication patch can be dropped.

Let me know if you think there are still clarifications needed upstream
given the information I've provided here. I'd be happy to adjust things
as necessary.

Well, since the main Audacious project is in fact 2-clause-BSD this
is much clearer now! Thanks again for the help. I hope to work on
this Sunday, or after we hear back from debian-legal.

Sincerely,
Nicholas

Francesco Poli

2017-12-08 10:10:40 UTC

Permalink

Post by Nicholas D Steeves
Dear Debian Legal Team,

Hello Nicholas, John, and everybody else reading this.

I would like to send some comments of mine, here.

Please note that: not only I am not a lawyer, but, even more
importantly, I am not your lawyer, nor a lawyer of the Debian Project.
Also, I am not a member of the Debian Project: I am just a Debian
external contributor, who happens to be a regular on the debian-legal
mailing list...

Post by Nicholas D Steeves
I've CCed you for my reply to this bug, because I don't have the
experience to be able to tell if Debian implicitly relicensed
Audacious as GPL-3 from 2012-2016,

As far as I can tell, *maybe* the implicit re-licensing was done by
distributing the audacious Debian package with the incorrect
debian/copyright file.

Post by Nicholas D Steeves
how potentially falling out of
BSD-2-clause license compliance might have affected this,

Failing to retain the license text in the package distribution is in
fact lack of compliance with the 2-clause BSD license, I would say...

Post by Nicholas D Steeves
and also how
this should be resolved. The Debian packaging is GPL-2+, so it's
possible to move to copyright-format/1.0 if that would simplify
things.

I personally think that the first thing to do is an accurate copyright
and licensing status review of the audacious package, so that the
debian/copyright file may be fixed to reflect the actual current state
of affairs.
The Audacious upstream developers may be willing to help, by clarifying
any doubts upon request.
This may be a perfect opportunity to switch to the [machine readable]
format.

[machine readable]: <https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/>

After a fixed audacious package is uploaded to Debian unstable and
migrates to Debian testing, the most offending issue should be solved,
I suppose.
At that point, the Audacious upstream developers may be willing to
forgive the Debian Project for the past incorrect copyright information.

If that is deemed to be needed or useful, it could be feasible to also
fix the debian/copyright file for audacious version 3.7.2 in a Debian
stable update (and possibly also address the same issue for
oldstable)... On the other hand, this extra effort could perhaps be
considered not worth doing.

Post by Nicholas D Steeves
Also, please reply to point 2. OTTO "ancient plugins...under
different licenses. I assume audacious-plugins will also need a
copyright review.

Probably.

Post by Nicholas D Steeves
Please CC John and I, Bug #883731, and
debian-legal as appropriate.

Done.

I hope my comments may help.

Bye and thanks to the Debian Multimedia Maintainers for the time they
spend in maintaining a number of great Debian packages, and to the
Audacious upstream developers for the time they spend in
developing/maintaining that very nice audio player (that I personally
use everyday!). Thank you!

--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

John Lindgren

2017-12-08 15:36:49 UTC

Permalink

Post by Nicholas D Steeves
Both BSD 3-clause and BSD 2-clause allow relicensing as GPL, thus so
long as the licensing terms are complied with correctly BSD code can
perpetually and unidirectionally flow to GPL projects.

Yes, I agree. It's perfectly okay for the Debian package(s) to be
distributed as GPL, *as long as* the original BSD license text is still
retained.

Post by Nicholas D Steeves
I'm also unsure whether the patch
that changes the user-visible bits and the out-of-date
debian/copyright outweigh the 2-clause license that wasn't stripped
from the headers of various files.

Speaking for myself as upstream project lead, I'm not worried about
the legal status of already-built packages, but I would prefer that the
upstream (BSD 2-clause) license remain user-visible in future Debian
builds. The simplest way to achieve this would be to remove
use-system-licenses.patch and let the GUI again display
/usr/share/audacious/COPYING as the upstream version does.

Alternatively, debian/copyright could be updated to include the full
text of the upstream license, plus any Debian-specific bits (packaging
copyrights, etc.), and the patch could be updated so that the GUI
displays the installed version of that file instead (I think that would
be /usr/share/doc/audacious/copyright?)

Post by Nicholas D Steeves
The Audacious upstream developers may be willing to help, by clarifying
any doubts upon request.

Yes, for sure.

Post by Nicholas D Steeves
If that is deemed to be needed or useful, it could be feasible to also
fix the debian/copyright file for audacious version 3.7.2 in a Debian
stable update (and possibly also address the same issue for
oldstable)... On the other hand, this extra effort could perhaps be
considered not worth doing.

For my part, I'm not worried about the stable+oldstable packages being
fixed, only that the problem is resolved in a new unstable upload going
forward. I think that the other upstream developers would agree.

Thank you both for the prompt reply and good discussion!

John

Nicholas D Steeves

2017-12-10 23:20:46 UTC

Permalink

Post by John Lindgren

Yes, I agree. It's perfectly okay for the Debian package(s) to be
distributed as GPL, *as long as* the original BSD license text is still
retained.

This will be easier to do.

Post by John Lindgren
Alternatively, debian/copyright could be updated to include the full
text of the upstream license, plus any Debian-specific bits (packaging
copyrights, etc.), and the patch could be updated so that the GUI
displays the installed version of that file instead (I think that would
be /usr/share/doc/audacious/copyright?)

Thank you for your blessing on doing it this way. If Debian was/is
relicensing as GPL in a non-reversible way then this the way it
would/might have to be done.

Post by John Lindgren

Post by Nicholas D Steeves
The Audacious upstream developers may be willing to help, by clarifying
any doubts upon request.

Yes, for sure.

Please see my question about a missing copyright holder; I paused my
review at this point, so there might be other examples.

Post by John Lindgren

Whew, thank you, that makes things easier for everyone :-)

Post by John Lindgren
Thank you both for the prompt reply and good discussion!

You're welcome! Thank you for reaching out.

Sincerely,
Nicholas

Nicholas D Steeves

2018-10-22 18:15:57 UTC

Permalink

Update

Sorry for my deplorable memory and lack of organisation wrt this bug;
I committed some initial work and then forgot about it. Given my work
schedule for Oct and Nov it is unlikely that I will be able to prevent
the scheduled autoremoval. If someone else would like to fix it asap
please go ahead. Otherwise I anticipate being able to find the time
to work on this after the 28th of Nov.

I'll go ahead and file a bug asking for confirmation of the license
for contributors to debian/*, because this information is not
contained in old-style copyright format and I'm only familiar with
machine readable copyright format 1.0.

Regards,
Nicholas

Andrej Shadura

2018-10-22 18:50:56 UTC

Permalink

Hi,

Post by Nicholas D Steeves
Update
Sorry for my deplorable memory and lack of organisation wrt this bug;
I committed some initial work and then forgot about it. Given my work
schedule for Oct and Nov it is unlikely that I will be able to prevent
the scheduled autoremoval. If someone else would like to fix it asap
please go ahead. Otherwise I anticipate being able to find the time
to work on this after the 28th of Nov.
I'll go ahead and file a bug asking for confirmation of the license
for contributors to debian/*, because this information is not
contained in old-style copyright format and I'm only familiar with
machine readable copyright format 1.0

I was going to have a look but got distracted by writing kernel drivers â
fascinating stuff :D

I will try and spend some time this week on this. If not, I'll post an
update here.

--
Cheers,
Andrej

Nicholas D Steeves

2018-10-23 01:51:08 UTC

Permalink

Post by Andrej Shadura
I was going to have a look but got distracted by writing kernel drivers
â** fascinating stuff :D
I will try and spend some time this week on this. If not, I'll post an
update here.

Thank you Andrej! Very much appreciated :-) I hope this bug contains
all the information you need.

Yes, they really are, although I must confess the details are a bit
above my head. Kudos for getting to that level of proficiency! By
the way, assuming you're a member of a the Multimedia Team, and are
interested in kernel drivers, are you the Debian guy to contact for
audio interface driver issues (eg: model specific quirks) or wishlist
"please support this new awesome interface or peripheral"? ;-)

Cheers,
Nicholas

Andrej Shadura

2018-10-23 15:09:06 UTC

Permalink

Post by Nicholas D Steeves

Thank you Andrej! Very much appreciated :-) I hope this bug contains
all the information you need.
Yes, they really are, although I must confess the details are a bit
above my head. Kudos for getting to that level of proficiency! By
the way, assuming you're a member of a the Multimedia Team, and are
interested in kernel drivers, are you the Debian guy to contact for
audio interface driver issues (eg: model specific quirks) or wishlist
"please support this new awesome interface or peripheral"? ;-)

Haha, I’m just a beginner — this is my first driver, and it’s not
related to multimedia (a driver to support a hardware random number
generator in U2F Zero).
So far this is my fourth patch to the Linux kernel; nevertheless, it’s
quite some fun to work with that and see how things work (or not — and
crash your system if you’re not careful *or* if you don’t run tests in
a qemu).

--
Cheers,
Andrej

Nicholas D Steeves

2017-12-10 23:12:39 UTC

Permalink

Hi Francesco, John, and everybody else reading this,
[...]

Post by Francesco Poli
Failing to retain the license text in the package distribution is in
fact lack of compliance with the 2-clause BSD license, I would say...

Post by Nicholas D Steeves
and also how
this should be resolved. The Debian packaging is GPL-2+, so it's
possible to move to copyright-format/1.0 if that would simplify
things.

Thanks for the clarification. I guess I've dropped the offending
patch in git and am currently working on a copyright-format/1.0
debian/copyright.

Will I also need to provide formal copies in debian/COPYING.emails or
would a README.copyright or similar pointing to the bug report
suffice? In particular I'm concerned about lines like this from
d/copyright:

"po/uk.po" is © 2005 Mykola Lynnyk and is distributed under the terms of the
GPL.

Where the new po/uk.po is GPL-incompatible 2-clause BSD:

# Ukrainian translation for Audacious
# Copyright (C) Audacious translators
# This file is distributed under the same license as the Audacious package.
#
# Translators:
# Dennis <***@gmail.com>, 2014
# Eugene Paskevich <***@raptor.kiev.ua>, 2015-2016
# Kostyantyn Fedenko <***@ukr.net>, 2011
# Oleg <***@gmail.com>, 2012
# NaiLi (aka jamesjames) Rootaerc <***@mail.ru>, 2012
# NaiLi (aka jamesjames) Rootaerc <***@mail.ru>, 2012
# Oleg <***@gmail.com>, 2012
# Rax Garfield <***@dvizho.ks.ua>, 2012
# Rax Garfield (http://biokillaz.com/), 2012
# Rax Garfield <***@dvizho.ks.ua>, 2012-2013
# Rustam Tsurik <***@gmail.com>, 2013
# Rustam Tsurik <***@gmail.com>, 2013
# Oleg <***@gmail.com>, 2012
# Taras Shevchenko, 2017
# Yaroslav Yenkala <hyper-***@yandex.ru>, 2016
msgid ""
msgstr ""
"Project-Id-Version: Audacious\n"
"Report-Msgid-Bugs-To: http://redmine.audacious-media-player.org/\n"
"POT-Creation-Date: 2017-08-19 19:12+0200\n"
"PO-Revision-Date: 2017-08-06 05:54+0000\n"
"Last-Translator: Taras Shevchenko\n"

John, what happened here with Mykola Lynnyk's 2005 GPL copyright?

Post by Francesco Poli

Post by Nicholas D Steeves
Also, please reply to point 2. OTTO "ancient plugins...under
different licenses. I assume audacious-plugins will also need a
copyright review.

Probably.

I took a cursory glance and it seems to be in better shape than the
main audacious package but I'll take a look later.

Post by Francesco Poli

Post by Nicholas D Steeves
Please CC John and I, Bug #883731, and
debian-legal as appropriate.

Done.
I hope my comments may help.
Bye and thanks to the Debian Multimedia Maintainers for the time they
spend in maintaining a number of great Debian packages, and to the
Audacious upstream developers for the time they spend in
developing/maintaining that very nice audio player (that I personally
use everyday!). Thank you!

Thank you Francesco, your comments do help. I'm also a big fan of
Audacious and use it all the time. (thank you John!) Oh, and if
everything goes according to plan we'll have a qt variant again
sometime in 2018 (one src:package will build the gtk variant, cleanup,
build the qt variant, and then package the two variants separately).

Cheers,
Nicholas

Francesco Poli

2017-12-10 23:23:47 UTC

Permalink

On Sun, 10 Dec 2017 18:12:39 -0500 Nicholas D Steeves wrote:

[...]

Post by Nicholas D Steeves
GPL-incompatible 2-clause BSD

[...]

A nitpick: the 2-clause BSD license is not GPL-incompatible (it's
indeed compatible with the GNU GPL).
It's just a distinct license with different (and much simpler)
wording...

Nicholas D Steeves

2017-12-10 23:28:05 UTC

Permalink

Post by Francesco Poli
[...]

Post by Nicholas D Steeves
GPL-incompatible 2-clause BSD

[...]
A nitpick: the 2-clause BSD license is not GPL-incompatible (it's
indeed compatible with the GNU GPL).
It's just a distinct license with different (and much simpler)
wording...

Good point. I ought to have phrased that differently ;-) What I mean
is that a GPL piece cannot become a BSD piece without explicit
relicensing by all copyright holders.

John Lindgren

2017-12-11 05:28:43 UTC

Permalink

Post by Nicholas D Steeves
In particular I'm concerned about lines like this from
"po/uk.po" is © 2005 Mykola Lynnyk and is distributed under the terms of the
GPL.

The line "Copyright (C) 2005 Mykola Lynnyk <...>" appears to have been
lost accidentally in commit 1a013156d209b, when we switched over to
Transifex. I'll see about restoring it.

As far as our Git history goes back (to October 2005), uk.po had no
license declaration and was assumed to be under the same license as the
source files it translated (which at the time was GPLv2+). At the time
of the BSD relicense, we took the liberty of assuming that such
translations would automatically switch to the new license along with
the source files they translated. No one (to my knowledge) has
contacted us in the five years since to clarify that their translations
were intended to be forever GPL-only, but I suppose that to take a more
cautious approach, Debian could still distribute the package as GPL in
total.

Post by Nicholas D Steeves
Oh, and if
everything goes according to plan we'll have a qt variant again
sometime in 2018 (one src:package will build the gtk variant, cleanup,
build the qt variant, and then package the two variants separately).

+1 from me!

John

Ian Jackson

2017-12-11 15:03:09 UTC

Permalink

Post by Nicholas D Steeves
Will I also need to provide formal copies in debian/COPYING.emails or
would a README.copyright or similar pointing to the bug report
suffice? In particular I'm concerned about lines like this from

Please put all the necessary information in the source package.

COPYING.emails is only one filename you might choose to use. If you
want to download multiple pages, or something, you can put them in
separate files. It's probably a good idea to download them with w3m
-dump or something. That produces a human-readable file which doesn't
depend on any external HTML assets.

This is much better than simply urls, because (sadly), urls often rot.
The lifetime of the contents in debian/ is controlled by Debian and
often exceeds, by large factors, the lifetime of upstream source
repositories, bug trackers, etc.

It would be a best praqctice to record the contents _and also_ the url
you got it from, and the date you downloaded it. That way the
information you give is verifiable while the url is still active; and
if the url rots, the information (attribution, etc.) is not lost.

So in summary, I would
w3m -dump https://bugtracker/whatever > debian/COPYING.issue4391.txt
and make an overview file (COPYING.emails maybe) referring to
these other files.

Thanks,
Ian.

Nicholas D Steeves

2017-12-12 21:39:28 UTC

Permalink

Hi Ian, Francesco, John, and everyone else reading this,

Post by John Lindgren

Post by Nicholas D Steeves
In particular I'm concerned about lines like this from
"po/uk.po" is © 2005 Mykola Lynnyk and is distributed under the terms of the
GPL.

The line "Copyright (C) 2005 Mykola Lynnyk <...>" appears to have been
lost accidentally in commit 1a013156d209b, when we switched over to
Transifex. I'll see about restoring it.
As far as our Git history goes back (to October 2005), uk.po had no
license declaration and was assumed to be under the same license as the
source files it translated (which at the time was GPLv2+). At the time
of the BSD relicense, we took the liberty of assuming that such
translations would automatically switch to the new license along with
the source files they translated. No one (to my knowledge) has
contacted us in the five years since to clarify that their translations
were intended to be forever GPL-only, but I suppose that to take a more
cautious approach, Debian could still distribute the package as GPL in
total.

For Debian Legal Team: With respect to the translations, I now suspect
they can probably be transitioned to BSD without issue, because
copyright is also assigned to the Audacious Translators. eg, in the
last GPL-2+ release 3.2.4:
Copyright (C) Audacious translators

Would you please confirm? It would be nice to be able to simplify the
issue of relicensing for the translations :-) Also, would you please
confirm or deny the necessity of the work outlined in the second half
of this email?

John, I removed the offending patch in git for the user-visible
license provided by the Audacious GUI. Then I went ahead and did a
historical relicensing review, in spite of the potential for other
missing copyright holders due to the Transifex switch. I am a bit
concerned about what looks to be a politic of "silence is consent" wrt
relicensing, and hope that I am wrong, or that I was sloppy in my
review. Was the discussing conducted informally off the record?

By the way, I definitely support every author's right to choose a
preferred license, so I'm not troubled with a transition to BSD
licensing ;-) This is one of the reasons the FSF demands copyright
assignment for their projects...they want to be able to relicense at
any point in the future without having to contact and document consent
from all contributors.

Would you please take a look at the following (Ian's reply) for an
example of how to provide a record of all copyright holder's consent?
tldr; documented confirmation (eg: via copies of emails or a download
of a bug report/issue/forum thread) for all contributors who did not
assign copyright to the Audacious Team in the headers of the files
they contributed to. I would be happy to generate such a file[s] if
you can point me in the right direction[s].

Post by John Lindgren

Please put all the necessary information in the source package.
COPYING.emails is only one filename you might choose to use. If you
want to download multiple pages, or something, you can put them in
separate files. It's probably a good idea to download them with w3m
-dump or something. That produces a human-readable file which doesn't
depend on any external HTML assets.
This is much better than simply urls, because (sadly), urls often rot.
The lifetime of the contents in debian/ is controlled by Debian and
often exceeds, by large factors, the lifetime of upstream source
repositories, bug trackers, etc.
It would be a best praqctice to record the contents _and also_ the url
you got it from, and the date you downloaded it. That way the
information you give is verifiable while the url is still active; and
if the url rots, the information (attribution, etc.) is not lost.
So in summary, I would
w3m -dump https://bugtracker/whatever > debian/COPYING.issue4391.txt
and make an overview file (COPYING.emails maybe) referring to
these other files.

Specific commits I couldn't find documented consent for, and which
didn't have have copyright assigned to the Audacious Team in the last
stable GPL-2+ release (3.2.4). From the git history I see it was a
lot of work to transition to BSD! Here are a couple examples
copyright holders that I believe Audacious will need explicit consent
from (see above) for relicensing to BSD:

42cbe57307962e65acc2db24dbe99249453c6aac
b308c892f47a55c63ef2675f9b6cf016be037f4c
31ea4ad1adb84f37ce8fff5b4868df247bd6d913
df1165d2fdd8470b2fd45d2e87cac5373055b55e
9a979a5af95eb663435ef99d3b7b5c79b94855be
33b58d4d8ba18fcbcc36af5c650414e173e22396
* Do you have consent on file to move to BSD license for all
contributors to XMMS and BMP?

bc295976816358f9512f99a78e933e6594cce121
853f96f54bbca608f0c95b5e8bf3fd2146607bdd
3d2ca792a02973fb5e2f33d6273aac825d4f3a55
a0655119b4e2b54c7879bd3dccdbc244ba07c318
* Do you have consent on file to move to BSD license for all
contributors to XMMS and BMP?

One can infer William Pitcock's consent to switch to BSD licensing
here, especially because he authored and commited other patches to
switch his code to BSD license, so I've omitted commits from others
that affected files where he alone was/is the copyright holder:
419176b6a4876daaca55a95b60ce51b786534961

320ffbb1a063c69f769683b0afc2726a3c87c89f
788fb88b010f1267c8de9b3f5e4216605064eac8
b58af7e570f893be4585cc924435a947146b3b04
63a743a785c79013c7a47fcd94a79ca14cac7688
aff7adac8e8f5e2143cd2654edeadfb37f033a43
1d699bdbde6151db05ccd83c8c857bd33e6660bb
0284a462e096a6d98233681e6c94cd3256bb7445

List of GPL-2+ copyright holders from last stable GPL release (3.2.4):
https://github.com/audacious-media-player/audacious/blob/audacious-3.2.4/AUTHORS

And debian/copyright (gpl-2+ licensed document) that hasn't seen
significant updates since audacious-2.3; however, I'm linking to it in
the hopes that it will help you track down anything lost in the
Transifex switch:
https://anonscm.debian.org/git/pkg-multimedia/audacious.git/tree/debian/copyright

It's a PITA, and a lot of work, but I believe that it's necessary for
Debian to confirm the successful relicensing of Audacious from GPL-2+
to BSD 2-clause. I brought in debial-legal as early as possible so
that they could step in and shout "wait a second, that's pedantic busy
work!" if ever that was the case.

Kind regards,
Nicholas

Francesco Poli

2017-12-12 22:37:46 UTC

Permalink

On Tue, 12 Dec 2017 16:39:28 -0500 Nicholas D Steeves wrote:

[...]

Post by Nicholas D Steeves
This is one of the reasons the FSF demands copyright
assignment for their projects...they want to be able to relicense at
any point in the future without having to contact and document consent
from all contributors.

Yeah, right: they want to do what they like, without asking whether the
contributors are fine with their decisions...
Personally, I consider this FSF copyright assignment policy a very bad
practice!

But I am digressing...

Nicholas D Steeves

2018-10-23 01:46:48 UTC

Permalink

Hi Francesco,

Post by Francesco Poli
[...]

Sorry this email fell through the cracks, even if it is a digression.
I agree that FSF copyright assignment is at odds with the ethos of
empowering the people, because it transfers the people's power to the
organisation--trusting in its beneficence. Oh, and that it's
identical to the people -> communist party power structure (the people
lose power), or the feudal copyright assignment of employee work to
their employers.

That said, it does make project management easier for the legal and
paperwork side--and for keeping things consistent, particularly if
records are ever lost...which counts as a pro, from a top-down
perspective ;-)

I haven't reread the history of this bug, but if I remember correctly
it's a win for GPL if the GPL translations are combined with BSD
sources, because the resulting binaries become inherently GPL,
assuming the translation meet the criteria for copyrightable material
(eg: originality). I understand how to this could be frustrating for
a project manager, which is why I thought it was important to mention
the alternative.

Cheers,
Nicholas

John Lindgren

2017-12-13 02:16:24 UTC

Permalink

Hi Nicholas et. al,

(tallica: This is re: Debian bug #883731, related to the GPL -> BSD
relicensing of Audacious a few years back. Please take a look at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883731 for background
if you're interested, otherwise disregard.)

Post by Nicholas D Steeves
For Debian Legal Team: With respect to the translations, I now suspect
they can probably be transitioned to BSD without issue, because
copyright is also assigned to the Audacious Translators. eg, in the
Copyright (C) Audacious translators

We needed a single copyright line because of the way Transifex is set
up, but it's not meant to indicate copyright assignment. "Audacious
translators" is not a legal entity and just refers to the individual
translators listed in each .po file, who are the copyright holders.

Post by Nicholas D Steeves
John, I removed the offending patch in git for the user-visible
license provided by the Audacious GUI. Then I went ahead and did a
historical relicensing review, in spite of the potential for other
missing copyright holders due to the Transifex switch. I am a bit
concerned about what looks to be a politic of "silence is consent" wrt
relicensing, and hope that I am wrong, or that I was sloppy in my
review. Was the discussing conducted informally off the record?

We took a bit more care with the source code relicensing than with the
translations. I personally went through Git commit logs and replaced
copyrights of "XMMS team", "BMP team", or "Audacious team" (again, none
of which were legal entities) and replaced them with the names of the
actual contributors.

In many cases, files still credited to "the XMMS team" or "the BMP team"
had been totally rewritten and none of the original code that was under
the XMMS/BMP copyright remained. Actually, as of today, no original
XMMS code remains in Audacious core (i.e. the "audacious" package) at
all. The largest body of remaining XMMS code is in the "skins" plugin,
which is still GPL for that very reason.

For the core of Audacious, the remaining copyright holders all gave
consent to relicense their code as BSD, generally by email or via the
IRC channel we had back then. I don't have any of the emails or IRC
logs saved (sorry) but the date of each of the separate Git commits you
listed reflects the point at which we received permission from the
copyright holders listed in those files.

Post by Nicholas D Steeves
Would you please take a look at the following (Ian's reply) for an
example of how to provide a record of all copyright holder's consent?
tldr; documented confirmation (eg: via copies of emails or a download
of a bug report/issue/forum thread) for all contributors who did not
assign copyright to the Audacious Team in the headers of the files
they contributed to.

Unfortunately, such documentation doesn't exist, to my knowledge. I'll
point out any specific information I recall about the commits you mentioned.

Post by Nicholas D Steeves
42cbe57307962e65acc2db24dbe99249453c6aac

The equalizer code was a port from mplayer. The author, Anders
Johansson, was contacted and gave consent for the relicense, and
incidentally also asked that we retain some of his coding style (see the
previous commit to equalizer.c).

Post by Nicholas D Steeves
b308c892f47a55c63ef2675f9b6cf016be037f4c

The session management code was later removed from Audacious, which is
why Ivan and David aren't listed in AUTHORS any longer.

Post by Nicholas D Steeves
31ea4ad1adb84f37ce8fff5b4868df247bd6d913

Michal Lipski (tallica, CC'd) did the footwork in tracking down the
authors of those files, and "where possible" in the commit message
refers to developers who gave consent. Most of the developers listed in
those files were still around on IRC at the time.

Post by Nicholas D Steeves
df1165d2fdd8470b2fd45d2e87cac5373055b55e

"desowin ok'd it" -- desowin is the Tomasz Moń listed in those files.
The rest of us were present on IRC, I think.

Post by Nicholas D Steeves
9a979a5af95eb663435ef99d3b7b5c79b94855be

Jussi Judin was not a core developer at the time; I assume tallica
contacted him.

Post by Nicholas D Steeves
33b58d4d8ba18fcbcc36af5c650414e173e22396
* Do you have consent on file to move to BSD license for all
contributors to XMMS and BMP?

I don't recall the particular IRC discussion referenced in the commit
message, but presumably it was determined that no XMMS/BMP code remained
in those files.

Post by Nicholas D Steeves
bc295976816358f9512f99a78e933e6594cce121

The commit message itself lists the copyright holders who gave consent.
Most of those folks were around on IRC and so I would assume that was
how they were contacted.

Post by Nicholas D Steeves
853f96f54bbca608f0c95b5e8bf3fd2146607bdd

Similar, except that (from what I remember) Paula developed that code
under Tony Vroon (Chainsaw)'s mentorship, and he would have vouched for
her consent.

Post by Nicholas D Steeves
3d2ca792a02973fb5e2f33d6273aac825d4f3a55

Here I was reattributing some files to their actual authors based on Git
logs, as I said earlier. You can see that in this commit, I left the
GPL notice intact on any files whose authors hadn't given consent yet at
that point (but did later on).

Post by Nicholas D Steeves
a0655119b4e2b54c7879bd3dccdbc244ba07c318
* Do you have consent on file to move to BSD license for all
contributors to XMMS and BMP?

I assume you refer to audstrings.[c,h]? None of the remaining code in
those two files is from XMMS/BMP. 95% of it I wrote myself; some small
bits are probably still William Pitcock (nenolod)'s.

Post by Nicholas D Steeves
One can infer William Pitcock's consent to switch to BSD licensing
here, especially because he authored and commited other patches to
switch his code to BSD license, so I've omitted commits from others
419176b6a4876daaca55a95b60ce51b786534961

Hold on ... that's a different beast altogether. That commit is from
2007, which was before I was involved in the project. nenolod was the
project lead at that time. Anyway, the commit isn't directly related to
the 2012 relicensing but appears to be reverting a prior effort that
failed due to a lack of consent from some (unnamed) developers at that
time. Note that a number of the files listed were later moved to
audacious-plugins, and remain GPL to this day.

Post by Nicholas D Steeves
320ffbb1a063c69f769683b0afc2726a3c87c89f
788fb88b010f1267c8de9b3f5e4216605064eac8
b58af7e570f893be4585cc924435a947146b3b04
63a743a785c79013c7a47fcd94a79ca14cac7688
aff7adac8e8f5e2143cd2654edeadfb37f033a43
1d699bdbde6151db05ccd83c8c857bd33e6660bb
0284a462e096a6d98233681e6c94cd3256bb7445

These are all from 2007 as well, and are presumably the commits reverted
by 419176b6a487. (The project remained GPL for another 5 years after.)

Post by Nicholas D Steeves
https://github.com/audacious-media-player/audacious/blob/audacious-3.2.4/AUTHORS

I assume you also noticed the disclaimer right at the top, "This file is
quite out of date"? The vast majority of the code written by the people
listed in that file has been removed, replaced, or moved to
audacious-plugins. That was true back in 2012, but even more so in 2017.

Post by Nicholas D Steeves
It's a PITA, and a lot of work, but I believe that it's necessary for
Debian to confirm the successful relicensing of Audacious from GPL-2+
to BSD 2-clause. I brought in debial-legal as early as possible so
that they could step in and shout "wait a second, that's pedantic busy
work!" if ever that was the case.

Personally, I can't invest very much time supporting the effort (sorry).
Hopefully you can consider at least the C code in Audacious core all
set, given the history I gave you above. The translations are likely to
be more of a problem. Depending on how pedantic you decide to be, I
suppose the documentation effort could involve going through all the
translations and contacting any pre-2012 authors to confirm their
permission (or alternatively removing and retranslating any pre-2012
strings, if they were a small enough fraction).

Especially considering that audacious-plugins is still a mixed BSD/GPL
package anyway, an alternative would be to add a clause to the COPYING
file to the effect of, "some bits are/may be GPL still". I don't think
I will do this upstream; my approach would more likely be to remove or
replace any offending bits as needed if/when someone complains.
However, I can understand if Debian were to consider my approach too
"casual" and wanted to take the more conservative approach of "we're
still distributing Audacious as GPL until proven otherwise". As someone
already pointed out, that's compatible with the upstream BSD license
*provided that* the upstream license is still included in full.

Best regards,
John