Re: Questions about libntru license/ntru patent status
William Whyte writes ("Re: Questions about libntru license/ntru patent status"):
> Sorry for having let this drift for so long. Way back at the start
> of the discussion, as we got into the discussion of the FOSS
> Exception, there seems to have been an assumption that Tor would
> depend on that FOSS Exception to use NTRU. In fact, our plan was to
> make a Tor-specific carveout along the lines of:
Thanks for your reply.
> "The NTRU source code and patents can be freely used and distributed
> when used as part of the quantum-safe-ntor protocol as specified in [doc
> ref] and its successor documents designated as such by the Tor Project."
I'm sorry to say that I don't think Debian would want to rely on such
a permission.
The reason is that it depends on the code actually implementing the
specified protocol. But, we want our downstreams and users to be able
to modify the software - including, to make it speak a different
protocol.
Debian is looking for a licence that would work for Debian and all our
derivative distributions, downstreams, and users, which would allow
all of us to use and modify the software.
On the other hand Debian does not need a licence that works if some
other library, besides the NTRU library, is used to implement the
algorithms.
So I think the approach of a licence attached to the source code is
much more likely to be helpful. If I remember the previous
discussion, that licence was very close to suitable, with some
problems in the wording of the `FOSS exception' (ie, the exception to
permit use with non-GPL licences).
As you quote in your email I suggested a wording based on a GPL
Additional Permission. I think that is what your `FOSS exception' was
trying to do. There are many ways of doing something like that. I
hope you will adopt something suitable - since I think our goals are
fairly well aligned.
Thanks,
Ian.
Re: "Use as you wish" license
Roberto writes ("Re: "Use as you wish" license"):
> The first one ("use as you wish") is already on Debian. To be honest I
> must say that I knew that, but I asked anyways to get independent
> answers not influenced by the fact that it has been included before.
I'm afraid that's not really a good way of answering these questions.
You weren't really to know, but:
This mailing list is purely advisory (if that, even), and has no
formal decisionmaking status. The actual decisions are made and
implemented by the ftpmasters.
If the ftpmasters have accepted this kind of permission statement
before, so many times, then I think we can draw the conclusion that
they are happy with it.
Thanks,
Ian.
Re: "Use as you wish" license
Roberto writes (""Use as you wish" license"):
> I've encountered two simple notices, I wonder if they are acceptable for
> DFSG under your opinion.
>
> Is "Use as you wish" an acceptable license?
I would argue that modifying and redistributing are uses, and
therefore included in `use'. To me that's clearly what the author
intends.
As a practical matter, a copyrightholder who writes such a notice is
unlikely to sue, and if the copyright passes on, their less
sympathetic successors are very likely estopped from going back on it.
So I think this is fine.
> And, a web page that says some of its content "may be downloaded and
> used for any projects, without restrictions".
It is to me less clear that this allows modification, because
`downloaded and used' seems to necessarily mean that `used' doesn't
include `downloaded'. I would ask the author/copyrightholder for
clarification and/or suggest a revised wording.
Ian.
Re: New upstream changing license, typo and SPDX-License-Identifier
Jens Reyer writes ("New upstream changing license, typo and
SPDX-License-Identifier"):
> 1. LGPL-2+ --> LGPL-2.1+
>
>
> One has a notice for the "GNU Lesser General Public License" v2 (or
> later).[2] However in v2 the LGPL was the "GNU *Library* General Public
> License, while it only became the "GNU *Lesser* General Public License"
> in v2.1. The project ships a COPYING file[3] (since nearly the
> beginning of the projects history), identical to
> https://www.gnu.org/licenses/lgpl-2.1.txt
There is no problem with the licence name change. LGPL 2.1 ("Lesser")
has a rubric which clearly identifies it as a successor to LGPL 2
("Library").
> It's clear that the project aims for license compatibility with Wine
> (LGPL-2.1+), but I assume this is not relevant for my first question:
>
> Is it ok to simply change the license notice to 2.1+?
Yes. (Subject to the difficulty discussed below.)
> But then again the LGPL 2.1 states that we have to "[...] publish on
> each copy an appropriate copyright notice and disclaimer of warranty;
> keep intact all the notices that refer to this License and to the
> absence of any warranty[...]".
There is no problem with this. Licence version upgrade is routine, if
"or later" has been used.
> 2. SPDX-License-Identifier
> ==
>
> Currently some files (small helper scripts, luckily only by authors we
> can ask for permission) have a custom license notifier for LGPL-2.1 only
> (but not later).[4] I'd like to change this (with the authors'
> permission). To respect the wish for a short license notice in these
> files, I've suggested to use the SPDX-License-Identifier instead:
>
> -# This software comes with ABSOLUTELY NO WARRANTY.
> -#
> -# This is free software, placed under the terms of the GNU
> -# Lesser Public License version 2.1, as published by the Free
> -# Software Foundation. Please see the file COPYING for details.
> +# SPDX-License-Identifier: LGPL-2.1+
This is not human-readable. I would avoid it, personally.
By "not human-readable" I don't mean that it's not clear what licence
this refers to. What it lacks is a clear declaration that the file is
released under the named licence.
I would suggest simply adding the missing words:
... Lesser Public License version 2.1 {+ or later +}, as ...
The intent is then clear, even if a bit abbreviated.
In the discussion of the pull request, Austin says "However
src/winetricks has had many more authors than just
myself/Dan/Joseph". This is true, but it is only these three files
Makefile
src/linkcheck.sh
src/release.sh
which seem to have the problematic statement, AFAICT. That's the
output of
git-grep -l 'Lesser Public License' | xargs git-grep -L 'or later'
So we need only ask the contributors to those files, who are
AsciiWolf
Austin English
daniel.r.kegel[@gmail.com]
I think AsciiWolf must be Joseph ? But anyway that committer
committed only 4 lines to Makefile in one commit, which is a minimal
contribution which probably doesn't attract the copyright monopoly.
I see Austin is happy. So I think you just need agreement from
Daniel.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Debain licensing
Rahul Mohan G writes ("Debain licensing"):
> Can you please let me know whether this license information is of
> the original package? If so, what could be the license information
> of the debian package?
This licence information is of the Debian version of the package. The
licence information covers both the licence of the origin package, and
of the Debian modifications (and the Debian packaging additions).
Ian.
Re: Inclusion of PDF with CC Attr 3.0 license
Francesco Poli writes ("Re: Inclusion of PDF with CC Attr 3.0 license"):
> On Thu, 01 Sep 2016 16:38:06 -0700 (PDT) Walter Landry wrote:
> > It is not like it is hard to add the attribution
> > required by the license.
>
> Well, in my own personal opinion, CC-by-v3.0 requirements on
> attribution are not so easy and practical to comply with [1].
> This is one of the reasons why I believe that this license fails to
> meet the DFSG.
You have forgotten to add the usual rider, that you should add when
you are putting forward an opinion which is contrary to Debian's
established policy.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: declaring a license
Herbert Fortes writes ("declaring a license"):
> I am doing a QA for python-irc[0] and the tarball
> does not have a COPYING/License file. The statement
> is done in setpu.py file and PyPi[1] only.
>
> [0] - https://packages.qa.debian.org/p/python-irc.html
> [1] - https://pypi.python.org/pypi/irc/
>
> I talked[2] with the upstream by github 'Issues'
> about that (no COPYING/License file ) and a version
> (12.1) which had a License file declaring one
> license (LGPL) and a setpu.py file declaring the
> actual license (MIT) in the same tarball.
>
> [2] - https://github.com/jaraco/irc/issues/106
>
> Now I have an email that explicit declares one
> License to all project I can put the file in debian/.
> In the tarball you only see that in setup.py file.
>
> Is that enough ?
I think it is. I would:
* Use curl to download copies of the two github issues #99 and #106,
and put copies of the resulting html in the source package,
in debian/ somewhere.
* Write a debian/copyright file stating that the whole package is
MIT, and containing a copy of the MIT licence. I would copy
the text from https://opensource.org/licenses/MIT.
Good luck.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Inclusion of PDF with CC Attr 3.0 license
Rafael Laboissière writes ("Inclusion of PDF with CC Attr 3.0 license"):
> [Please, Cc to me, since I am not subscribed to debian-legal.]
>
> I am considering to package Divand [1], an add-on package for Octave. The
> current upstream tarball [2] contains a PDF file [3] with the following
> copyright and licensing conditions: "© Author(s) 2014. CC Attribution 3.0
> License."
>
> Would it be okay to include this file in the Debian package?
AFAICT this PDF is a scientific paper. The source code (typesetter
input file or whatever) is not provided, and while modifying it would
be permitted by the CC-BY copyright licence, it would be awkward using
just the PDF.
My personal view is that there would be no problem shipping the PDF,
even though Debian's users would have no practical ability to modify
this PDF. Making a modified version of a scientific paper like this
one is neither useful, nor, unless especial care is taken, ethical.
Our users would be better served by getting a copy of the paper than
by having you remove it.
But Debian has taken the view that even documents like this one must
be fully free, and even removed from the source package. So you will
need to strip it out of the source package and make a "dfsg" orig
tarball.
Sorry. I think this is daft. Debian does at least permit you to
include a link to somewhere else the paper may be found.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: [Individual|Corporate] Contributor License Agreement
Frederic Bonnard writes ("Re: [Individual|Corporate] Contributor License
Agreement"):
> Though, as Ian mentionned, and as I intuitively felt, I still think
> there are unpleasant conditions in this agreement, in respect to the
> social contract will of giving back to the community, amongst
> others. It's a real stymie.
It is annoying. How annoying it is in practice will depend on all
sorts of things.
> My best option is, indeed, to ask to remove those agreements from the source.
Good luck. Also, best wishes if you decide to go ahead with packaging
this program for Debian even in spilte of the CLA.
Regards,
Ian.
Re: [Individual|Corporate] Contributor License Agreement
Ben Finney writes ("Re: [Individual|Corporate] Contributor License Agreement"):
> Frederic Bonnard <fre...@linux.vnet.ibm.com> writes:
> > My best option is, indeed, to ask to remove those agreements from the
> > source.
>
> It can often be effective to offer an alternative.
>
> You may want to offer the idea that, instead of asking for an additional
> CLA, they could simply ask for the contributor to certify the origin of
> the contribution <URL:http://developercertificate.org/>.
This is a good suggestion.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Freeware Public License (FPL)
Jörg Frings-Fürst writes ("Freeware Public License (FPL)"):
> a short question: is this license DFSG compatible?
Sadly there isn't permission to modify. I think this is probably
unintentional.
I'm afraid you'll have to go back to the authors/copyrightholders and
get them to fix the licence for this particular program.
This bad licence seems to be spreading like some kind of virus.
Searching for its name found some github repositories using it and
also this bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730758
That includes a statement by the licence author that they didn't mean
to forbid modification. Unfortunately that's not good enough when
other people have adopted the bad licence text.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Is the RAR archiver freely distributable?
Dmitry Alexandrov writes ("Re: Is the RAR archiver freely distributable?"):
> [Ian:]
> > We (Debian) cannot possibly agree to such a condition. It may well be
> > violated in Debian (even in main) already.
>
> I believe, that clause only implies ‘cracks’ or key generators for RAR.
Is it really your position that this is acceptable ?
If so I will consider whether to write a cracker or key generator for
RAR and upload it to unstable !
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: flask-sphinx-themes
Tobias Frost writes ("Re: flask-sphinx-themes"):
> Am Montag, den 24.10.2016, 06:07 +0200 schrieb Daniel Stender:
> > I was packaging privacyIDEA and came across this license text [1]:
> >
> >
> > We kindly ask you to only use these themes in an unmodified manner
> > just for Flask and Flask-related products, not for unrelated
> > projects. If you like the visual style and want to use it for
> > your own projects, please consider making some larger changes to
> > the themes (such as changing font faces, sizes, colors or
> > margins).
> >
...
> IMHO as they "ask": it is a wish and no obligation.
> I think this is OK in respect of the DFSG.
I agree.
Thanks,
Ian.
PS, Tobias, your email had wrap damage by the time it got to me. I
had to reformat it.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: is igmpproxy dfsg compliant?
Pali Rohár writes ("Re: is igmpproxy dfsg compliant?"):
> Looks like that same question was already asked in 2009, but it is without
> answer. Can you look at it?
.
> On Sunday 20 Jun 2009 20:54:12 Santiago Garcia Mantinan <ma...@debian.org>
> wrote:
> > I was thinking in packaging igmpproxy, but I'm afraid it is not clear
> > weather it is dfsg compliant or not. I'd like to know your opinion.
> >
> > igmpproxy can be found at http://sourceforge.net/projects/igmpproxy
> > and is supposed to be under GPLv2, but its codebase is smcroute 0.92 which
> > is also under GPLv2 and the problematic mrouted 3.9-beta3 which was under
> > the Stanford license, which I believe is considered not dfsg compliant, at
> > least we used to have that very same version of mrouted on nonfree.
> >
> > According to that, igmpproxy is not dfsg compliant, but Stanford guys have
> > relicensed their code, like it was said on http://bugs.debian.org/227146
> > a more complete explanation on the mrouted relicensing can be seen here:
> > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/mrouted/LICENSE
> >
> > So... can we consider igmpproxy as dfsg compliant or not?
> >
> > Thanks in advance!
> >
> > Regards...
>
> Because igmpproxy is based on mrouted originally licensed under Stanford
> and later relicensed under BSD, I would consider it DFSG compliant...
I think the situation is fine now. I suggest you include a
screenscrape of the openbsd web page, in the source package (to answer
future quetions, if any), if there are no better sourdes for the
relicence.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: is igmpproxy dfsg compliant?
Pali Rohár writes ("Re: is igmpproxy dfsg compliant?"):
> Can you review proposed package?
Willdo.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: drbdmanage EULA conforming to DFSG?
Markus Frosch writes ("drbdmanage EULA conforming to DFSG?"):
> I, myself, would consider the license non-free in terms of DFSG, due to this
> paragraph:
>
> > 3.4) Without prior written consent of LICENSOR or an authorized partner,
> > LICENSEE is not allowed to:
> > [...]
> > b) provide commercial turn-key solutions based on the LICENSED
> >SOFTWARE or commercial services for the LICENSED SOFTWARE or
> >its modifications to any third party (e.g. software support or
> >trainings).
>
> What's your opinion about that clause?
Wow. That's horrible. This is definitely unacceptable for Debian.
(I haven't read the rest of the licence. It's been suggested on
debian-legal that this is far from the only serious problem.)
> > Is DRBD Manage open source software?
> >
> > Yes, the license meets OSI?^@^Ys Open Source Definition, it
> > conforms to Debian?^@^Ys social contract, it conforms to
> > Ubuntu?^@^Ys licensing policy and it is within Launchpad?^@^Ys
> > licensing conditions.
This is clearly false as regards acceptability to Debian.
I doubt very much that they have talked to OSI or to Ubuntu.
I have CC'd one of the OSI lists. I couldn't find an appropriate list
for Ubuntu. Maybe someone else here knows how to bring this to the
appropriate Ubuntu people's attention ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: is igmpproxy dfsg compliant?
Pali Rohár writes ("Re: is igmpproxy dfsg compliant?"):
> Ok, package is already in new queue:
> https://ftp-master.debian.org/new/igmpproxy_0.1-1.html
Hrm. I didn't spot that. Well, anyway, thanks for your hard work.
As regards the package I didn't find anything terrible (although I
didn't quite finish everything I wanted to check - in particular I
haven't looked at the github project), but I did find twho things
that's are a slight problem:
AFAICT you think the overall resulting licence is GPLv2+ (that's
certainly what Johnny Egeland has written, and that's what you've
written in debian/copyright. But there are mentions of contributions
from Carsten Schill under GPLv2-only. Has anyone contacted Carsten
about this ?
And, there are a couple of files (`install-sh' and `missing') under
the MIT X Licence, which is not mentioned in debian/copyright. That is
a GPL-compatible licence so it's not a big problem, but the licence
should be mentioned in debian/copyright.
I also had some comments about the way the information was structured.
I don't think it is necessary (or indeed a good idea) to ship all of
the copyrightholders permission emails in debian/copyright.
The copyright file should IMO contain information about the actual
licence, and not contain out of date pieces of licence, or historical
information. It also does not need to contain records of all the
email communications with the licence holders.
IMO these should be kept in the source package, in case they are
needed, but they do not need to be in the .deb. The copyright file
should instead summarise the situation.
So I would suggest you put them in debian/ somewhere. COPYING.emails
or something maybe. The filename doesn't matter very much.
Conversely the source package should contain all the tracing
information we have about who approved what licence when. That
includes the emails I mention above, but also licence statements from
Stanford and OpenBSD etc.
As regards the Stanford relicensing: you have included two URLs. But
I think we should have the actual text of the relicense.
The best way to do this would probably be to use wget or curl to
download the HTML from the OpenBSD cvsweb page (which includes Theo de
Raadt's commit message), and maybe also save a copy of the diff which
comes out from this URL:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/mrouted/LICENSE.diff?r1=text=1.1=text=1.2
I looked at the troglobit.com url you mention and I don't think the
text there really provides anything more interesting or useful,
although it might be worth mentioning somewhere in the source package
that that's the upstream.
And there is some out-of-date information in the source package that
could usefully be qualified:
The file Stanford.txt in the toplevel is no longer applicable.
Ideally it would be deleted, but our source formats do not support
thta. You should prefix it with a notice saying it does not apply,
and referring to a copy of the Stanford notice.
Was the file AUTHORS from mrouted ? I can't tell from the Debian
source package you have provided. I think you may want to patch it to
prefix a statement about its scope.
In projects now maintained primarily in a VCS and accepting
contributions, such AUTHORS files typically become very out of date.
Many of my comments would be worth feeding upstream. Upstream
probably don't want to be distributing this out of date information,
and I'm sure they would like to have a record of the relicensing
approval emails.
Finally, the package's debian/control Homepage field refers to
sourceforge but actually it's now on github AFAICT.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: drbdmanage EULA conforming to DFSG?
(Resending a similar mail to d-legal because my previous attempt was
rejected by the OSI listserver.)
Markus Frosch writes ("drbdmanage EULA conforming to DFSG?"):
> I, myself, would consider the license non-free in terms of DFSG, due to this
> paragraph:
>
> > 3.4) Without prior written consent of LICENSOR or an authorized partner,
> > LICENSEE is not allowed to:
> > [...]
> > b) provide commercial turn-key solutions based on the LICENSED
> >SOFTWARE or commercial services for the LICENSED SOFTWARE or
> >its modifications to any third party (e.g. software support or
> >trainings).
>
> What's your opinion about that clause?
Wow. That's horrible. This is definitely unacceptable for Debian.
(I haven't read the rest of the licence. It's been suggested on
debian-legal that this is far from the only serious problem.)
> > Is DRBD Manage open source software?
> >
> > Yes, the license meets OSI?^@^Ys Open Source Definition, it
> > conforms to Debian?^@^Ys social contract, it conforms to
> > Ubuntu?^@^Ys licensing policy and it is within Launchpad?^@^Ys
> > licensing conditions.
This is clearly false as regards acceptability to Debian.
I doubt very much that they have talked to OSI or to Ubuntu.
I have CC'd one of the OSI lists and legal@canonical.
As the three institutions whose names are being taken in vain, I think
it would be good for us to have a coordinated response.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: is igmpproxy dfsg compliant?
Pali Rohár writes ("Re: is igmpproxy dfsg compliant?"):
> On Sunday 11 December 2016 13:13:08 Ian Jackson wrote:
> > Historical information can be retained in the git history, and in a
> > document which explains the authorship and licensing history of
> > igmpproxy.
>
> Yes, but now, for version in upstream git they are not historical yet.
Right.
I worry that new patches keep coming in and you're running to stand
still.
If this is a problem you can mark those licences as applying to
previous contributions, but clearly state that new contributions will
be treated as dual licenced: GPLv2+ and the applicable old licence(s).
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: is igmpproxy dfsg compliant?
Pali Rohár writes ("Re: is igmpproxy dfsg compliant?"):
> On Thursday 24 November 2016 19:29:21 Roberto wrote:
> > On Thu, Nov 24, 2016 at 06:36:53PM +0100, Pali Rohár wrote:
> > > And can be included igmpproxy package into Debian?
> >
> > Probably asking the authors if they can please switch the license, it
> > will benefit not only Debian but anyone who downloads from upstream
> > source as well.
>
> So... it is enough if all authors and contributors of igmpproxy agree
> that their changes can be redistributed under GPLv2+?
Yes.
> Or do they need to "relicense" their changes also under new BSD Stanford
> too?
No.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: unknown license for package/debian/* in d/copyright in adopted package
Ben Finney writes ("Re: unknown license for package/debian/* in d/copyright in
adopted package"):
> As to how to record the information, I would expect to find it in the
> ‘debian/copyright’ file, and I don't see what you're referring to at
> <URL:https://sources.debian.net/src/sympathy/1.2.1%2Bwoking%2Bcvs%2Bgit20161222/debian/copyright/>.
>
> So, if you can point to what you mean, I may be able to better respond :-)
I meant this, which I provided a link to earlier:
https://browse.dgit.debian.org/sympathy.git/tree/COPYING.emails
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: unknown license for package/debian/* in d/copyright in adopted package
Ben Finney writes ("Re: unknown license for package/debian/* in d/copyright in
adopted package"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > I would encourage everyone who does packaging to explictly licence
> > your debian/* with some very permissive licence (eg, MIT).
>
> I default to grating “GPLv3 or later” for mine; often I'll change
> that to match the upstream work's license grant.
>
> I don't see any special reason to prefer lax license grants for Debian
> packaging, so I default to copyleft.
It is often useful to copy Debian packaging snippets from one package
to another. That requires that the packaging of the first package
have a licence which is compatible with the upstream licence of the
second. In practice that means a permissive licence.
This benefit IMO far outweighs the risk that at some point someone
will abuse our goodwill to make Debian-format source packages out of
proprietary software. No-one, not even evil people, would want to do
that. In practice no-one except Debian and its free software
derivatives makes Debian-format source packages; everyone else has an
ad-hoc build script that spits out some .debs.
> The principle is to consider what a hypothetical future package
> maintainer, or FTP master or recipient, will need to have to verify the
> copyright holder does in fact grant the stated license.
>
> I agree that having the message be cryptographically signed is not
> necessary, but it is good to have if feasible.
>
> The important thing is that the grant be explicit, specific as to which
> work and which license terms, and that it all be clearly in writing.
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.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: unknown license for package/debian/* in d/copyright in adopted package
Nicholas D Steeves writes ("unknown license for package/debian/* in d/copyright
in adopted package"):
> I'm adopting src:muse-el, and the old d/copyright file does not state
> which license the old debian/* uses.
This kind of thing is quite annoying. I would encourage everyone who
does packaging to explictly licence your debian/* with some very
permissive licence (eg, 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 mail does not have to be signed. (It seems you're confident you
have the right email correspondent.) Although there is no harm in it
being signed, asking for a signature might make it more inconvenient
for Michael, or cause delay.
You can ask Michael to send the mail to you. He could also post it
here, if he feels like it. If he sends the mail to you privately, do
not publish his new email address without his permission. Put a copy
of the email, with the headers heavily redacted, in the package.
As an example of how to do this for some upstream contributions, I
offer this:
https://browse.dgit.debian.org/sympathy.git/tree/COPYING.emails
> The bug associated with this ITA is #844184. By now it's kind of a
> long read ;-)
I haven't read it :-).
Good luck.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Fixing dvi2dvi
(CCing the bug, #841056)
Christoph Biedl writes ("Fixing dvi2dvi"):
> I'd like to fix dvi2dvi which (besides a no-brainer) has a problem
> | #841056 dvi2dvi: license requires package rename
>
> >3. The package name of the modified software must not be ``dvi2dvi'' or
> >``dvi2dvi-'' where is the version number.
>
> Now I could take some advice what in Debian would be considered
> compliant to that clause.
>
> Was it sufficient to rename the binary package only, or should the
> source package be renamed as well?
I think `package' probably means source package too, although you
don't quote the licence. For the benefit of others:
http://metadata.ftp-master.debian.org/changelogs/main/d/dvi2dvi/unstable_copyright
Is upstream contactable ? Maybe they could be persuaded to drop the
restriction. Does anyone know if they have been asked ?
> Also, it would help the users if a transitional package "dvi2dvi" was
> shipped as well. Technically this should be acceptable since the
> transitional package was not provided by upstream, so the clause does
> not apply. But I'd like to hear a second opinion on that.
I think we should do that, yes, and I think that is fine.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: freeness and compatibility of CeCILL-C licence
Drew Parsons writes ("Re: freeness and compatibility of CeCILL-C licence"):
> If I'm reading that right, we can link it from BSD and LGPL libraries.
> Currently MUMPS is in Debian used by
...
> code-aster GPL2
This is a problem then.
Is there any possibility of CeCILL being persuaded to add a GPL
compatibility exception ? The licence already has an upgrade clause
IIRC.
Ian.
Re: freeness and compatibility of CeCILL-C licence
Dmitry Alexandrov writes ("Re: freeness and compatibility of CeCILL-C licence"):
> [Ian:]
> > (IMO it would not be fine if it specified Russian or Chinese courts.)
>
> Interesting idea. Any substantiation for such a discrimination of origin?
Some courts are more trustworthy than others.
Ian.
Re: System libraries and the GPLv2
Carlos Alberto Lopez Perez writes ("Re: System libraries and the GPLv2"):
> However, I still don't understand why we don't just declare OpenSSL a
> system library; or at least define a clear policy for when a package is
> considered part of the base system (so the GPL system exception applies
> to it).
I think the GPL system library exception does not apply for the
benefit of anything on a DVD image. Since we want downstreams to be
able to make arbitrary DVD( image)s containing whatever bits (of main)
that they like, and distribute them, we cannot rely on the system
library exception for anything in Debian.
Ian.
Re: freeness and compatibility of CeCILL-C licence
Drew Parsons writes ("freeness and compatibility of CeCILL-C licence"):
> There are various discussions about the status of the CeCILL-C licence
> v1 (and other CeCILL licences) in the history of this mailing list.
> It's not listed at https://www.debian.org/legal/licenses/
> but when it last came up on this list, Thibaut Paumard suggested it's
> fine, LGPL compatible,
> https://lists.debian.org/debian-legal/2010/01/msg00064.html
> Is this still the consensus?
...
> CeCILL-C v1 itself is
> http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html
I think this is a DFSG-free GPL-incompatible copyleft licence.
Francesco Poli dislikes the choice of law and courts clause, but I
think it's fine. (IMO it would not be fine if it specified Russian or
Chinese courts.)
It's GPL-incompatible because it is not identical to the GPL and
requires derivatives to have the same licence.
The warranty disclaimer clauses are unusually worded but seem to
protect contributors (including third parties) well enough.
Ian.
Re: No-Copyright?
Ole Streicher writes ("No-Copyright?"):
> one (Java) source file of an ITP package (jcdf) has the following comments:
>
> * The code for the Huffman and Adaptive Huffman decompressing stream
> * implementations in this class is based on the C implementation in
> * "The Data Compression Book" (Mark Nelson, 1992), via the code
> * in cdfhuff.c from the CDF source distribution.
> *
> * On the topic of intellectual property, Mark Nelson
> * http://marknelson.us/code-use-policy;>says:
> *
> * It is my intention that anyone who buys the book or magazine be free
> * to use the source code in any form they please. I only request that
> * any use that involves public reproduction include proper attribution.
> * any use that involves public reproduction include proper attribution.
> * I assert that in no case will I initiate or cooperate with any attempt
> * to enforce the copyright on the source code, whether it belongs to me
> * or a publisher.
> *
> * And I even bought the book (MBT).
>
> https://anonscm.debian.org/cgit/debian-astro/packages/jcdf.git/tree/BitExpandInputStream.java
>
> What is this? No-enforce-copyright with an attribution requirement?
> Upstream itself uses LGPL-3.
That's a big ambiguous as to who owns the copyright. Often copyright
of books ends up owned by the publisher, and publishers are often
bad.
I found this:
https://fossies.org/linux/cdf/src/lib/cdfhuff.c
That has a longer version of the same statement. I think that, plus
the fact that no publisher has tried to enforce this, over a period of
decades, means that a publisher would find it quite difficult to do
so.
So it's fine. I would c the longer statement from that web page I
found.
Ian.
Re: OpenSSL license for new packages.
Paulo Ricardo Paz Vital writes ("OpenSSL license for new packages."):
> I'm intending to package the openssl-ibmca library for s390 arch into
> Debian and I have a question about the license.
Thanks for getting in touch.
> Since this is an engine for OpenSSL, we have choose the license as
> OpenSSL License, which is based on BSD license.
Is "we" the upstream developers for openssl-ibmca, here ?
If so then I have some observations you may find helpful.
Firstly, OpenSSL itself is undergoing a relicensing effort:
https://www.openssl.org/blog/blog/2017/03/22/license/
If you want to follow OpenSSL, I therefore strongly suggest you adopt
Apache 2.0, or at least dual licence with Apache 2.0 as an option.
Secondly, the OpenSSL licence is not generally very well-regarded for
a number of reasons. I won't go into that here, but the OpenSSL
project's decision seems very good to me.
> The point is, two of the
> OpenSSL License [2] statements say the follow:
>
> " * 3. All advertising materials mentioning features or use of this
> *software must display the following acknowledgment:
> *"This product includes software developed by the OpenSSL Project
> *for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
>
> " * 6. Redistributions of any form whatsoever must retain the following
> *acknowledgment:
> *"This product includes software developed by the OpenSSL Project
> *for use in the OpenSSL Toolkit (http://www.openssl.org/)"
>
> I'd like to know if this is an impediment to package and redistribute it
> as a Debian Package. I checked the openssl package, and the content and
> license is the same.
These statements are, of course, false, at least as far as
openssl-ibmca itself is concerned. It is very bad practice to require
licensees to make false statements in copyright notices !
It causes considerable trouble. In a similar situation involving PHP
addons, we (the Debian Project) ended up consulting lawyers to find
out whether this was a serious problem.
So please do go back to upstream and see if you can get them to drop
this (or follow OpenSSL's lead and use Apache 2.0).
However, in fact our lawyers advised us in the PHP case that there was
no significant actual legal risk in us distributing the PHP addons,
provided that we made the situation very clear (including to the
relevant PHP upstreams).
See
https://lists.debian.org/debian-legal/2016/02/msg00014.html
I think this advice is probably equally applicable here. So if
openssl-ibmca upstream do not want to change their licence, I think
you should do as our laywers recommended in the PHP case.
Ian.
Re: OpenSSL license for new packages.
Ben Finney writes ("Re: OpenSSL license for new packages."):
> Paulo Ricardo Paz Vital writes:
>
> > Since this is an engine for OpenSSL, we have choose the license as
> > OpenSSL License, which is based on BSD license.
>
> Two problems with that:
>
> * There are multiple licenses that meet the description “BSD
> license”. They are published by the BSD project(s) for their
> works. They all have different effects and need to be
> distinguished.
>
> So, when discussing a license text actually published by BSD, please
> state exactly which one is being talked about.
I looked at the git repository linked to, and a few guessing clicks
got me here
https://github.com/opencryptoki/openssl-ibmca/blob/master/src/e_ibmca.c
which is the full licence text.
See my other reply.
Ian.
Re: OpenSSL license for new packages.
Kristian Fiskerstrand writes ("Re: OpenSSL license for new packages."):
> On 07/28/2017 02:45 PM, Ian Jackson wrote:
> > I looked at the git repository linked to, and a few guessing clicks
> > got me here
> > https://github.com/opencryptoki/openssl-ibmca/blob/master/src/e_ibmca.c
> > which is the full licence text.
>
> That would make the other statements about containing OpenSSL code valid
> at least, but I found this section interesting:
> > * 5. Products derived from this software may not be called "OpenSSL"
> > *nor may "OpenSSL" appear in their names without prior written
> > *permission of the OpenSSL Project.
>
> Is it a consensus that "OpenSSL" should be interpreted in a case
> sensitive manner in this case (as a trademark), or would the name of the
> project itself constitute as problematic for the license ("openssl-ibmca")?
Law and courts and things are generally not case sensitive.
The name of the project would be problematic, except that: I read
"this software" here as referring to OpenSSL itself and openssl-ibmca
is not derived from openssl, so is not caught by this clause.
Furthermore, it is not likely that the openssl-ibmca upstream would
have any objection to the things that Debian or any of our downstreams
or users would want to do. So even if this clause migth be
interpreted by a court to mean "you can't call this thing
openssl-ibmca", we don't think that's the licence authors meant.
If it turns out that that is what they meant, we can rename our
packages. That is our standard approach to excessively strict
trademark boilerplate and I think it is equally applicable here.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: File is BCP 78 or Simplified BSD? Lintian says BCP 78
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
>
> 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 ?
Ian.
Re: Working with a non-public license
Justin Gerhardt writes ("Working with a non-public license"):
> I'm a first time package creator and I could use some advice in
> regards to a license. I'm looking to package some proprietary
> software for inclusion in the non-free repo. The software is a
> popular game that is distributed in two parts, a commercially sold
> game client and an openly distributed server. I'm looking only to
> distribute the server part.
This isn't an answer to your question:
Why do you think this is a socially useful thing to do ? Why should
Debian help this company in this way ? How does doing this help
Debian's users, or the cause of software freedom, or whatever ?
If you have good answers to these questions then maybe someone will
feel like it's worth helping out...
Ian.
Re: [licence] specific licenses for backdoor-factory software
p...@reseau-libre.net writes ("[licence] specific licenses for backdoor-factory
software"):
> I'm currently packaging "backdoor-factory" for the pkg-security team.
> The tool is already in kali.
> The upstream sources are hosted here:
> https://github.com/secretsquirrel/the-backdoor-factory
>
> The main tool is based on the following license file (LICENSE.txt) :
> ---8<---
> Copyright (c) 2013-2016, Joshua Pitts
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
This is a perfectly fine licence very like the 3-clause BSD.
However:
> The upstream sources also contain a subdir (not required for the tool
> but existing in the upstream git repository), containing the tool aPlib
> (a compression library).
> This tool is using the following license (looks like common license),
> file aPLib/readme.txt:
This is evidently a homegrown licence text written by someone without
the necessary legal knowledge.
Unfortunately:
> You may not edit or reverse engineer any of the files (except the
> header files and the decompression code, which you may edit as long
> as you do not remove the copyright notice).
This is clearly non-free. It forbids modification.
> - Is the main software legaly acceptable for Debian ?
The upstream part is fine. But:
> - Do i need to clean the upstream (deleting aPlib dir) making a dfsg
> package
Yes.
> or the upstream can be kept in the source package untouched if
> the aPlib is not installed in the bin packages ?
No. Debian's practice is to require the removal of non-free
components from source packages, even if they are supposedly not
touched by the build. This ensures that there is no accidental
dependency of the non-free parts.
Will the program build and work without aPlib ? Why would it ship
with its own compression library ?
In the medium to long term it might be worth asking upstream to either
drop their special compression library, or fix the licence (best done
by choosing an existing widely-used Free Software licence).
Regards,
Ian.
Re: zstd: PATENTS application to copyright
Jeff Epler writes ("Re: zstd: PATENTS application to copyright"):
> Apparently,
> https://github.com/facebook/zstd
> https://github.com/facebook/zstd/blob/dev/LICENSE
> https://github.com/facebook/zstd/blob/dev/PATENTS
>
> Contents of .../LICENSE of this date:
> BSD License
This is all fine.
The copyright licence is a standard 3-clause BSD, and totally
DFSG-free.
The patent licence is a very usual kind of permissive patent licence.
Some people on debian-legal object to the software patent retaliation
termination clause, but I think it is fine and many similar licences
can be found in main.
And anyway, in the absence of known problems, we do not normally
investigate patents in software we are considering accepting. Doing
such investigations is ill-advised:
https://www.debian.org/legal/patent.en.html
https://www.debian.org/reports/patent-faq.en.html
Ian.
Re: unknown license for package/debian/* in d/copyright in adopted package
Ben Finney writes ("Re: unknown license for package/debian/* in d/copyright in
adopted package"):
> 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.
I think it is better not to bother upstream with pointless
administrivia.
Ian.
Re: advice for free software package named almost identically to non-free software
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:
> 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.
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.
Regards,
Ian.
Re: Bug#875876: RFS: python-dtcwt/0.12.0-1
Ghislain Vaillant writes ("Re: Bug#875876: RFS: python-dtcwt/0.12.0-1"):
> FYI, here is the interpretation of the license by the upstream author. I
> asked about it back when I did the initial release, and no issue was
> raised by the FTP team.
>
> https://github.com/rjw57/dtcwt/issues/109
Quoting that:
All Python code and documentation in this repository is BSD 2-clause
licensed. The wavelet co-efficient data is effectively in the public
domain being as it is merely a mathematical "truth" that those are
the wavelet co-efficients.
The original implementation of the DTCWT includes this clause:
[troublesome wording]
Note that the original license uses the language "use the
algorithms" which is unclear. The code in this repo implements the
DT-CWT algorithm and if an algorithm is covered by copyright in a
given juristiction, any use requires referencing the original
author. If algorithms are not copyright-able then use does not. I
have no control over this and I don't want to try to interpret the
original license.
So I think that the situation is perfectly clear. Algorithms are not
covered by copyright (anywhere). The upstream author is just being
over-cautious in leaving in that notice.
I suggest that in the Debian package we c that comment from the
github page into the source package, and put that next to the upstream
caveat about the original clause - and then remove the caveat and the
troublesome notice from debian/copyright.
Ian.
Re: does MUSIC (cosmology package) qualify as free under DFSG?
Hi, debian-science. debian-legal had a query about a program which
had a citation requirement in its licence. See below. What's our
usual approach ?
Boud Roukema writes ("does MUSIC (cosmology package) qualify as free under
DFSG?"):
> I would like to use the MUSIC cosmological initial conditions software
> https://bitbucket.org/ohahn/music
...
> ii. does not allow modification
You are right. This is probably a mistake by the upstream authors.
You should see if you can get them to fix it.
If they won't then unfortunately, unless we can find some pretty good
other evidence of their actual intent, this can't be in Debian.
> iii. does not allow distribution [conditions on distribution are
> listed, but that could be interpreted to mean that *if* you obtain
> permission from the author to distribute, *then* this is a
> constraint/reminder about conditions on the private permission that
> you have obtained]
It could. I think it's an odd interpretation, and a court would
probably decide that the copyright holders intended to permit
distribution (particularly, since they have put the thing on a public
git hosting service).
But again, you should ask them to fix it, since you're asking them to
clarify anyway.
> iv. does not allow distribution of modified copies
See (ii).
> v. requires obligatory citation of the software and research paper
>
> On point v: the GPL forbids this:
> https://www.gnu.org/licenses/gpl-faq.html#RequireCitation
> "No, this is not permitted under the terms of the GPL."
That a licence is not GPL-compatible is unfortunate, but does not make
it non-free.
> On the other hand, the same GPL FAQ seems to imply that a citation
> requirement is legally invalid. Does it matter if a licence has a
> non-enforceable (illegal) requirement that people will generally
> follow voluntarily (and under academic ethics rather than legal
> obligation)? Or rather: would this be accepted under DFSG?
I don't know what Debian's position is on this. I think the GPL FAQ
entry does not mean that this licence is unenforceable.
If it is enforceable, it may or may not be a problem. Personally I
don't have a problem with it, but it's not my opinion that counts -
I'm not one of the ftpmasters.
I know that in some other cases upstreams have been persuaded to
change such licence conditions into non-binding imprecations. In this
case that would make the resulting software GPL-compatible, which
would be very nice. Perhaps upstream can be persuaded. And perhaps
debian-science can come up with some examples to help persuade.
BTW, I am very sympathetic to the underlying motives for these kind of
licence terms. There is a big problem with lack of funding for
scientific software. See for example
https://arxiv.org/abs/1610.03159 _The Astropy Problem_
for a description of one instance of the general class of problem.
Regards,
Ian.
Re: Bug#875876: RFS: python-dtcwt/0.12.0-1
Herbert Fortes writes ("Re: Bug#875876: RFS: python-dtcwt/0.12.0-1"):
> [Ian Jackson:]
> > So I think that the situation is perfectly clear. Algorithms are not
> > covered by copyright (anywhere). The upstream author is just being
> > over-cautious in leaving in that notice.
>
> Why being "over-[cautious]" if the append is useless. That's the term I
> should use at first. It is the upstream choice.
I'm afraid I don't follow. I can't even tell if you're agreeing with
me or not. Sorry.
Ian.
Re: Anki logo copyright question
> = > > Anki's logo is copyright Alex Fraser, and is licensed under the AGPL3 > like the rest of Anki's code, but with extra provisions to allow more > liberal use of the logo under limited conditions. I read this as a dual licence. That is, the user may, at their option use the AGPLv3 permissions, subject to the AGPLv3 conditions; or they may use this alternative licence. I think this is (i) the only coherent way of reading this text and the AGPLv3 (ii) almost certainly what the licence author and the copyright holder intend. As Mike says, the AGPLv3 source code provisions etc. make it awkward to "sprinkle" the logo in relevant blog articles, books, etc. This additional permission seems to me to be clearly intended to help with that case. So the alternative licence does not require provision of source code. But it has much more restrictive modification and usage conditions. IMO in Debian we should rely on the AGPLv3 for our own purposes (so for example, the AGPLv3 makes the licence DFSG-free), and for those of most of our users. However, we should retain this alternative licence text so that Debian contributors, users and downstreams can use the unmodified logo as the upstream project intends. (I'm assuming that we don't wish to modify the logo. If we do have a reason to modify it we should consider whether we should talk to Anki upstream about preserving this additional permission for the modified logo.) We should probably also put a note somewhere to remind our downstreams that if they modify the logo, they should delete the additional licence permission (since it becomes inapplicable, and leaving it in would be confusing). Ian.
Re: configure.in is missing but...
Eriberto Mota writes ("configure.in is missing but..."):
> In #882538, Helmut pointed that outguess[1] has a configure file[2]
> generated by a missing configure.in. He considers that configure, an
> interpreted script (shell), has no source code because the following
> lines:
...
> I still have doubts about if this situation is a DFSG violation and I
> need more opinions.
Pabs and Helmut are right.
Can't you find a copy of the configure.ac somewhere ? If not, you may
be able to reconstruct one. Skimreading the configure script suggests
that wouldn't be too hard.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: French gov open license
Ben Finney writes ("Re: French gov open license"):
> More precisely, “pass DFSG” is not something we can ask of licenses.
> Rather, the DFSG are for evaluating a *work* proposed for entry to
> Debian.
>
> Until we have a work to examine, with a grant of license from the
> copyright holders (and holders of other monopolies) in that work, the
> question of DFSG doesn't even come up.
>
> So, the question will need to be asked about a work proposed for entry
> into Debian.
I think this is rather disingenuous. The most common reason for a work
being rejected is indeed probably that some part of it is not actually
licenced under the ostensible licence for the whole package.
But that doesn't mean that rejection for wrongnesses in the licence
itself don't occur. There are plenty of examples. It can make sense
to look at the licence and say "if the whole work was under this
licence, and there were no other problems, it would be OK".
I have read the licence PDF and it is a reasonable licence for open
data. But if used together with some program, it would need to be
analysed for compatibility with that program's licence.
Commonly, we would want to know if it was GPL3+-compatible. I think
it probably is. I don't see any clauses which are not restrictions
which are already in the GPL3 in other terms, so complying with GPL3
would also comply with this licence.
There is one possible exception, in that the licence requires
The re-use shall not mislead third parties or misrepresent the
content of the << Information >>, its source and its time of last
update.
"Misrepresent the content" is a bit vague. If challenged, I would
argue that this is the same as the GPL3's requirement for "appropriate
copyright notice" perhaps read together with the GPL3 requirement for
notices of modification.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Can we serve GFDL documentation (e.g. gcc-7-doc) on manpages.d.o?
Michael Stapelberg writes ("Can we serve GFDL documentation (e.g. gcc-7-doc) on
manpages.d.o?"):
> I was operating under the assumption that we can only serve packages
> from main and contrib, but I was wondering what your thoughts are:
>
> Could we serve manpages from non-free packages? I m curious both in
> general and specifically about GFDL-licensed manpages such as the
> ones from gcc-7-doc.
Things in non-free all have their individual licences. Some of them
might prohibit what manpages.d.o does. Others don't.
I haven't looked at gcc-7-doc, but a GFDL-licenced manpage would be
legally serveable if there is no front cover text and no back cover
text and no invariant sections. But such a manpage would be
DFSG-free, so ought to be in main, surely ?
There is also the question as to whether we want to mix
nonfree-but-maybe-redistributable-like-this documentation with
properly Free documentation.
Maybe if there *are* things we can present this way, we should present
them on manpages.nonfree.org ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#874295: Not a bug
Ben Finney writes ("Re: Bug#874295: Not a bug"):
> Thomas Pierson writes:
> > It's only if a user want to connect to a particular external service
> > that a plugin file is downloaded and used.
>
> That is still a problem, IMO. It would be best if the program did not do
> that, and instead prompted the user to install the non-free package
> providing that plug-in.
I agree with Ben that it would be better if the program used a
non-free package from Debian instead. Maybe we could clone this bug
into a wishlist bug for that.
> (Yes, I think a web browser should not download and execute arbitrary
> JavaScript either. That one problem remains unaddressed is not a
> justification for the same problem elsewhere.)
This is obviously out of scope for the discussion of this bug.
If you want to change Debian's stance about this, you will need to
agitate with ftpmaster, on -project, or -devel, or pass a GR, or
something.
Ian.
Automatic downloading of non-free software by stuff in main
This mail is going to a lot of lists. I have set the followups to d-policy because ultimately this is hopefully going to result in a change to policy. Over the years, d-legal has discussed a number of packages which automatically download non-free software, under some circumstances. The obvious example is web browsers with extension repositories containing both free and non-free software. We have also recently discussed a media downloader/player which, when fed a particular kind of url, will offer to automatically download a proprietary binary-only protocol module to access the specified proprietary web service. We have generally put software like this in main, because it asks the user first, and can be used perfectly well without the proprietary parts. But the overall result is that a user who wants to use Free software can be steered by Debian into installing and using non-free software, sometimes unwittingly, I would like to establish a way to prevent this. (There are even whole Debian derivatives who have as one of their primary goals, preventing this. We should aim for most of the changes necessary for such derivatives to be in Debian proper, so the derivative can be little more than a change to the default configuration.) I think the necessary new central technical component is a configuration somewhere, checked by programs with plugin download capability. We should have a conversation about: * What user experience options should ideally be available * How those options should be represented in configuration * Bug severity for programs that do not respect the "only free stuff" setting. Ideally we can come up with a technical solution which means that it is easy for existing programs implement the new check, so that failure to do so can be RC for buster. The minimum required changes to individual packages should be small. NB that this is going to be a _user option_. I'm not trying to shut down non-free extension repositories. (Indeed I sometimes use them.) I want to give users more control. Obviously excluded from this discussion are downloader packages, which have the fetching and use of proprietary things as their primary purpose, and which therefore live in contrib. But there is another category I want to distinguish: Applications for processing Turing-complete file formats. This includes web browsers, because of Javascript; but it also includes PostScript viewers; interactive fiction interpreters; and so on. The distinction between this and the general plugins I mention above is that these applications all restrict the capabilities of the code being executed, by running it in some kind of sandbox or container. The idea being that the code gets to control the user's interactions _with the providers of that code_, but not anything else. There are some people who object to executing any non-free code on their computer and I don't mind providing a facility for people to restrict that. But I don't know exactly how to design such a thing. For web browsers, there is the FSF's libre-JS. Personally I think that is rather quixotic (and doesn't really address the real user freedom question anyway), but I have no objection if anyone wants to do the work to integrate that into some kind of freeness control system. But with file formats, the situation is much harder. I don't feel we can introduce a policy requirement requiring package maintainers to support users who want this kind of restriction, until we can come up with a scheme that will actually work and be useable (and indeed, will be minimal effort for a package maintainer to opt into). (The question is: how do we stop a Postscript file received by email being rendered automatically when the user clicks on it, while allowing the user to still open a Postscript file they generated themselves ?) Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: Can we serve GFDL documentation (e.g. gcc-7-doc) on manpages.d.o?
Ian Jackson writes ("Re: Can we serve GFDL documentation (e.g. gcc-7-doc) on
manpages.d.o?"):
> I haven't looked at gcc-7-doc, but a GFDL-licenced manpage would be
> legally serveable if there is no front cover text and no back cover
> text and no invariant sections. But such a manpage would be
> DFSG-free, so ought to be in main, surely ?
To expand on this:
A cover text is IMO no good because
If you publish printed copies (or copies in media that commonly have
printed covers) of the Document
I think arguably the HTML for a long manpage on a manpage website is
"media that commonly have printed covers". It definitely would be if
manpages.d.o provided pdf outputs (which it might do in the future).
And that means that the front cover text must be included. But it is
not. I looked at the GCC manpage and it does have a front cover text,
"A GNU Manual", but it does not start with that text.
Of course maybe you disagree about "media that commonly have printed
covers" in which case maybe you'd have to just limit any future pdf
feature to properly-free manpages.
Also, in general, there is no way to easily tell what the reason is
for something being in non-free. You'd have to invent some kind of
coding or whitelist system.
IMO this is a swamp.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: SHA1 implementation by Steve Reid
Carsten Leonhardt writes ("Re: SHA1 implementation by Steve Reid"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > And, if at any point in the future somebody takes a more legalistic
> > view and starts sending takedown notices, we can just throw away our
> > existing version based on the old RFC's code and redo the integration
> > using the nearly-identical code from the new RFC.
>
> Hm, the previous maintainers of bacula removed the code because of bug
> #658326, submitted 2012-02-02. The new RFC 6234 is dated "May 2011", so
> before the bug report.
There is no evidence in #658326 that anyone was aware of the new RFC.
> > So there is, I think, very little risk to us or our downstreams, of
> > leaving this situation as is - ie, there is no point going and trying
> > to weed out code based on the old RFC (even if we could somehow
> > reliably determine whether some code was based on the old RFC
> > directly, or via the new RFC with the better licence).
>
> I'll point upstream to this thread and ask if he'd consider using the
> code from the new RFC.
The main point of my message, which you are replying to, was that:
this is pointless makework.
> (By the way, the situation "as is" is to repackage the upstream source,
> removing sha1.[ch].)
If I were the Bacula maintainer I would drop the sha*.[ch]-related
Debian delta, in my next upload, based on the arguments I make in this
thread.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Freeness of vague Synopsys license
Andreas Bombe writes ("Freeness of vague Synopsys license"):
> I am currently working on reintroducing GHDL into Debian. It is a VHDL
> compiler/simulator that includes non-standard VHDL libraries from
> various vendors and I have to throw out most of them (unlike before, it
> now comes with the core standard libraries reimplemented under a free
> license). I'm now unsure whether I should keep the Synopsys libraries
> which found some wider use before its features were finally offered by
> the VHDL language standard.
>
> Here is the copyright statement and license from one of the files in its
> entirety:
>
> | Copyright (c) 1990, 1991, 1992 by Synopsys, Inc. All rights reserved.
> |
> | This source file may be used and distributed without restriction
> | provided that this copyright statement is not removed from the file
> | and that any derivative work contains this copyright notice.
>
> It offers use and distribution without restriction, but technically not
> explicitly modification. However, if permission of modification weren't
> intended, the requirement of keeping the copyright statement would be
> pointless. Therefore I am leaning towards permission of modification
> being implied.
I agree with your interpretation.
The implication you are imputing is necessary for the wording to make
sense. At least all the common law jurisdictions I'm familiar with
would take the same approach to interpretation of legal language as
you have done.
> Keeping these files would be "nice to have" but not a requirement. Users
> with legacy VHDL projects using Synopsys libraries would need to find
> and install these libraries themselves if they were removed.
Even better: that means that in the very unlikely even that someone
would disagree with our interpretation, we could simply remove these
files again without having to untangle a lot of within-Debian
rdepends.
But even if that weren't the case I think the necessarily implication
is that permission was granted (and the copyrightholders are likely to
be estopped from claiming otherwise because everyone has been relying
on that implied permission for, presumably, years).
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: legal issues of libmusicxml
Joël Krähemann writes ("legal issues of libmusicxml"):
> I consider adding library routines support for MusicXML to my
> application in main.
>
> http://www.musicxml.com/for-developers/musicxml-xsd/
> http://www.musicxml.org/dtds/license.html
>
> Would this cause a legal conflict? Or would it make it impossible to
> distribute in main?
Just adding "support" for musicxml doesn't pose any issues whatsoever.
If you need to copy the DTSs into your program then they would have to
be free. But I read the licence text you linked to and it seems like
a fairly straightforward permissive licence. It looks
[A]GPL[123]-compatible to me, even.
So unless your "application in main" has a very odd licence, that too
is fine.
Don't forget to copy the licence text etc. into your program, if you
copy the DTDs, of course.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: clementine: installs non-free plugin at runtime
Anthony DeRobertis writes ("Re: clementine: installs non-free plugin at
runtime"):
> I think it'd be reasonable to make the confirmation dialog explicitly
> say that the plugin is not free software. But other than that, which
> does not warrant severity: serious, I think this bug should be closed as
> not a bug.
With Debian's current stance on recommending non-free software (ie, we
are, contrary to our principles, happy to do it even if the user has
decided they do not want non-free), I agree with you.
Personally I think it should be a bug if any package in main offers to
download and run non-free software, other than in some kind of
restricted environment[1], if the user does not have the Debian
non-free area enabled.
[1] The distinction I am making is between what might normally be
thought of as programs, and situations where a turing-complete
protocol is used to deliver and display something that the user
inevitably knows is controlled by someone else and which they have
explicitly asked for. For example, the JS in web pages; documents
provided as PostScript files, or whatever.
This rule would distinguish the binary blob Spotify client (forbidden)
from the proprietary music files it downloads (permitted, if there
were a Free client that could do the download).
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
Florian Weimer writes ("Re: DFSG + Hack typeface license with transition to
proposed new source file build in Debian package"):
> Ian Jackson:
> > Debian is not likely to accept a restriction on modifying glyphs. We
> > consider that Debian (and its downstreams and users) must be free to
> > make changes - even changes that upstreams disapprove of.
>
> We have historically accepted restrictions like these:
> | The programs for computer Modern are in the public domain, and readers
> | may freely generate and hand-tune their own fonts using the algorithms
> | of this book. However, use of the names is restricted: Any fonts
> | whose names cmr10 or cmbx12 or ... are identical to the standard font
> | names of this book should be fully compatible with the fonts defined
> | here; i.e., fonts with the same names are supposed to have precisely
> | the same character coding schemes and precisely the same font metric
> | files.
I don't think this is very illuminating for the Hack typeface.
The problematic restriction I said Debian was not likely to accept was
one which forbids, entirely, the creation of derivative modified
glyphs. That is not present in the text above.
A complete discussion of the status of the TeX font licence is outside
the scope of this memo :-).
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Preinstall slightly modified Debian on laptops for sale
Kumar Appaiah writes ("Preinstall slightly modified Debian on laptops for
sale"):
> Dear Debian Legal,
Firstly, you need to know that this mailing list is for discussion
etc. and is not empowered to make decisions on behalf of Debian, or on
behalf of the copyrightholders of the software in Debian.
Also, I am not a lawyer and I am definitely not your lawyer.
So what I say is in an effort to be helpful, but you remain solely
responsible for whatever you do, even if my advice below turns out to
be wrong.
> I am working with a team that is working on a low-cost laptop that
> would be GNU/Linux based. When it comes to choice of distribution that
> would be preinstalled on the laptop, Debian is among them. In this
> context, please let me know the following:
>
> - Do I need someone's permission to sell the laptop with Debian
> GNU/Linux preinstalled?
No, you don't.
But there is a question about branding: if you want to mention Debian
in your advertising, which you probably do want to, you should read
the Debian trademark policy:
https://www.debian.org/trademark
> - Since the laptop is Cherry Trail based, some extra drivers and
> modules are needed for sound and wifi, thereby requiring a custom
> kernel. If I bundle a custom kernel (with legally freely
> redistributable files), can I still go ahead and redistribute this
> custom version without permission? Note that this is the only
> modification to stock "stretch".
If the drivers are Free Software with a Linux-kernel-compatible
licence (freely _modifiable_ under the terms of the GNU GPL2, not
merely freely redistributable) then there is no problem.
If the drivers are not Free Software (for example, the "source code"
is obfuscated, or the drivers are supplied only as binary .ko files)
then that is forbiddden by the licence of Linux.
But there are a couple of other things that might give concern about
this approach: firstly, what about security support ? Bugs in the
Linux kernel are frequently discovered. Your users will need to get
those security updates. Maintaining your own version of the kernel,
and distributing updates to it, is going to be a lot of work for you.
Does a Debian backports kernel not meet the needs of this hardware ?
Or maybe a kernel from Debian testing (aka "buster", the release
currently in preparation) ?
Your users would probably be better-served by a preconfiguration which
uses a kernel from Debian, even perhaps one which is not yet
officially released by Debian, than if you try to roll your own.
(This should be done by appropriate apt configuration, so that when
Debian provides new kernels, the user gets them automatically.)
Although Debian doesn't formally give security support for all of
these kernels, in practice they would probably get updated faster than
you would mananage if you had to do it yourselves.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Preinstall slightly modified Debian on laptops for sale
Ian Jackson writes ("Re: Preinstall slightly modified Debian on laptops for
sale"):
> Kumar Appaiah writes ("Preinstall slightly modified Debian on laptops for
> sale"):
> > I am working with a team that is working on a low-cost laptop that
> > would be GNU/Linux based. When it comes to choice of distribution that
> > would be preinstalled on the laptop, Debian is among them. In this
> > context, please let me know the following:
I should say that the legal aspects of my answer are not specific to
Debian.
And it remains that your users would be better off with a kernel from
their distro, whatever that distro is.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Preinstall slightly modified Debian on laptops for sale
Kumar Appaiah writes ("Re: Preinstall slightly modified Debian on laptops for
sale"):
> On Thu, Dec 07, 2017 at 12:56:31PM +, Ian Jackson wrote:
> > And it remains that your users would be better off with a kernel from
> > their distro, whatever that distro is.
>
> Thanks for the perspectives, Ian. I guess that we would have to
> maintain the kernel separately till this becomes upstream. I will
> figure out the other aspects at my end.
Good luck.
As a practical matter, if you do end up maintaining your own kernel,
you will probably find that the same kernel can be used for many
different Debian derivatives. (If you are really lucky you'll find
that some Debian derivative already has a useful kernel and you can
supply the Debian userland with that distro's kernel, until Debian
gets the relevant drivers.)
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#883731: audacious: Debian packaging has incorrect license
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.
Thanks,
Ian.
Re: New license review
Bastien ROUCARIES writes ("New license review"):
> May I ask a review about this license (http://lillicense.org/v1.html,
> verbatim below)
Ie, this one:
> Any modification to the software submitted to the authors may be
> incorporated into the software under the terms of this license.
I think this is untroublesome. It is saying that _if_ modifications
are submitted to the upstream (impliedly, by the authors of the
modifications), the upstreams are granted permission to redistribute.
There is no obligation on a patch author to submit, so the licence
condition is no problem.
It looks like an attempt to deal with the "patches submitted with no
signed-off-by" problem.
I assume you are looking at some actual software you think is released
under this licence. There may be other problems with that specific
software, of course, so the answer I am giving is necesssarily
abstract.
Ian.
Re: New license review
Bastien ROUCARIES writes ("Re: New license review"):
> On Mon, May 14, 2018 at 2:24 PM, Ian Jackson
...
> > I assume you are looking at some actual software you think is released
> > under this licence. There may be other problems with that specific
> > software, of course, so the answer I am giving is necesssarily
> > abstract.
>
> Yes packaging node-docco https://github.com/jashkenas/docco/
I haven't done a full review but it seems OK to me. You ought to
search the source tree for anything that looks like it came from
elsewhere.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Running an external JBIG2 encoder if one exists
Sean Whitton writes ("Running an external JBIG2 encoder if one exists"):
> An upcoming release of OCRmyPDF, which I maintain in Debian, will call
> jbig2 if it can be found on PATH, or gracefully degrade. On Debian,
> this won't do anything, since we don't have that package.
>
> I don't have any trained intuitions about patent law, but I assume that
> the fact that OCRmyPDF contains code that looks for a jbig2 executable
> is not any kind of patent violation?
It seems unlikely to me that this would be a problem.
Not that I think you have done anything wrong, but this is probably a
good time to remind everyone of:
https://www.debian.org/legal/patent
https://www.debian.org/reports/patent-faq
If you want more reassurance than "seems fine" from someone like me, I
guess you should email patents@d.o with the info requested in
/legal/patent.
Ian.
Re: Logos in Dask documentation
Paul Wise writes ("Re: Logos in Dask documentation"):
> On Wed, Jun 6, 2018 at 1:01 PM, Diane Trout wrote:
> > Several logos are linked to in the Dask documentation, and
> > I was wondering how I should resolve them.
>
> Are they present in the source package or are you concerned about
> privacy violations from browsers downloading remote images when
> loading the local documentation?
It's not just privacy violations. These kind of external references
in packaged documentation can make offline use of the documentation
very annoying. Offline use is an important reason why someone would
install the -doc package rather than just go to the project website...
> > Here' is the list of logos and what I found for their terms of use.
>
> I wouldn't recommend it, but one other solution is to just ignore the
> logos and their licensing and keep them as-is. This is what Debian's
> firefox packages do for the search engine logos.
I don't see any problem with copying the logos into the source
(whether into the upstream source, or into the Debian package).
I know that some DFSG zealots will say that this is a DFSG violation
but I think it's de minimis, particularly because (i) obviously the
logo's owners are not going to mind since the whole purpose is to
credit them, so there is no risk of anyone being sued (ii) if the
logos ever give any legal or practical trouble in the future they can
be simply replaced by text at that point. I think that providing a
nice credit to the sponsors is worth these tiny risks.
I appreciate that this kind of purposive approach to the
interpretation of the DFSG (or indeed any of Debian's documentation)
is an anathema to much of Debian's culture. Many Debian members value
legalistic compliance with written documents, over promoting the
underlying purposes of those documents (and indeed over promoting our
other values and goals).
Ultimately the arbiter would be ftpmaster, who are rather inscrutable.
You could try it, and see what they think. As a matter of integrity,
you should draw the matter to their attention (as well as that of
downstreams) by mentioning it in d/copyright.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: GPLv3 source code with license check for some build configuration, DFSG ok?
Florian Weimer writes ("Re: GPLv3 source code with license check for some build
configuration, DFSG ok?"):
> Thomas Preud'homme:
> > The questions I was asking in the original thread on -mentors are:
> >
> > - Is a non-ultimate build DFSG ok?
> > - Does the ultimate build respect the GPLv3?
> >
> > I'm leaning towards yes (because no usage restriction, source
> > available, GPLv3 which allow redistribution with or without
> > modification) and no due to this stanza in GPLv3:
>
> What does upstream have to say about this matter?
>
> The legal situation is a bit murky here, especially if the key prompt
> contains a copyright notice, whose removal is forbidden by the GPL.
I don't agree with this analysis. The GPL does not generally forbid
removal of copyright notices; it requires their appropriate display
(see "Appropriate Legal Notices" in the definitions.)
OTOH we do not patch out copyright and self-advertising messages that
other programs print when started interactively, so we shouldn't do so
here either.
> In general, the GPL does give permission to patch out things like key
> entry fields and key checks, but the fact that you are able to infer
> that the author likely intended something else makes the GPL
> declaration somewhat doubtful (despite the curious construction in
> section 7 of the GPLv3).
I think s7 of the GPLv3 is a complete answer to suggestions that there
is somehow some implied additional restriction.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]
Steve Langasek writes ("Re: Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]"):
> I don't think you should be taking it upon yourself to add copyright
> statements regarding debian/ contents where authors have not asserted their
> copyright up front. There is precious little in debian/, outside of
> debian/patches/, which should generally be considered copyrightable in a
> well-done package.
I agree.
But also I would like to suggest that people editing debian/ should
explicitly add a CC0 dedication (or similar) somewhere.
The licence of debian/ needs to be comptatible with the licence of
the rest of the package, and it is often useful to copy fragments from
one debian/ to another.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]
Ian Jackson writes ("Re: Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]"):
> But also I would like to suggest that people editing debian/ should
> explicitly add a CC0 dedication (or similar) somewhere.
This was ambiguous. I mean that the person editing debian/ should
dedicate *their own* changes via a CC0 statement.
I agree that one should not add new copyright notices relating to
other people's contributions.
It is OK to *copy* existing copyright notices from elsewhere in the
pacagke to debina/copyright, since that is what debian/copyright is
for.
Ian.
Re: Can a license be "DFSG approved"?
Paul Wise writes ("Re: Can a license be "DFSG approved"?"):
> On Thu, Oct 26, 2017 at 9:53 PM, David Seaward wrote:
> > I was also reminded of the comment below, and wondered in retrospect if
> > a flagging licenses as "DFSG approved" actually makes sense?
>
> The DFSG is not a body that can approve things. You could say "DFSG
> compatible", or "foo version X under license Y was approved by the
> Debian ftp-masters".
I think a better and more verifiable thing to say would be:
"Software wholly under this licence has been accepted as Free Software
by Debian".
The evidence required for this assertion is, of course, a pointer to
the Debian archive. A possible counter-evidence might be a bug
report. Depending on the response of various parties, bug severity,
etc. the status of the software might then be "disputed" or
"rejected".
A difficulty is that a licence's status according to Debian might
change over time. Does this attempt at taxonomy handle that ?
Note the important difference between the following two kinds of
reasoning:
A. Package X is in Debian ([url to archive]) and the version in
Debian is solely licenced under licence Y. There are no bugs in
the Debian BTS against X claiming it is non-free. Consequently,
licence Y seems to be sufficient in Debian, if there are no other
problems, and other packages under the same licence are likely to
be accepted (assuming they pass copyright review etc.)
This is sound reasoning.
Verssus:
X. Package X was discussed somehow by Debian. { ftpmaster rejected
it | there is an RC bug open against the version in the archive
| it is scheduled for removal }. The version Debian considers
questionable is licenced solely under licence Y.
Therefore XXX Debian does not like licence Y XXX.
The conclusion surrounded by XXX does not follow from the premises.
Quite possibly there are other problems with the specific package -
missing source code; some files whose authors do not actually appear
to have been licenced them under Y; or whatever.
To decide that the problem is with the licence would require more
interpretative work of Debian's public stance and discussions. This
is difficult because Debian does not always provide clear reasons for
rejection. It is also difficult because there are many licences and
packages that are so obviously non-free that no-one ever discusses
them - and bringing them up on debian-legal, or asking ftpmaster about
them, would be a waste of time.
I do wonder if this approval tag might set up a bad incentive, for
people who want to promote licences to try to get a package or two
with that licence into Debian.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Are register names and locations under copyright?
Philipp Klaus Krause writes ("Re: Are register names and locations under
copyright?"):
> However, the files are just lists of register names and locations. So if
> the files are not under copyright, I guess that copyright note could be
> ignored?
Yes.
The ftpmasters seem to have agreed in the past, on this point,
according to the example supplied by Milan.
I suggest copying the "Comment".
Make sure that the source .inc really is just the list of register
names and locations, and doesn't contain (eg) discursive text, or
substantial assembler macros, or whatever.
Ian.
Re: GPLv3 source code with license check for some build configuration, DFSG ok?
Thomas Preud'homme writes ("Re: GPLv3 source code with license check for some
build configuration, DFSG ok?"):
> The questions I was asking in the original thread on -mentors are:
>
> - Is a non-ultimate build DFSG ok?
> - Does the ultimate build respect the GPLv3?
I think there is no legal problem. The questions are of ethics.
AFAICT from what you are saying:
The "ultimate" build is somehow superior.
The upstream authors have granted legal permission by using the GPLv3,
to disable the licence check. I guess that they would prefer users of
the "ultimate" build to pay them or something; this is probably mostly
"enforced" by providing users pre-built binaries, and hoping that
no-one will ship non-licence-enforcing binaries.
So I don't think there is any _legal_ problem with any of the options
you are considering.
> Feature wise, the ultimate edition seems to only differ in the
> license check, message with the version being embedded the word
> "ultimate" and the absence of the following text in the UI: "Buy the
> Ultimate version to fund development". The ultimate build seems to
> be limited to Mac OS and Windows only, ie it does not build on Linux
> but that's only because of a macro check. It could trivially be
> disabled.
I think there is nothing very objectionable about that UI text,
provided it's not too intrusive. Indeed, GNU programs print
self-advertisements too (not asking for money, so that's perhaps a bit
different, but the same principle applies).
If the extra UI is an annoying nag then there should be a way to
disable it but IMO you can leave it enabled by default.
> Given the differences mentionned above, I prefer to just use a non ultimate
> build. The only difference except version number in some help string is to
> encourage users to contribute to its development by telling them to buy the
> ultimate edition. They are free not to do it so I think that respects the
> DFSG.
Yes.
So, there is no problem, I think.
Personally, I would not simply disable the UI nag, even though we have
legal permission to do so. Upstream would probably find it annoying.
OTOH if there are actual _features_ in the "ultimate" version that
aren't in the standard version, they should be enabled in the Debian
package. It is OK for a Debian package to promote, to a limited
extent, the reasonable agenda of its upstreams - but we should not be
shipping crippleware.
HTH.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: CUPS GPL → Apache license change, how to proceed?
(Adding d-legal)
Didier 'OdyX' Raboud writes ("CUPS GPL → Apache license change, how to
proceed?"):
> tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to
> "Apache-2.0"; how should the license incompatibilities be enforced?
This reply is going to be annoying, I fear:
> Some questions at this point (Some for FTP Masters, CC'ed):
> - Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking
> is unacceptable for Debian main? In both directions?
I think the answer is "yes, we think that is unacceptable".
ftpmaster seem rarely to reply to these kind of questions. If you
actually want the answer, I suggest you:
- search for existing cases and see if they got REJECTed or ACCEPTted
- upload and see
:-/
> - Can CUPS link against GPL-2-only code?
> - Can GPL-2-only code link against CUPS?
I don't understand how these are different to the previous question.
> - Whose reponsibility is it to check for these incompatibilities, and make
> sure they are not shipped in Debian?
I think (and this is my personal opinion) that a licence
incompatibility is a bug in the depending package, and it is the
responsibility of the depending package maintainer.
> - What tools should I be using to identify which of these will be
> undistributable constructs?
I'm not aware of any useful tools and I hope someone else will be
able to help.
> Aka: how, given a list of source
> packages, can I determine which are GPL-2-only in the codepaths that
> link against CUPS? - What fields could I / should I use in src:cups
> to enforce these? I was initially thinking of setting versionless
> Breaks: in each src:cups' library against the identified GPL-2-only
> culprits, then mass-filing bugs against these, promising to add
> version constraints when/if the licensing issue gets lifted. Does
> that sound like a good way forward?
I guess. It seems like a lot of work, and the cups transition would
be blocked.
You might instead consider simply filing bugs against the
dependencies, and setting a deadline by which they will be escalated
to RC. You will want to discuss this with the release team.
Good luck.
Ian.
Re: DFSG-compatibility of X13-ARIMA-SEATS (U.S. federal govt. software)
Sébastien Villemot writes ("DFSG-compatibility of X13-ARIMA-SEATS (U.S. federal
govt. software)"):
> However, the last clause of the licence says that the `user agrees to
> make a good faith effort to use the Software in a way that does not
> cause damage, harm, or embarrassment to the United States/Commerce.'
I think this is straightforwardly non-free.
Suppose that Russia or the People's Republic of China wants to use
Debian in a weapon system, and wants to use this package (whatever it
does) as part of that.
Of course many people object to working on weapons systems, and I
would avoid doing so myself. But the compromise we make when working
in Free Software is that we choose to waive our right to pick and
choose who benefits from our software, and to what uses our software
is put.
If we want to fight against robotic weapons systems, or torture, or
war at all, or oppressive governments, we still avoid prosecuting that
fight by means of writing prohibitions in our software licences. The
alternative would be an incomprehensible warren of interlocking
restrictions about which software can be used for what and by whom.
The restriction you quote is particularly bad, because it
discriminates in favour of specific people. One is forbidden from
using this software to attack the United States (whether with
violence, or with words). Attacking the European Union or Russia or
the PRC is fine. Except within the US of course where the licence
doesn't apply - so Russian and PRC agents in the US can use it, and
only risk being convicted of spying or sabotage, and not the much
worse crime of copyright licence violation.
Ian.
Re: DFSG-compatibility of a overly short license [tensorflow dependency]
Andrej Shadura writes ("Re: DFSG-compatibility of a overly short license
[tensorflow dependency]"):
> The homepage of the project says (www.kurims.kyoto-u.ac.jp/~ooura/fft.html):
> > You may use, copy, modify and distribute this code for any
> > purpose (include commercial use) and without fee. Please
> > refer to this package when you modify this code.
Oh good.
> In my opinion it is quite clear it is not disallowing redistributing
> modifications.
Please replace the licence text in the package with the text fromk the
web page, and leave some notes in debian/ in the source package about
when you retrieved the web page (and, ideally, a copy of the page).
You probably also want to send a patch to upstream to fix the LICENSE
file to agree with the website.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Font-Awesome 5 no build system DFSG compatibility
Simon McVittie writes ("Re: Font-Awesome 5 no build system DFSG compatibility"):
> I think this is a technical issue, but not a DFSG violation; and I think
> it would be appropriate to track it as a bug, but not a release-critical
> bug.
I have a different analysis, at least, as far as I currently
understand the situation.
What is going on here is that upstream are keeping some of the actual
source code (and yes, I think the Makefiles count - I agree with the
GPL's definition of source in this context) secret (perhaps
unintentionally). We need to obtain it. If we can't, then perhaps we
can produce an equivalent build sequence to replace the missing parts.
IMO for files which are built automatically by upstream, they should
be built automatically in Debian too.
> The same situation exists in any package where some hard-to-modify,
> non-executable data file (perhaps an icon) is accompanied by its
> easier-to-modify source form (perhaps in GIMP format or as a SVG) but
> a manual export step is required to transform the source form into the
> modifiable form.
This is quite different. In those cases there is no other build
system. When there is no other build system, then upstream are doing
the same manual thing that we are expecting ourselves, our users, and
our downstreams to do.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Hacking License
Giacomo Tesio writes ("Re: Hacking License"):
> On Mon, 10 Dec 2018 at 18:31, Ian Jackson
> wrote:
> > I recommend to my fellow Debian Developers that they do not try to
> > introduce into Debian a package with this licence. In particular,
> > I would recommend to my fellow DDs not to sponsor such a package.
> > That will save ftpmaster the bother of reviewing this licence.
>
> I guess this is a political recommendation with the weight of an order.
I have no more authority on this question than any other DD. Maybe
you will find one who disagrees. Debian is far from homogenous.
> Is there something I can do about it?
> If the problem is not in the text of the license, how can I fix it?
In the short term, you can add a clear compatibility clause that
allows relicensing as a well-known existing licence, or you can use an
existing licence.
In the longer term you can engage with the copyleft community - in
fora other than debian-legal - to move the wider community's centre of
opinion in your preferred direction.
Or you can try to find some DD who has the time and inclination to
- sponsor your package at a technical level
- ignore or disagree with recommendations from people like me
- review your licence in detail
- engage with you and with Debian ftpmaster to help resolve
whatever issues they and you and ftpmaster identify
For the avoidance of any doubt, I think I am probably not opposed to
your political goals. I may well even support them. That seems
likely. Maybe they are even important enough to justify a new
licence, but I think they don't justify trying to go it alone in the
way you seem to be doing.
> However, if you express the consensus in Debian, I suggest to fix the
> texts at https://lists.debian.org/debian-legal/ and at
> https://people.debian.org/~bap/dfsg-faq so that it more clearly
> express the intents, boundaries and goals of this mailing list.
As for the first link, it says only
| Copyright, licensing and patent issues
| Discussions about legality issues such as copyrights, patents etc.
which IMO accurately describes the scope of the list within Debian.
I'm sorry that not all of Debian's practices, including our
disinclination to help with the detailed review and drafting of
bespoke licences, are documented. If this were to be documented it
would be in the Developers' Reference, probably, and certainly not the
mailing list description.
The second link is someone's personal web page over which I have no
control, and over which Debian exercises no control other than to
avoid things like Code of Conduct breaches. It has the word `DRAFT'
in the page title. If you have read anywhere that it is in any way
official, please let me know and I will arrange to have its status
made clearer.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Hacking License
Giacomo Tesio writes ("Re: Hacking License"):
> On Mon, 10 Dec 2018 at 17:29, Ian Jackson
> > I think Giacomo would be well served by adopting AGPLv3+ and
> > nominating himself as licence steward.
>
> Thanks for your suggestion.
> Unfortunately AGPLv3 doesn't cover many of the issues I try to address
> with the Hacking License.
Well, these things are a tradeoff, aren't they ?
Are you more concerned about on the one hand, the ability of people to
use your code in larger projects, and distribute it easily, and so
on ?
Or are you really convinced that these other issues are showstoppers
and that without handling them in your licence, downstreams will abuse
their position ? Frankly that doesn't seem particularly likely.
I think maybe you are seriously undervaluing the benefits of using a
licence that everyone already knows and that is compatible with many
other Free Software licences.
> Also, changing the license steward on an AGPLv3+ could cause serious
> confusion to users in the long term.
I think you must have misunderstood me. I meant that you would avail
yourself of this paragraph of AGPLv3 s14:
If the Program specifies that a proxy can decide which future
versions of the GNU Affero General Public License can be used, that
proxy's public statement of acceptance of a version permanently
authorizes you to choose that version for the Program.
You would nominate yourself, presumably. Then if you engage with
copyleft-next and a new licence (an AGPL successor perhaps) appears
that you like you can use that.
Another alternative that you should seriously consider is to dual
licence your code.
Anyway, I agree very strongly with Ben Finney's criticisms of your
approach. I don't think engaging with the detail of your licence text
is a good use of Debian's time. Nor is this mailing list a good
drafting review panel anyway.
I recommend to my fellow Debian Developers that they do not try to
introduce into Debian a package with this licence. In particular,
I would recommend to my fellow DDs not to sponsor such a package.
That will save ftpmaster the bother of reviewing this licence.
Sorry,
Ian.
Re: Hacking License
Giacomo Tesio writes ("Re: Hacking License"):
> On Wed, 12 Dec 2018 at 10:49, Simon McVittie wrote:
> > When
> > faced with a non-standard license with unclear terms and no community
> > consensus on its consequences, it's quite a rational response to think "I
> > don't have time to think about this" and decide to contribute to something
> > else instead.
>
> This is not a rational response, just a lazy one.
On the contrary, laziness is often very rational. We all have a
limited amount of time and energy. We have to make decisions about
what to spend that on. Time I spend analysing licence texts is time I
have not spent learning a new programming language. It is also time I
could have spent improving my own software tools - a big goal of which
is making it eaiser to hack on the software on your computer.
Often we need to make those decisions very quickly because spending
time on researching what to do is also time which can be wasted.
Perhaps you don't care about encouraging, into contributing to your
project, people who are short of time and who are picky about what
they spend time evaluating.
> To give a rational response, you have to consider the alternatives and
> the outcomes of contributing to that specific software under that
> specific license in that specific time and place.
And most people are not licensing experts. It doesn't make sense for
them to try to decide all this stuff for themselves. Rather, they
will reasonably defer to the consensus of some other community, that
they trust.
> But such cognitive load is the price of Freedom.
Freedom is also the freedom not to think about things. Personally I
think true software freedom comes when it is quick and convenient to
use software which, if and when I decide I want to get more stuck in,
makes it possible to modify and share - with a amount of energy
commensurate to the depth of the changes I want to make.
The Free Software community has not always recognised this, but we are
starting to. That's why we have bigger arguments in Debian now about
defaults that we used to in the past.
And, freedom is also the freedom to engage *collectively* and do
things *together*. The freedom to trust the judgements of others
(including, sometimes, other communities) - knowing that sometimes
that trust will be misplaced, but knowing also that the benefits from
trusting usually far outweigh the costs. Trusting relieves us of the
need to constantly re-make others' decisions in areas where we lack
expertise. It allows us to build on the work of others instead of
redoing it or dismantling it. It allows us to combine our efforts.
To put it bluntly: I have more trust in the collective wisdom of the
GPL-3 and AGPL-3 drafting processes, and the general Free Software
licence development community, than I do in either your judgement on
these questions or indeed my own personal skill at licence drafting or
review.
And now I will exercise my freedom to direct my energy by not engaging
with the rest of your message...
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Hacking License
Giacomo Tesio writes ("Re: Hacking License"):
> Laziness is blind cost minimization.
>
> [150-odd lines more text deleted]
/me blindly minimises costs:
tl;dr
I think this closes the converation for me. I've made my pitch, and
you disagree.
Ian.
Re: Hacking License
Xavier writes ("Re: Hacking License"):
> No Debian accepts any license that are DFSG compliant (DFSG is just a
> guidelines). You may use the 3 tests to understand what may be wrong :
These tests are not official. AFAIAA they do not form part of the
approval process used by the Debian ftpmasters when they make
decisions on the acceptability of some work for Debian.
Xavier, please do not misrepresent the situation.
I agree that inventing a new licence is a bad idea. I think Giacomo
would be well served by adopting AGPLv3+ and nominating himself as
licence steward.
Thanks,
Ian.
Re: Copyright concerns regarding Seafile
Jan-Henrik Haukeland writes ("Copyright concerns regarding Seafile"):
> Libzdb is licensed under GPLv3. Copying and modifying GPL code is
> perfectly fine as long as the original copyright notice and license
> are kept. Unfortunately, this is not what the Seafile team
> did. Instead they copied code from libzdb, removed the copyright
> notice, claimed the code as their own and re-license it under
> another license.
That is very clearly Not OK.
However, I am puzzled by something. AFAICT from github seafile-server
claims to be AGPL3-only. You are talking about a licence conflict
with libzdb which is GPL3+.
But GPL3+ and AGPL3 are compatible. So why did the seafile developers
feel the need to engage in this subterfuge ?
Ian.
Re: Copyright concerns regarding Seafile
Andrej Shadura writes ("Re: Copyright concerns regarding Seafile"):
> On Wed, 15 May 2019 at 12:10, Moritz Schlarb wrote:
> I fully agree. Since the client doesn’t include the code in question,
> it’s out of scope of the issue, so there is no reason to remove it
> >from Debian.
I am very uncomfortable with having code in Debian whose upstream
authors appear to have plagiarised some other people's software, and
then obfuscated it, in order to evade copyright licensing. Who knows
what other misleading practices they have engaged in, or may do in the
future ?
As a project, we do not have the resources to fully audit all the code
we ingest from upstreams and redistribute to our users. We must rely
on trust. That depends on the upstream being trustworthy.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Missing source in firefox-esr: EME module
Nat Tuck writes ("Missing source in firefox-esr: EME module"):
> The firefox-esr package in Buster includes the encrypted media extension
> functionality, which relies on library called "wildvine". Source for
> this library is not included in the firefox-esr source package.
>
> This has been an outstanding bug since 2016, but it hasn't been
> considered as a serious issue with the package:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837091
That bug seems to contradict you.
Firstly, it says that firefox-esr only downloads this proprietary
software after explicit user action. Is that right ?
Secondly, it is indeed tagged as "serious", ie release critical.
I think the behaviour described at the end of that bug is quite
undesirable. I think user action to download non-free sofware should
be more explicit, and not so easily invited.
Overall, in Debian, we do not have a good enough mechanism for user
control over these kind of suggestions. There should be a single
place where a user can say, during installation, what their posture is
for non-free software.
Options should probably include:
0 Never suggest non-free software to me; simply don't mention it.
1 Explicitly confirm for each piece of non-free software.
2 Automatically download and run non-free software whenever
it is likely to be convenient.
We would have to have some kind of argument about JavaScript on web
pages. I don't think the FSF's "librejs" stuff is useful in practice
but we should probably offer it as an option. Something like a ublock
configuration that turns off JS by default and can be fiddled with,
would probably be appropriate for users who select 0 or 1.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Custom license conditions and grant for Wordplay package
Moshe Piekarski writes ("Re: Custom license conditions and grant for Wordplay
package"):
> The copyright holder made a statement on Facebook chat that he considers
> the code to be in the public domain. Is that enough for me to consider
> it such?
While legally in some jurisdictions there is no such thing as public
domain, I think the intent of the copyright holder - to grant very
broad permissions, certainly broad enough for Debian - is clear.
There is a difficulty with how we would provide evidence of this
statement if it came to that. Can you put a transcript and/or
(hopefully fairly small) screenshot into the source package ?
I don't use Facebook, so I will ask: How do you know that the Facebook
user in question is the same person as the copyright holder ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Missing source in firefox-esr: EME module
Nat Tuck writes ("Re: Missing source in firefox-esr: EME module"):
> The binary-only wildvine component of Firefox, as incorporated in
> the package currently shipped by Debian, can not reasonably be
> understood as an "optional addon that is downloaded separately in
> response to an explicit user request". It is intended as integral
> functionality of the browser, and the technical mechanism of
> downloading that component separately exists only as an attempt to
> game standards such as the DFSG that prefer free software.
You didn't answer my question:
| [The bug] says that firefox-esr only downloads this proprietary
| software after explicit user action. Is that right ?
AIUI if I (and personally I am a user who do not want this) do not
ever give my browser permission to do this, it will never download it.
I think your complaint is that it is making it the default easy path.
Personally I would agree with such a complaint, as I said in my
earlier mail.
> Comparing this to the librejs question is unreasonable.
I appreciate that you are angry. I'm sorry that the rest of my mail
seemed to push your buttons rather. I did not intend to make an
equivalence between the librejs question and this DRM thing.
But the question of global control of suggestions to download
proprietary software inevitably involves consideration of various
different kinds of proprietary software.
> Are there other packages in Debian main that have hardcoded URLs to
> download to non-free components from third parties? How do they
> handle this?
I don't know for sure.
I think there are probably other packages besides browsers with their
own add-on or plug-in repositories. Those repositories sometimes have
a mix of free and non-free software.
The thing you are complaining about here is different, because that
particular feature only ever downloads non-free software.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Missing source in firefox-esr: EME module
Nat Tuck writes ("Re: Missing source in firefox-esr: EME module"):
> [Ian Jackson:]
> > You didn't answer my question:
> > | [The bug] says that firefox-esr only downloads this proprietary
> > | software after explicit user action. Is that right ?
...
> If the "Enable DRM" preference is ever enabled, the software is automatically
> downloaded and installed transparently in the background. There are two ways
> that preference can be enabled:
>
> - Checking "Enable DRM" in preferences.
> - Visiting a page with a DRMed video on it.
>
> When you visit a page with DRMed video a yellow nag bar appears at the top of
> the page with the text "You must enable DRM to play some audio or video on
> this page", as well as a single "Enable DRM" button. Users click off these
> nag bars without reading them - so it's questionable that this is further
> user interaction than simply pressing "play" on a video. But even if you do
> read the text, in neither case are you requesting a software download.
OK so there are a number of problems here, which add
1. The message asking permission is far too inexplicit. (TBH I
remember deciding not to approve, when prompted by such messages,
but because I hate DRM - and I didn't know that if I had approved,
it would have downloaded proprietary software too.)
2. There is no way to prevent firefox from repeatedly asking
permission.
3. Users who have not installed software from contrib find that their
Debian firefox package will offer to download and run proprietary
software.
Fixing problems 1 and 2 will not be controversial, I hope. Would you
care to write a patch which changes the message, as a start ?
Presumably fixing problem 2 is not that hard either: at least,
providing something that could be set in about:config.
Problem 3 is awkward because in Debian we do not have a consensus
understanding of when it is appropriate for a package in main to
download and run proprietary software. I think this will require a
General Resolution to fix, but necessary groundwork involves figuring
out what behavioural profiles users want, and trying to align those
behavioural profiles to our existing archive areas.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Missing source in firefox-esr: EME module
Nat Tuck writes ("Re: Missing source in firefox-esr: EME module"):
> All that gets a bit off topic for why I started this thread on debian-legal.
> Currently, the Firefox package *logically* bundles this component in a way
> that's clearly intended to dishonestly circumvent the DFSG. Papering over the
> issue with UI changes just feels like doubling down on that dishonesty.
I think you are missing something very important.
Namely, you have failed to appreciate that this is a *political*
problem. It needs a political solution. You will not get this
problem fixed by simply stating your opinion, and your reasons, on
this list (on in bug reports).
> Your proposal of simply changing the text is effectively trying to convert
> DRM *into* an addon.
I can definitely see that way of looking at it. To my mind it would
make the problem less severe.
> I don't think it's appropriate to start by simply changing the messages since
> that doesn't solve the majority of the problem, but it would make the issue
> seem less urgent.
Well, that is a question of political tactics. Personally I think it
is not a good look to refuse to help mitigate a problem because you
want the problem to be more obviously bad for tactical reasons.
I tried to help by suggesting possible starting strategies. You don't
need to agree with me. But in order to effect any change here you
will need to build a coalition of opinion sufficient to force a change
in Debian's approach.
I think the problem with proprietary addons offered by software in
Debian is a significant one, which we should address head-on. If we
did that then users who are concerned with their own software freedom
will easily be able to avoid both this DRM code, and proprietary
addons. Ie, solving the problem of addons would solve your firefox
problem.
That's why I wrote this:
> > Problem 3 is awkward because in Debian we do not have a consensus
> > understanding of when it is appropriate for a package in main to
> > download and run proprietary software. I think this will require a
> > General Resolution to fix, but necessary groundwork involves figuring
> > out what behavioural profiles users want, and trying to align those
> > behavioural profiles to our existing archive areas.
Feel free not to take my advice.
But I am afraid that your current approach is doomed. You seem to
have come to -legal to try to use it as a lever to fix #837091. But
-legal has no authority.
Maybe you came here to drum up support. That got you engagement with
one potential ally, namely me. But you have responded by arguing with
me about semantics and details, rather than looking for common ground
and trying to develop a political strategy. So I am not encouraged
:-(.
Regards,
Ian.
Re: upstream changing from GPL-2+ to GPL-3+ without copyright holders permission
Florian Weimer writes ("Re: upstream changing from GPL-2+ to GPL-3+ without
copyright holders permission"):
> Andrej Shadura:
> > then it is totally fine to choose that option, since the copyright
> > holders have already given that permission you think they need to
> > give.
Yes. For more detail, see Francesco Poli's response which I think
answers the legal question entirely correctly.
> In general, I agree. But there might be cases that are less
> clear-cut. For example, if the upgrade from GPLv2+ to GPLv3+ is used
> to gain permission to combine the work with an AGPL work, especially
> if this is done in an "open core" context.
Florian, are you still answering the legal question ? Because I don't
see how these kind of considerations (eg, the reaason for the licence
upgrader's choice, or the business model of the original authors)
could make much of a legal difference. So I think if you intended to
answer the legal question then I completely disagree with you.
If you intended to answer (given the introduction of "fine") moral
questions instead, then of course these questions are much more
subjective.
Then your view is a reasonable one, but I would tend to disagree.
Personally I have often taken GPLv2+ code and mixed it (either by
textual copying, or by linking) with AGPLv3+ code, taking advantage of
the GPLv2+ version upgrade and the GPLv3+'s AGPL-compatibility clause.
I have done similar things with LGPL'd code and the GNU GPL(s).
I dislike the open core business model; and I dislike
software-as-a-service models where the code is in practice Free for,
and owned by, only the service operators (usually, one dominant
service operator) - and thus in practice proprietary for everyone
else. I don't think there is any ethical imperative to support these
business practices, and no obligation to avoid undermining them.
> I also think that in general, Debian should try to respect copyright
> holders' wishes, even if the project is not required to do so.
> Disregarding authors rarely leads to good outcomes.
I think taking proprietarised GPL service code, and making significant
enhancements under an AGPLv3+ licence, is a Good Thing. Even if it
upsets the original authors or the proprietary service operators.
Whether it is a good community-building strategy is a different
question of course, and depends on how much interest there is in
freeing the code in question.
And, as individuals and companies we oftn need to make practical
political compromises (eg in our employment, or in our business
dealings, etc). That might mean we would avoid doing things that
upset original authors, etc.
But Debian as a project is committed to Free Software. As a project
we do not restrain our contributors from annoying proprietary software
companies, or more generally from fully exercising[1] the legal
freedoms we have to deal in Free Software.
In other words: how much weight to give to the preferences of the
original copyright holders is a matter for the individual maintainers.
Ian.
[1] Of course we want to act consistently with our own values, such as
the Social Contract, the Diversity Statement, and so on. My claim is
that those values do not include refraining from exercising our rights
just because it would annoy proprietary software owners.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: anti-tarball clause and GPL
Simon McVittie writes ("Re: anti-tarball clause and GPL"):
> Are you asking this hypothetically, or is there a piece of software that
> someone intends to apply this to?
There are existing packages for which I consider the PFM to include
the git history. I'm not pressing this point from a legal point of
view because, well, that just generates lots of heat and no light.
I think that we should address this potential problem by arranging to
give to the history to our users and downstreams. There are lots of
other really good reasons to do this.
(ISTM that whether the PFM needs the upstream vcs history or not is a
question of fact which depends strongly on the context, how the thing
is developed, etc. I don't think a GPL rider like the one quoted
earlier is definitive either way - it's a statement of the author's
opinion and perhaps implies something about their practices.)
> Redistributing the entire history of a third-party project is practically
> problematic because it is no longer enough to check that there is nothing
> you don't want to distribute (e.g. non-free software) in the HEAD commit:
This boat already sailed a long time ago. Via alioth and now salsa,
and via the dgit git server, we are in many cases distributing that
complete history already.
> For established projects, the complete history is also inconveniently
> large: my git clone of glib2.0 has a 57M .git, which compares poorly
> with a 4.5M source tarball (and glib2.0 isn't even particularly big or
> old by the standards of projects like glibc and the Linux kernel).
Right. Bundling up git histories in tarballs is not a really sensible
way to carry on (unless trying to make a source CD for offline use or
something). Better to just have a git server, since then you only
need to keep one copy of the history, and in many cases clients can
only transfer updates.
> We have to draw a line somewhere. You could equally well say the software's
> bug tracking system and mailing lists, which also store human-readable
> comments, are part of the preferred form for modification - but those
> don't normally have any copyright license granted (I certainly didn't
> put this email under a copyright license!) so they are non-free.
So that interpretation of the PFM is not compatible with upstream's
practices.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: remote logo inclusion in package documentation
Paride Legovini writes ("remote logo inclusion in package documentation"):
> Hello debian-legal,
>
> The latest upstream version of a package I maintain (libmseed) ships
> with HTML documentation. The HTML documentation fetches a remote logo,
> and this triggered the privacy-breach-logo lintian tag [0].
>
> The logo is explicitly made available for usage by the institution
> developing the software [1], but I couldn't find its terms of use. The
> IRIS Wikipedia page includes the logo and lists it as CC BY-SA, but I'm
> not certain this information is correct.
>
> Do you think the HTML documentation fetching the IRIS logo can be
> included in Debian main?
No. The lintian warning is correct. Downloading logos in docs like
this is not only a privacy breach, but also a practical problem.
I have been on a train with no internet, trying to read some docs
which I had deliberately pre-installed, and found that each page would
take 30s to load because it had to wait for an attempted logo fetch to
time out.
If you can't establish that the logo is OK to include, you should
replace it.
In practice if you write an email to upstream they will probably
explicitly confirm the CC-BY-SA information from Wikimedia. Have you
tried that ?
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: GPL2 + required to have the place to get the recent version
Gunnar Wolf writes ("Re: GPL2 + required to have the place to get the recent
version"):
> I'm leaving aside the question that has been picked up, regarding
> whether this can be made under the GPLv2, or whether this is a
> "requirement" or a "polite request"...
>
> The requirement itself seems very similar to the "advertising clause"
> in the four-clause BSD license:
>
> https://lists.debian.org/debian-legal/2004/05/msg00753.html
> https://lists.debian.org/debian-legal/2004/04/msg00325.html
> https://www.gnu.org/licenses/bsd.html
>
> At that point, 4-clause BSD licenses were judged non-DFSG-free.
The 4-BSD advertising clause is worse than this requirement because:
* Instead of just saying where you got the program or where to get
recent versions, with 4-BSD you have to name all the contributors.
The list of contributors can be very long.
* Instead of just requiring the notice to "accompany" the software,
ie copies of the software have to have this additional notice, the
4-BSD requirement applies much more widely including to
advertising, blog postings, whatever.
I think the requirement at issue here is inoffensive, at least if we
read the legal text above.
But I don't understand why the authors consider it useful. The GPL2
requires you to give a lot of information about the original software.
It's not clear how much extra simply a link to the upstream helps.
However...
Samuel Henrique :
> > The release notes for 3.0. r5 also mentions:
> >
> > This program is licensed under GPL-2. Please note also that if
> > you're using the program for a paid or free public service you need
> > mention where you got this program from.
This suggests that the authors of this clause do not understand the
effect of their own legal wording. My reading of the legal wording
does not affect use. So it does not do what the release notes say.
To the original authors I would recommend AGPL3+.
If they don't want that then I think even if a clause could be drafted
which would have the effect they want (presumably, that described in
the release notes) it wouldn't be worth the licence incompatibility.
So if they don't want AGPL3+ they should probably use GPL2+.
I would recommend to them GPL2+ rather than GPL-v2-only for two
reasons:
- It makes it possible to upgrade the licence piecemeal to AGPL3+
later, because AGPL3+ and GPL2+ code can be mixed;
- GPL2's termination-for-fault clause is well known to be draconian.
Both GPL2+ and AGPL3+ are better choices than a custom clause because
they provide much better compatibility.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
