Re: Expat license and "free for academic users"

[Nicholas D Steeves]

Francesco Poli  writes:

> On Tue, 20 Jun 2023 10:14:41 +0300 Andrius Merkys wrote:
>> 
>> [Please keep me in CC, I am not subscribed]
>> 
>> I encountered a package EvoEF2 [1] which is licensed under Expat and has 
>> the following in its README.md:
>> 
>> "EvoEF2 is free to academic users."
>> 
>> To me such limitation seems to contradict the Expat license, but I 
>> wonder what is the legal opinion about such combination. I know that I 
>> can always ask the upstream for clarification which I did earlier when 
>> the restriction was:

1. EvoEF2 is licensed Expat
2. Expat makes EvoEF2 free for all users
3. "EvoEF2 is free to academic users."
4. I am a[n] [academic] user
5. EvoEF2 is free for me.

#3 is redundant because it is a subset of #2.

vs

1. EvoEF2 is licensed Expat
2. Expat makes EvoEF2 free for all users
3. "EvoEF2 is free to academic users."
4. I am a [commercial or nonacademic] user
5. EvoEF2 is free for me.

At #2, all users, includes nonacademic, commercial, etc.  #3 becomes an
editorial: a statement of the anticipated audience and nothing more.

> Well, take into account that I am not a lawyer.

I'm also not a lawyer and this is not legal advice.

> Anyway, to me, the sentence "EvoEF2 is free to academic users." looks
> a little misleading.

Agreed.

> One could nitpick that the sentence is not false: it's true that EvoEF2
> is free to academic users, since it's released under the Expat license,
> and therefore it's free to everyone, including academic users.
>
> However, the sentence may make the reader think that EvoEF2 is free
> _only_ to academic users, although it does not say so.

I agree that this is the important part!  It seems legally nonbinding to
me, and not nice to the reader.

Also, I think it would be a stretch to successfully argue that the
antecedent of a redundant statement in the README somehow acts as an
addendum to the LICENSE, such that the license is no longer Expat.
Maybe there are some parts of the world were this is how an addendum
works, but I think the additional statements usually need to be
explicitly defined as such. ie: "This is an addendum to the LICENSE...I
limit the LICENSE in the following way...".

> I would suggest to once again get in touch with upstream and persuade
> them to drop that sentence, or perhaps to replace it with something
> like "EvoEF2 is free to all users."

Agreed!  On the other hand, if the author intends to forbid commercial
use, then the license should say so.  While not great for the community,
that may also be what the author wishes for...

Cheers,
Nicholas


signature.asc
Description: PGP signature

RFC about DFSG-freeness of PHP license [Re: Bug#903999: ITP: php-doc -- Documentation for PHP]

[Nicholas D Steeves]

Hi Athos,

Thank you for working on this RFP, and for doing all the work involved
with reintroduction the package.

I'm CCing the debian-legal team who I hope will be able to help with
the stylesheet question and related issues; I've given it my
best-effort, but would appreciate someone else's perspective

My reply, in context, follow inline:

Athos Ribeiro  writes:

> On Wed, Sep 28, 2022 at 08:11:14AM +0800, Paul Wise wrote:
>>On Mon, 2022-09-26 at 16:23 -0300, Athos Ribeiro wrote:
>>
>>> As mentioned in the original report (RFP), this package was
>>> originally removed from the archive due to Bug #821695, when it was
>>> not updated during the PHP 7 transition.
>>
>>If you weren't already aware, please note the extra steps needed when
>>reintroducing packages that were removed from Debian (e.g. bug reopen):
>>
>>https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs
>
> Hi Paul, Thanks for the pointers.
>
> While I am working on packaging details, I still want to make sure it is
> OK to re-introduce the package due to the PHP-3.0 issues I pointed
> before.
>

Do you mean the PHP-3.0[-only] issue:

  https://lintian.debian.org/tags/license-problem-php-license

which appears to be the same as the PHP-3.1[-or-greater?] issue?

  https://ftp-master.debian.org/php-license.html

Is the problem you're referring appears to be that this license places
limitations on the use of the term "PHP"?  Were this limitation on
endeavour, it would be non-DFSG, but honestly I'm a bit surprised that
php8.1 is in Debian main...eg: that it's DFSG-free.  I'm also not sure
why the Apache license isn't problematic for this same reason.

At any rate, as far as I can tell this is something for the ftpmasters
to worry about, so long as you follow the instructions at the above two
links as well as consulting the PHP package for examples.  Ie this means
is that the debian/ subdir must have a more permissive license than the
PHP one (eg: Expat).

> On top of that, I needed to change one of the build time internal
> dependencies so we wouldn't end up with (hundreds of) broken links. This
> led to the need of clarification on
> https://github.com/php/web-php/issues/711 by the upstream project.
> If the stylesheets provided are indeed proprietary, I will need to write
> our own.
>

Oh my!  Yes, after reading that issue (quoted below):

>> The following files are referred to and fetched from phd when
>> building with the PHP package (in
>> phpdotnet/phd/Package/PHP/ChunkedXHTML.php):
>>
>>   https://www.php.net/styles/theme-base.css (styles/theme-base.css)
>>   https://www.php.net/styles/theme-medium.css (styles/theme-medium.css)
>>

The copyright text on the PHP website is

Except as otherwise indicated elsewhere on this Site, you are free
to view, download and print the documents and information available
on this Site subject to the following conditions:

  * You may not remove any copyright or other proprietary notices contained
in the documents and information on this Site.

  * The rights granted to you constitute a license and not a
transfer of title.

  * The rights specified above to view, download and print the
documents and information available on this Site are not
applicable to the graphical elements, design or layout of this
Site. These elements of the Site are protected by trade dress
and other laws and may not be copied or imitated in whole or in
part.
(https://www.php.net/copyright)

To me it sounds like 1. No rights to redistribute the website (in whole
or in part) are granted, except where the part is a separate project
with its own license (php-docs).  2. No one has a license to view,
download, or print the stylesheets.

Were the second claim to be maintained, a consequence of this would
seems to be that only the copyright holder[s] could build the
unpatched documentation without committing copyright infringement.

>> While the phd project is shipped under MIT/BSD licenses, web-php and
>> its files
>> have no other license notices other than the notice on copyright.php
>> which says that the design and layout of php.net is protected by
>> trade dress and should not be copied nor imitated. Does this apply to
>> both files above? In special, styles/theme-base.css seems to be
>> derived from bootstrap, and the apache license disclaimer was
>> kept. Is it still ditributed through the apache license then?

Good point; however, the Apache license allows relicensing (so long as
various conditions are met).  Were the PHP project to not do this, they
would be in breach of the Apaache license, and we still wouldn't be able
to redistribute.

Given the copyright notice published to the PHP website, I think you're
right about how the only workaround is to replace their stylesheets!
Please note that network access is blocked during the builds of all
Debian packages (packages in non-free are not part of Debian).

I also 

do SPDX declaration fulfill §17 of GPL?

[Nicholas D Steeves]

Hi,

I found a problematic change in one of my packages:

  
https://github.com/KDE/kio-gdrive/commit/6321fda6294e3d021b7a2758c1200aa42debb021

This looks like a regression of license validity to me, because the
fulfillment of §17 of the GPL was removed from the affected files, and I
suspect that we don't accept standalone SPDX declarations as valid in
ambiguous cases like this one...

Especially when they're as confusing as "GPL-2.0-only OR GPL-3.0-only OR
LicenseRef-KDE-Accepted-GPL", when the provided GPL-3.0-only is
identical to the provided GPL-3.0-or-later, and the restriction of
"only" is not reflected in any headers nor the license text for
GPL-3.0-only.

Finally, the intent of David Barchiesi appears to have been GPL-2+ OR
GPL-3+...with "KDE e.V." restriction on forward compatibility, but this
is not reflected in the provided
https://github.com/KDE/kio-gdrive/commit/6321fda6294e3d021b7a2758c1200aa42debb021#diff-39989992dd1286c14401f7fd5ddc9cdf08c61ebe75659cc148678f13b75049b6

Despite the mess, it appears that the licenses will evaluate to
bin:kio-gdrive as a whole being GPL-3.0-only work, but confidence in
that is low if SPDX declarations do not fulfill §17 of GPL.

I don't want to exploit the fact that the package is already in Debian
as a way to bypass what seems like it might otherwise have been an
ftpmaster reject.


Thank you in advance for your comments!
Nicholas


signature.asc
Description: PGP signature

Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

Hi,

Adrian Bunk  writes:

> On Fri, Jul 10, 2020 at 07:48:31PM -0400, Nicholas D Steeves wrote:
>
>> it would still not be DFSG-free, because it
>> fails the "desert island test" for snail mail.  Were OmniTI Computer
>> Consulting would accept email, it would also fail the "dissident test".
>
> This is the first time I see someone claiming BSD-4-clause would not
> be distributable.
>

Well, BSD-4-clause isn't on the list of DFSG-approved licenses...

  https://wiki.debian.org/DFSGLicenses

>> Finally, BSD-4-clause is not an approved license in KDE projects
>>   https://community.kde.org/Policies/Licensing_Policy
>
> Policies for new source code added in KDE are not relevant in Debian.
>
>> Feel free to escalate this issue...I'm humble and am comfortable with
>> being shown the error of my ways, but I believe this is a genuine
>> problem.
>
> Yes, it would be good if other people from debian-legal would comment.
>

Agreed :-)


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

Hi Adrian,

Adrian Bunk  writes:

> On Fri, Jul 10, 2020 at 06:33:32PM -0400, Nicholas D Steeves wrote:
>> Adrian Bunk  writes:
>> > On Fri, Jul 10, 2020 at 03:38:57PM -0400, Nicholas D Steeves wrote:
>> >>...
>> >> * Neither name of the company nor the names of its contributors may be 
>> >> used to endorse or promote products derived from this software without 
>> >> specific prior written permission.
>> >> 
>> >> I'm not 100% certain that bundling dprof2calltree with kcachegrind 
>> >> constitutes a "product[s] derived from this software", because I'm also 
>> >> of the opinion that bundling != derivation, but it seems like a lawyer 
>> >> might argue the it does.  So kcachegrind and any distributions' package 
>> >> would also need written persmission from OmniTI Computer Consulting.
>> >>...
>> >
>> > You are arguing the 3-Clause BSD License would be non-free?
>> 
>> No, because dprof2calltree is modified 4-Clause BSD.
>
> dprof2calltree uses a verbatim copy of 4-Clause BSD
> (except for filling the company placeholders).
>
> This clause is one of the 3 clauses that are identical in 3-clause and 
> 4-clause BSD.
>

I'm aware of 4-clause to 3-clause BSD similarities and history.

>> > On Fri, Jul 10, 2020 at 03:53:48PM -0400, Nicholas D Steeves wrote:
>> 
>> It fails the "desert island test" because
>> 
>> 1. Any mention of the features or use of this software requires
>> user-facing display of the text "This product includes software
>> developed by OmniTI Computer Consulting".
>> 
>> 2. OmniTI Computer Consulting's name cannot be used to "without specific
>> prior written permission"
>> 
>> The desert island does not have the paper snailmail service required to
>> fulfil #2 (4th clause of the license).
>
> The 4-clause BSD license is around for 30 years, everyone else 
> (including the FSF[1]) does not interpret it the way you do
> that there would be a conflict between these two clauses.
>
> cu
> Adrian
>
> [1] https://www.gnu.org/licenses/license-list.html#OriginalBSD

Did you read the text at that link?  "it *does* cause practical
problems, including incompatibility with the GNU GPL [emphasis mine]"

Also here https://infogalactic.com/info/License_compatibility

Many of the most common free software licenses, especially the
permissive licenses, such as the original MIT/X license, BSD
licenses (in the three-clause and two-clause forms, *though not the
original four-clause form*), MPL 2.0, and LGPL, are
"GPL-compatible". That is, their code can be combined with a program
under the GPL without conflict and the new combination would have
the GPL applied to the whole (not the other license) [emphasis
mine].

Finally, the "desert island test" is a DFSG test, and not a DFSG test.
Were you to provide proof from a legal team that the BSD-4-clause was
somehow GPL-compatible, it would still not be DFSG-free, because it
fails the "desert island test" for snail mail.  Were OmniTI Computer
Consulting would accept email, it would also fail the "dissident test".

Finally, BSD-4-clause is not an approved license in KDE projects
  https://community.kde.org/Policies/Licensing_Policy

Feel free to escalate this issue...I'm humble and am comfortable with
being shown the error of my ways, but I believe this is a genuine
problem.


Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work

[Nicholas D Steeves]

Hi Adrian,

Adrian Bunk  writes:

> On Fri, Jul 10, 2020 at 03:38:57PM -0400, Nicholas D Steeves wrote:
>>...
>> * Neither name of the company nor the names of its contributors may be used 
>> to endorse or promote products derived from this software without specific 
>> prior written permission.
>> 
>> I'm not 100% certain that bundling dprof2calltree with kcachegrind 
>> constitutes a "product[s] derived from this software", because I'm also of 
>> the opinion that bundling != derivation, but it seems like a lawyer might 
>> argue the it does.  So kcachegrind and any distributions' package would also 
>> need written persmission from OmniTI Computer Consulting.
>>...
>
> You are arguing the 3-Clause BSD License would be non-free?
>

No, because dprof2calltree is modified 4-Clause BSD.

> On Fri, Jul 10, 2020 at 03:53:48PM -0400, Nicholas D Steeves wrote:
>>...
>> At the very least, it appears that the advertising clauses make
>> dprof2calltree not DFSG-free,
>
> It does not:
> https://www.debian.org/legal/licenses/
>
>> because they fail the "desert island test".
>>...
>
> It does not.
>
> If you choose to advertise the use of this software on your desert 
> island, you have to include the acknowledgement in your advertisement.
>

It fails the "desert island test" because

1. Any mention of the features or use of this software requires
user-facing display of the text "This product includes software
developed by OmniTI Computer Consulting".

2. OmniTI Computer Consulting's name cannot be used to "without specific
prior written permission"

The desert island does not have the paper snailmail service required to
fulfil #2 (4th clause of the license).


Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Commercial Use and Source Code

[Nicholas D Steeves]

Hi Aron,

On Fri, Jul 19, 2019 at 01:56:14PM -0400, Aron Reman wrote:
>Hi,
>Thank you for the response. I just wanted some clarification. Under the
>Debian license, I do not have to release source code as long as I am
>writing my source code on top of the existing system correct? As in, I am
>writing C/C++ code and running it on a Debian OS, which will be on my
>product that is going to be sold commercially. It is my understanding that
>under these conditions, I do not need to make my source code public.
>Thanks,
>Aron

It's important to note that any "Debian license" is usually limited
the the debian/* contents of a package.  Assuming you're not modifying
this, then there's no issue with potential violation of
Debian-specific copyright holders.

That said, is your "C/C++ code" 100% your own work, or does it build
on an existing package?  For example, let's say you work for a storage
company, you're developing a NAS product, and you'd like to modify
smartmontools to correctly read your drives' status.  If this modified
smartmontools is distributed on your NAS product, then those
modifications are bound by the smartmontools license terms.  To check
for stuff like this, see the package's corresponding copyright file.
eg, in this case: /usr/share/doc/smartmontools/copyright.  Your
lawyers should additionally ask you to audit the upstream source to
confirm that this convenience copy is accurate.

There are also tricky cases like QT, or at least a license like what
QT used to have.  That is to say, a license which grants distribution
rights for noncommercial use, but requires the purchase of a
commercial license for use in proprietary software.  I'm not sure if
the QT case is still current, but it's one reason why proprietary
software traditionally chose to use GTK rather than QT.

Finally, there's also software licensed under various BSD or MIT
licenses that explicitly allows proprietary modifications to be made
without a legal duty to provide the source code of modified parts.
Once again, check /usr/share/doc/package/copyright, and have your team
double-check.

Finally, also in the case of embedded, I believe one continues to have
a duty to provide the source code (plus modifications to the parts
that require it).  This is like AOSP and router firmwares. eg: you can
distribute proprietary *applications with* GPL software, but you can't
distribute proprietary *modifications to* GPL software.  eg:

  
https://www.zdnet.com/article/symantec-may-violate-linux-gpl-in-norton-core-router/


Regards,
Nicholas

P.S. To everyone reading this, can we put this answer somewhere on the
debian.org, or is there a URL that already exists that we can refer
people to?

signature.asc
Description: PGP signature

Re: do I need to mention tiny change in copyright file

[Nicholas D Steeves]

Hi Joël,

On Fri, Mar 01, 2019 at 01:38:56PM +0100, Joël Krähemann wrote:
> Hi,
> 
> Do I need to mention the person submitted 3 patches in
> debian/copyright file, containing a total of 5 lines changed in my
> package?
> 
> I have attached the patches. Upstream did a notice in ChangeLog and
> AUTHORS as tiny change, as recommended by:
> 
> https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
> 
> bests,
> Joël

There seems to be a convention to credit the patch submitter in
d/changelog with "thanks to Name Family_Name" when the patch is not
legally significant.  When a patch is legally significant it must be
documented in d/copyright.

Of course if the patch submitter also submitted a changelog entry, or
if the patch imports in such a way that it generates one crediting the
author, I'll retain that.

Oh, and this is in addition to proper DEP-3 headers where the
submitter is credited and the source is provided.  When a patch is
cherry picked from upstream, it falls under upstream's copyright, and
I tend to believe that a DEP-3 header demonstrating upstream is the
origin is sufficient, and that upstream's "Files: *" stanza doensn't
needed to be extended to say "Files: *
debian/patches/cherry-picked-commit.patch".  Once again, if it's not
legally significant it shouldn't be added to d/copyright, but DEP-3
headers should still be used.


I'm sure more experienced members of this list can add something to
the intersection of best practises and potential mountain of paperwork
;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#903092: [RSVP] php-elisp: permission to relicense contributions required from past contributors

[Nicholas D Steeves]

Hi Francesco,

Thank you for your reply, and sorry for the delay in my own.  Reply
follows inline.

On Sat, Feb 02, 2019 at 10:18:39AM +0100, Francesco Poli wrote:
> On Fri, 1 Feb 2019 16:46:07 -0700 Nicholas D Steeves wrote:
> 
> > Dear Ola, Pontus, and Debian Legal team,
> 
> Hello!
> 
> > 
> > It seems Thierry is MIA, and will not be confirming permission to
> > relicense his contributions to d/changelog and d/control.  Please let
> > me know if the following blocks moving to GPL-3+ debian/* and a
> > machine-readable format: 1.0 debian/copyright.  At this point I
> > suspect it does, but I am erring on the side of caution.
> 
> Do I understand correctly that the content of php-elisp/debian/* is
> currently licensed under the terms of the GNU GPL v2 or later?
> 
> If this is the case, since GPL-3+ is compatible with GPL-2+, what's
> wrong in keeping Thierry's contributions under GPL-2+, while the
> remainder of debian/* is migrated to GPL-3+ ?
> The effective resulting licensing status for debian/* would still be
> GPL-3+, although the debian/copyright file would be slightly less
> simple, but, oh well, I guess you could live with that...
> Or am I missing anything important?
> 
> I hope this helps.
> Bye!
> 

Yes, that does help, thank you.  And yes, an extra stanza and license
in d/copyright is nothing compared to doing a manual copyright check
of an old package not in VCS, without the help of 'git blame'.

Please see the last paragraph of my last message in this thread for a
proposal that would save everyone time working through stuff like this.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#903092: [RSVP] php-elisp: permission to relicense contributions required from past contributors

[Nicholas D Steeves]

Hi Giacomo!

Thank you for your reply, and sorry for the delay in my own.

On Sat, Feb 02, 2019 at 10:54:32AM +, Giacomo wrote:
> I'm one of the old contributors: years ago I did the port from PHP4 to PHP5.
>

Wow, thank you for that work upstream :-)

> To be honest I can't recall if my contribution was done under GPLv2 or GPLv3 
> (or if it included the "or later" option), but I guess it was GPLv2+ as GPLv3 
> was yet to come.
> 
> In any case why restrict the license to GPLv3+ that is incompatible with 
> GPLv2 while the current license is compatible with both GPLv3 and GPLv2?
> 
> 
> Is there any strategic advantage for users' freedom I miss?
> 
> If not, I think that the php-mode would benefit to stay GPLv2+.
> 

I agree, and also prefer GPLv2+ for similar reasons.  I don't remember
when it happened off the top of my head, but FYI upstream changed
maintainers and relicensed to GPLv3+.

  https://github.com/emacs-php/php-mode/issues/387
  https://github.com/ejmr/php-mode

Getting confirmation of copyright for debian/changelog for
contributors who are long gone is an annoying issue when moving to
copyright-format 1.0...  In this case, luckily, Ola is still around to
answer the question of what debian/* packaging was originally intended
to be licensed as!  :-)

It would be nice if there was an official statement from debian-legal,
codified somewhere, saying that  1) for a package that does not use
machine-readable copyright-format 1.0  2) when the original packager is
able to confirm the license of debian/*,  3) then all subsequent
contributions to debian/changelog fall under that license.  I doubt
I'm the only contributor who was mentored to be strict about these
things, and then ended up taking up a bunch of people's time for
paperwork...


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#903092: [RSVP] php-elisp: permission to relicense contributions required from past contributors

[Nicholas D Steeves]

Dear Ola, Pontus, and Debian Legal team,

It seems Thierry is MIA, and will not be confirming permission to
relicense his contributions to d/changelog and d/control.  Please let
me know if the following blocks moving to GPL-3+ debian/* and a
machine-readable format: 1.0 debian/copyright.  At this point I
suspect it does, but I am erring on the side of caution.

On Mon, Jul 30, 2018 at 05:46:27PM +0200, pon...@ullgren.com wrote:
>This is acceptable by me.
>// Pontus
> 
>  > On Thu, Jul 05, 2018 at 09:01:30PM -0400, Nicholas D Steeves wrote:
>  >> Package: php-elisp
>  >> Version: 1.13.5-3
>  >> Severity: normal
>  >>
>  >> Dear Ola, Moritz, Thierry, and Pontus,
>  >>
>  >> The Debian Emacsen team is adopting php-elisp.Ã*  At this time we
>  would
>  >> like to move to machine-readable copyright format 1.0 and harmonise
>  >> update the copyright of debian/* to GPL-3+, which upstream has
>  >> migrated to.
>  >>
>  >> Please reply to this bug to confirm that you consent to GPL-3+
>  >> relicensing of your past contributions.
> 
>  Php-elisp is ready to upload. Would you please confirm if GPL-3+ is
>  an acceptable license for your contributions to this package?

d/copyright:

  This package was debianized by Ola Lundqvist  on
  Mon, 26 Feb 2001 21:33:20 +0100.
  New co-maintainer since Thu, 14 Aug 2003 18:30:27 +0200 is
  Pontus Ullgren .

  It was downloaded from:
  https://github.com/ejmr/php-mode

  Copyright:
 Copyright (C) 1999, 2000, 2001, 2003, 2004 Turadg Aleahmad
   2008 Aaron S. Hawley
   2011, 2012, 2013, 2014 Eric James Michael Ritz

  License:

  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License
  as published by the Free Software Foundation; either version 2
  of the License, or (at your option) any later version.


d/changelog:
...
php-elisp (1.5.0-1.1) unstable; urgency=low

  * Non-maintainer upload.
  * Prevent byte compilation on xemacs21, since it's incompatible
(Closes: #584698)

 -- Moritz Muehlenhoff   Thu, 05 Aug 2010 16:37:37 -0400

php-elisp (1.5.0-1) unstable; urgency=low

  * New upstream release (Closes: #368061, #291207)
  * New maintainer (Closes: #525947)
  * debian/control:
+ bumped Standards-Version to 3.8.4
+ added ${misc:Depends} in Depends
+ updated Depends to emacs23 | emacs22 | emacsen
+ updated Suggests to php5 | php5-cli
+ updated Section to lisp
+ added in Recommends field speedbar (Closes: #500120)
+ used debhelper 7
+ added Homepage field
+ added texi2html in Build-Depends to generate manual (Closes: #476197)
  * debian/rules:
+ removed emacs21 references (Closes: #269650)
+ used binary-indep instead of binary-arch target
  * debian/copyright
+ added copyright notice
  * Added compat, docs, watch files
  * switched to dpkg-source 3.0 (quilt) format

 -- Thierry Randrianiriana   Sun, 09 May 2010 09:00:55 +0300

php-elisp (1.4.0-3) unstable; urgency=low


Thanks!
Nicholas


signature.asc
Description: PGP signature

Re: Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

On Mon, Oct 22, 2018 at 08:50:56PM +0200, Andrej Shadura wrote:
> 
>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


signature.asc
Description: PGP signature

Re: Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Hi Francesco,

On Tue, Dec 12, 2017 at 11:37:46PM +0100, Francesco Poli wrote:
> On Tue, 12 Dec 2017 16:39:28 -0500 Nicholas D Steeves wrote:
> 
> [...]
> > 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...

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


signature.asc
Description: PGP signature

Re: Bug#883731: audacious: Debian packaging has incorrect license

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

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Does Debian itself have a license?

[Nicholas D Steeves]

On Mon, Sep 10, 2018 at 09:12:47AM +1000, Ben Finney wrote:
> Hong Xu  writes:
> 
> > For example, /usr/share/doc/bash/copyright reads "Copyright (C)
> > 1987-2014 Free Software Foundation, Inc." Although the author of the
> > packaging "Matthias Klose " is mentioned, there is no
> > license claimed for his packaging work.
> 
> I consider that to be a bug worthy of reporting. (The absence of
> explicit grant of license for the packaging work is a violation of
> Debian Policy §4.5.)
> 
> It will be a bug that many packages in Debian have, so you might want to
> co-ordinate a response. After discussion you might find the response
> is “this isn't urgent because it has been this way for decades”. Or you
> might find a different consensus.
> 
> Be aware of the Debian Developer's Reference guidance on reporting a bug
> to many packages at once (in brief: don't until you discuss it with the
> package maintainers and achieve consensus)
> https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#submit-many-bugs>.
> 
> > As far as I know, there are a lot of cases where default configuration
> > files in Debian are handcrafted, either from scratch or modified from
> > those in the upstream package.
> 
> The copyright document for a package must (Debian Policy §4.5) contain
> comprehensive copyright information for all the package, whether
> originating from upstream or from Debian maintainers or anywhere else.
> 
> So I think that every part of Debian is required to have its copyright
> information declared explicitly in the ‘copyright’ document of one or
> more installed packages on the system.
> 
> If you know of an exception, let's discuss that; otherwise I think the
> response is to talk about specific packages that fail to meet that
> requirement.

Hi Ben,

I'm in the process of adopting php-elisp and have been delaying while
waiting for copyright confirmation emails from all contributors.
Given this:

  https://sources.debian.org/src/php-elisp/1.13.5-3/debian/copyright/

Per the URL above, is it a Policy v3.9.6 §4.5 violation?  Would it be
such a violation under Policy 4.2.0?  There are still a lot of
packages like this...

Are Ola and Pontus the only copyright holders for debian/*?  I've
followed the licensing confirmation procedure and am tracking the
replies here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903092

If Ola and Pontus are the only copyright holders then I can switch to
format 1.0 with explicit licensing of debian/* :-)

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Does Debian itself have a license?

[Nicholas D Steeves]

Hi Hong,

On Sun, Sep 09, 2018 at 12:32:28PM -0700, Hong Xu wrote:
> On 09/08/2018 09:51 PM, Ben Finney wrote:
> > Hong Xu  writes:
> > 
> >> I understand that each piece of software has its own license in Debian
> >> and they can be easily looked up. However, I have trouble finding the
> >> license of the Debian itself, e.g., metadata of packages, default
> >> configuration files created by the Debian project, etc. Can you
> >> provide any information on that? Thanks!
> > 
> > My understanding is that the entire operating system is delivered as
> > packages, and each package declares its copyright information in its
> > ‘/usr/share/doc/$PACKAGENAME/copyright’ document.

Let's use the octave example.  In /usr/share/doc/octave/copyright you'll
find the section "Files: debian/*".  This is the copyright for the
Debian portions of the source package.  Sometimes there were be
debian/patches/custom_debian_config.patch which modifies the upstream
source.  Such patches also fall under the copyright of
"Files:debian/*" unless otherwise specified. [1]

Unfortunately the it's not nearly as clear for package which don't use
copyright format 1.0...

> > The “metadata of packages” I am not sure what you mean? To my knowledge
> > all the metadata is part of the source form of the package, and so is
> > subject to the license conditions described for that package. Is there
> > something else you refer to as “metadata of packages”?
> 
> The metadata of packages include information package descriptions,
> dependencies, etc. that were created by Debian developers. It seems to
> me that the copyright file of package does not describe the license of
> this information since the copyright holder seems to be always the
> upstream copyright holders. For example, /usr/share/doc/bash/copyright
> reads "Copyright (C) 1987-2014 Free Software Foundation, Inc." Although
> the author of the packaging "Matthias Klose " is
> mentioned, there is no license claimed for his packaging work.

It sounds like you're saying "metadata of the [binary] packages".
They're not metadata for source packages, where they are actual files.
Eg: '$ apt source octave'.  In a non-native (the majority of packages)
Debian source package the Debian bits are also in a separate tarball
from the upstream one. eg:
  http://http.debian.net/debian/pool/main/o/octave/octave_4.0.3-3.debian.tar.xz
vs
  http://http.debian.net/debian/pool/main/o/octave/octave_4.0.3.orig.tar.xz

> 
> > The same would be true for any default configuration files. They will be
> > auto-generated (maybe even, simply copied) from some files installed
> > from a specific package, and so are subject to whatever general license
> > conditions apply for each package.
> 
> As far as I know, there are a lot of cases where default configuration
> files in Debian are handcrafted, either from scratch or modified from
> those in the upstream package. For example, the file octave.conf
> (installed to /etc/octave.conf) in the source package of octave seems to
> be manually modified from the upstream configuration file and its header
> reads:

octave-4.0.3/debian/octave.conf.  See [1].


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

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

On Mon, Dec 11, 2017 at 12:28:43AM -0500, John Lindgren wrote:
> On 12/10/2017 06:12 PM, Nicholas D Steeves wrote:
> > 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:
> 
> 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].

On Mon, Dec 11, 2017 at 03:03:09PM +, Ian Jackson wrote:
> Nicholas D Steeves writes ("Re: Bug#883731: audacious: Debian packaging has 
> incorrect license"):
> > 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:
> 
> 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

Re: Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

On Mon, Dec 11, 2017 at 12:23:47AM +0100, Francesco Poli wrote:
> On Sun, 10 Dec 2017 18:12:39 -0500 Nicholas D Steeves wrote:
> 
> [...]
> > 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.


signature.asc
Description: PGP signature

Re: Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

On Fri, Dec 08, 2017 at 10:36:49AM -0500, John Lindgren wrote:
> Nicholas D Steeves wrote:
> 
> > 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.
> 
> > 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.

This will be easier to do.

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

> Francesco Poli wrote:
> 
> > 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.

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

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

> Thank you both for the prompt reply and good discussion!

You're welcome!  Thank you for reaching out.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

Hi Francesco, John, and everybody else reading this,

On Fri, Dec 08, 2017 at 11:10:40AM +0100, Francesco Poli wrote:
> On Thu, 7 Dec 2017 22:39:41 -0500 Nicholas D Steeves wrote:
[...]
> 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...
> 
> > 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/>

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 <tymb...@gmail.com>, 2014
# Eugene Paskevich <eug...@raptor.kiev.ua>, 2015-2016
# Kostyantyn Fedenko <fede...@ukr.net>, 2011
# Oleg <kvantar...@gmail.com>, 2012
# NaiLi (aka jamesjames) Rootaerc <the...@mail.ru>, 2012
# NaiLi (aka jamesjames) Rootaerc <the...@mail.ru>, 2012
# Oleg <kvantar...@gmail.com>, 2012
# Rax Garfield <ad...@dvizho.ks.ua>, 2012
# Rax Garfield (http://biokillaz.com/), 2012
# Rax Garfield <ad...@dvizho.ks.ua>, 2012-2013
# Rustam Tsurik <rustam.tsu...@gmail.com>, 2013
# Rustam Tsurik <rustam.tsu...@gmail.com>, 2013
# Oleg <kvantar...@gmail.com>, 2012
# Taras Shevchenko, 2017
# Yaroslav Yenkala <hyper-n...@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+\n"
"Last-Translator: Taras Shevchenko\n"

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

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

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


signature.asc
Description: PGP signature

Re: Bug#883731: audacious: Debian packaging has incorrect license

[Nicholas D Steeves]

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,

On Thu, Dec 07, 2017 at 05:15:53PM -0500, John Lindgren wrote:
> 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*
> BSD 2-clause, with some exceptions:

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
(commit@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


signature.asc
Description: PGP signature

Re: File is BCP 78 or Simplified BSD? Lintian says BCP 78

[Nicholas D Steeves]

Hi Ian,

Thank you for the quick reply, and sorry for the delay.  I have a bit
of free time today, but after that I (again) won't have much time for
Debian work for the next two weeks.

On Mon, Aug 14, 2017 at 09:12:04PM +0100, Ian Jackson wrote:
> Nicholas D Steeves writes ("File is BCP 78 or Simplified BSD?  Lintian says 
> BCP 78"):
> > I am wondering if Lintian correctly detected a file's copyright as BCP
> > 78, or if it's a false alarm.  I want to believe that it's a false
> > alarm, but have submitted a patch to make the package dfsg-free in
> > case it is not a false positive (Bug #868258).
> 
> It's a false alarm.  I think the file is entirely "Code Components"
> which the text itself says is released under the "simplified BSD"
> licence, and it references sha.h, which is here
>   https://raw.githubusercontent.com/kdave/btrfs-progs/master/tests/sha.h
> 
> It would be best to tidy up by getting rid of the misleading BCP78
> boilerplate, which doesn't apply to the code, only to the rest of the
> document (none of which seems to be present in sha224-256.c at least).
> 
> > The file in question is btrfs-progs/tests/sha224-256.c
> > https://raw.githubusercontent.com/kdave/btrfs-progs/master/tests/sha224-256.c

That's a relief!  So this can be solved with (mandatory) additions to
debian/copyright and a patch to upstream.

> > I am writing to you because it seems like this might be a matter of
> > interpretation.  eg: that the official specification is BCP 78, but
> > that the code samples are Simplified BSD.  It might also be necessary
> > to consult two other files introduced in the same commit.  Here is
> > that commit:
> > 
> > https://github.com/kdave/btrfs-progs/commit/4ddd6055c333932b561046ad1d41234d773246d2
> 
> github says "3 changed files" and then lists changes to 2 files.  The
> changes to sha.h are fine.  What is the 3rd file ?

I'm not sure why github didn't show changes to the third file when you
checked.  When I check it on github, and when I look at
4ddd6055c333932b561046ad1d41234d773246d2 in gitk it shows changes to
tests/sha-private.h, tests/sha.h, and tests/sha224-256.c.

So far we have:

sha.h -> 2-clause (Simplified BSD)
sha224-256.c -> send patch to upstream to remove misleading BCP78
boilerplate
sha-private.h -> "See RFC 6234 for details"?  ...so 2-clause?

After consulting RFC 6234, it seems that maybe this header needs a
2-clause boilerplate, because
   Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

If this is the case then upstream will also need a patch for
sha-private.h, no?

Kind regards,
Nicholas


signature.asc
Description: PGP signature

File is BCP 78 or Simplified BSD? Lintian says BCP 78

[Nicholas D Steeves]

Dear Debian Legal Team,

I am wondering if Lintian correctly detected a file's copyright as BCP
78, or if it's a false alarm.  I want to believe that it's a false
alarm, but have submitted a patch to make the package dfsg-free in
case it is not a false positive (Bug #868258).

The file in question is btrfs-progs/tests/sha224-256.c
https://raw.githubusercontent.com/kdave/btrfs-progs/master/tests/sha224-256.c

I am writing to you because it seems like this might be a matter of
interpretation.  eg: that the official specification is BCP 78, but
that the code samples are Simplified BSD.  It might also be necessary
to consult two other files introduced in the same commit.  Here is
that commit:

https://github.com/kdave/btrfs-progs/commit/4ddd6055c333932b561046ad1d41234d773246d2

These hashing algorithms are used to tests/fssum.c, and fssum is used
in tests/misc-tests/019-receive-clones-on-munted-subvol/test.sh.  If
you're interested here is the upstream description of the test:
# Test that an incremental send operation works when in both snapshots there are
# two directory inodes that have the same number but different generations and
# have an entry with the same name that corresponds to different inodes in each
# snapshot

I believe this test was written to test for cases where incremental
send | receive operations could result in file system corruption.  Of
course, we could trust upstream to run these tests themselves, but my
understanding of the autopkgtest initiative was that this is exactly
the sort of tests we ought to be running.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Re: advice for free software package named almost identically to non-free software

[Nicholas D Steeves]

Hi Paul,

On Sun, Jun 11, 2017 at 10:19:16AM +0800, Paul Wise wrote:
> On Sun, Jun 11, 2017 at 7:42 AM, Nicholas D Steeves wrote:
> 
> > Do you think it's ok to internally provide backwards compatibility?
> > eg, for a library, newname provides/fulfils oldname, for a long period
> > of time...perhaps a year.  I'm trying to think of all the non-Debian
> > users who would also be affected by this change.
> 
> That would be a decision for upstream but I guess it would probably be OK.

I've given the upstream contact your email so he can write to you
directly.  Maybe I'm paranoid and overestimate the motivation and
skills of litigious goons!  Worst-case scenario being a google-tracked
mailing list boosts the page-ranking of the almost-identically-named
software and attracts the attention of those who would cause stress
for others.

Thank you for the advice,
Nicholas


signature.asc
Description: Digital signature

Re: advice for free software package named almost identically to non-free software

[Nicholas D Steeves]

Hi Ian,

On Mon, Jun 12, 2017 at 12:27:12PM +0100, Ian Jackson wrote:
> Nicholas D Steeves writes ("advice for free software package named almost 
> identically to non-free software"):
> > An upstream has named their GPL software almost identically to a
> > proprietary piece of software.  Both the free and the proprietary
> > software are developed in the U.S.A.  The upstream has confirmed that
> > the name is not a registered trademark in the U.S.A, but the
> > proprietary software unambiguously precedes the free version; thus, if
> > ever there is a dispute, the developer of the first version has the
> > "prior art" argument on their side.
> 
> Hi.
> 
> I can't help feeling that this story is missing something.  I don't
> disagree with anything Paul Wise has said, but:

I apologise for being so vague and cryptic...if this wasn't a
public and google-searcheable list I would have been much more
forthcoming.  I'm not the upstream, btw! ;-)
 
> > The developer of the free software implementation has asked me if it
> > would be sufficient to ask permission from the author of the
> > proprietary developer to name his software similarly.  If this is
> > acceptable, would you please provide a template I can send to the
> > author of the free implementation?
> 
> In most situations I can imagine, the proprietary software author
> would be very unlikely to give permission.  Indeed, I would expect
> them to object if they knew about it, so, contacting them to ask for
> it might well trigger the latent problem.
> 
> If the free upstream suggests that they might ask for permission,
> presumably they have a different understanding of the proprietary
> authors' views.  Perhaps they know (of) each other or have some other
> relationship that we're missing.

To the best of my knowledge they do not.  In summary, when it occurred
to me that the naming could be an issue I contacted upstream, he asked
what is usually done in cases like these, I said I'd ask debian-legal.
The optimist in me expressed the sentiment that maybe asking for
permission from the proprietary software author would be sufficient,
but I qualified this with something along the lines of "please don't
contact him until I receive a reply from debian-legal as to if this is
a wise course of action".

> So, as far as the question actually asked I think Paul is right.  But
> I have a strong feeling of "something odd going on here".  It may be
> that if we knew more of the background, we could give better advice.

I've given the upstream contact your email so he can write to you
directly.  Maybe I'm paranoid and overestimate the motivation and
skills of litigious goons!

Thank you


signature.asc
Description: Digital signature

Re: advice for free software package named almost identically to non-free software

[Nicholas D Steeves]

On Fri, Jun 09, 2017 at 09:52:35AM +0800, Paul Wise wrote:
> On Fri, Jun 9, 2017 at 6:29 AM, Nicholas D Steeves wrote:
> 
> > An upstream has named their GPL software almost identically to a
> > proprietary piece of software.
> 
> I think it would be best to pro-actively rename the software now
> rather than wait until renaming the software would be more painful.
> Even if the proprietary software developer gives their permission,
> they could always sell the software to someone else, who might not be
> as forgiving of the naming similarity.

That's a really good point, and something I hadn't considered!  I've
forwarded this to our upstream contact.

Thank you,
Nicholas


signature.asc
Description: Digital signature

Re: advice for free software package named almost identically to non-free software

[Nicholas D Steeves]

On Fri, Jun 09, 2017 at 09:52:35AM +0800, Paul Wise wrote:
> On Fri, Jun 9, 2017 at 6:29 AM, Nicholas D Steeves wrote:
> 
> > An upstream has named their GPL software almost identically to a
> > proprietary piece of software.
> 
> I think it would be best to pro-actively rename the software now
> rather than wait until renaming the software would be more painful.
> Even if the proprietary software developer gives their permission,
> they could always sell the software to someone else, who might not be
> as forgiving of the naming similarity.

Do you think it's ok to internally provide backwards compatibility?
eg, for a library, newname provides/fulfils oldname, for a long period
of time...perhaps a year.  I'm trying to think of all the non-Debian
users who would also be affected by this change.

Thank you for help and the feedback!
Nicholas


signature.asc
Description: Digital signature

Re: unknown license for package/debian/* in d/copyright in adopted package

[Nicholas D Steeves]

Dear Debian Legal Team,

Thank you very much for your help.  I've read each email in this
thread with care, and at last can consider this issue closed.

On 9 June 2017 at 02:27, Anthony DeRobertis <anth...@derobert.net> wrote:
> On 06/08/2017 06:52 PM, Nicholas D Steeves wrote:
>>
>>
>> I'd prefer not to, because Message-ID reveals what I consider private
>> information (IP address or client hostname) to an unbounded audience,
>> and I believe that this is a greater privacy violation than the
>> lintian warning against downloading a hyperlinked image in local [...]
>
>
> That depends on the software that generated the message (e.g., Thunderbird
> seems to do uuid@domain, so avoids the privacy issue—at least it reveals
> less than the From header), but where it does you could just redact the
> hostname (or entire domain). That'd still preserve the ability to reference
> an individual message.
>
> Message-Id: <localpart@...> and
> Message-Id: <localpart@REDACTED>
>
> are both pretty clear what you're doing.
>

Anthony, thank you for this solution! :-)  I didn't know that this was allowed.
Ben, now there's a Message-ID field.  I'll upload to experimental as
soon as Sean Whitton grants me DM permissions for src:muse-el.

Sincerely,
Nicholas

Re: unknown license for package/debian/* in d/copyright in adopted package

[Nicholas D Steeves]

Hi Ben,

On Wed, Jun 07, 2017 at 10:24:11AM +1000, Ben Finney wrote:
> Nicholas D Steeves <nstee...@gmail.com> writes:
> 
> > I pushed updates here:
> >
> > https://anonscm.debian.org/git/pkg-emacsen/pkg/muse-el.git/tree/debian/COPYING.emails
> 
> That's a good record. Better than most Debian packages, I'd say :-)

Thank you! :-D

> Can you put the Message-ID field for each message in the header for the
> message? That will make it easier to refer to specific messages later.

I'd prefer not to, because Message-ID reveals what I consider private
information (IP address or client hostname) to an unbounded audience,
and I believe that this is a greater privacy violation than the
lintian warning against downloading a hyperlinked image in local
documentation.  The later only reveals private information to a single
person.  Yes, it can be argued that Debian Developers wave their
privacy by participating in publicly archived forums, like this one;
however, because the contributors chose to privately email me rather
than reply to this this thread, I have chosen to maximally respect
their privacy.

> As it is, I can say I think you need only these ones:
> 
> * Date: Thu, 1 Jun 2017 10:15:58 +1000
>   From: Trent Buck <trentb...@gmail.com>
> 
> * Date: Wed, 31 May 2017 20:24:01 -0700
>   From: Michael Olson <mwol...@gnu.org>
> 
> * Date: Thu, 01 Jun 2017 09:57:49 +0200
>   From: Julien Danjou <a...@debian.org>
> 
> > How important is this updated copyright?
> 
> It's important to include explicit grant of specific license in writing
> from all copyright holders.

I included Mehdi's statement because I believe it is to the affect of
"I am pretty sure that I am not a copyright holder".  That said, is
this record sufficiently complete without digging through bts archives
to find out how to contact anyone who was involved in the NMU he
did...and then contacting them?

> > Do I need to worry about getting it into Stretch?
> 
> I think it can wait until after the release, though I don't speak for
> the release team or FTP masters.

I contacted them but don't expect to receive a reply, knowing how busy
they must be ;-)

Thank you for the help,
Nicholas


signature.asc
Description: Digital signature

advice for free software package named almost identically to non-free software

[Nicholas D Steeves]

Dear Debian Legal,

An upstream has named their GPL software almost identically to a
proprietary piece of software.  Both the free and the proprietary
software are developed in the U.S.A.  The upstream has confirmed that
the name is not a registered trademark in the U.S.A, but the
proprietary software unambiguously precedes the free version; thus, if
ever there is a dispute, the developer of the first version has the
"prior art" argument on their side.

The developer of the free software implementation has asked me if it
would be sufficient to ask permission from the author of the
proprietary developer to name his software similarly.  If this is
acceptable, would you please provide a template I can send to the
author of the free implementation?

The degree of similarity as close as "Quake" and "Quake-world".

Sincerely,
Nicholas


signature.asc
Description: Digital signature

Re: unknown license for package/debian/* in d/copyright in adopted package

[Nicholas D Steeves]

On Wed, May 31, 2017 at 02:54:57PM +1000, Ben Finney wrote:
> Ian Jackson  writes:
> 
> > Do you agree that my mail exchange as found in the sympathy package is
> > a good example of how to ask these questions, and how to record the
> > answers ?
> 
> Ian Jackson  writes:
> 
> > I meant this, which I provided a link to earlier:
> >   https://browse.dgit.debian.org/sympathy.git/tree/COPYING.emails
> 
> Yes, that's a good record of the conversation.
> 
> It'd be better IMO if it included each message's Message-ID field, or
> some other URI for each message so that the parties in the conversation
> can later verify that it matches their own record of the discussion.
> 
> Are there messages in that file that could be removed? I typically try
> to get a single message from the copyright holder, that contains an
> explicit and unambiguous grant of a specific license.
> 
> Often that isn't forthcoming as clearly as we might like, because of how
> the correspondence unfolds. I appreciate that you pressed for that in
> the discussion for ‘sympathy’. Maybe that's just an example of a case
> where no one message will clearly show the grant of license, and the
> whole set needs to be examined.

Dear Ian and Ben,

Thank you for resuming this conversation!  I had forgotten to finish
work on this issue and it exactly the reminder I needed.

I pushed updates here:

https://anonscm.debian.org/git/pkg-emacsen/pkg/muse-el.git/tree/debian/COPYING.emails
https://anonscm.debian.org/cgit/pkg-emacsen/pkg/muse-el.git/

How important is this updated copyright?  Do I need to worry about
getting it into Stretch?  When Feb 5th blew by I thought "minor, not
very popular package that isn't worse than it was before" so didn't
worry about it and I thought the issue wasn't worth hassling someone
for an unblock.

Sincerely,
Nicholas


signature.asc
Description: Digital signature

unknown license for package/debian/* in d/copyright in adopted package

[Nicholas D Steeves]

Dear Debian Legal Team,

I'm adopting src:muse-el, and the old d/copyright file does not state
which license the old debian/* uses.  I used "comm" to see what
remained after transitioning the package to use dh-elpa, current
debhelper and compat, et al, and only the contributions of Michael
Olson and myself remain in debian/*.  Sean Whitton is working with me
to make sure the updated package is very high quality.  He made me
aware of the issue updating to copyright-format 1.0 when the original
debian/* license was undefined.

src:muse-el is GPL-3+, with some MIT contributions.  debian/* must
have been DFSG-free, and were probably GPL-2, GPL-2+, or possibly MIT.
I was recently able to contact Michael Olson.  Would a signed email
from Michael Olson certifying that his contributions to debian/* were
of either GPL-2, GPL-2+, or MIT be sufficient to allow an update to
src:muse-el/debian/copyright?  If so, to whom should I ask him to send
that email?

The bug associated with this ITA is #844184.  By now it's kind of a
long read ;-)

Sincerely,
Nicholas


signature.asc
Description: Digital signature