Hello,
On Wed, Aug 31, 2016 at 08:07:52PM +0800, Boyuan Yang wrote:
> 2016-08-25 5:41 GMT+08:00 Sean Whitton <spwhitton@spwhitton.name>:
> > You claim that the upstream files are only licensed under the GPL
> > version 2 (and no later version). But looking at the headers of the .h
> > and .cpp files, the upstream author licenses them as GPL-2+. However,
> > EnCrypt.java is just GPL-2 with no later version.
>
> Fixed in the copyright file.
>
> Upstream said the entire project is released under GPL-2, but some certain files
> are released under GPL-2+. So I am writing that "Files: *" is under GPL-2 and
> listed those files to be under GPL-2+.
Okay. Optionally, you can wrap the lines to make them it more readable, e.g.
Files: application.h
application.cpp
global.cpp
And I think you could use e.g. global.* instead of listing both of them,
if you want to (definitely not required).
> Personally I have one question: Now that upstream said some files are
> released under GPL-2+, is it reasonable for the Debian package to
> choose only the GPL-2 license to republish?
That would meet the DFSG, but it wouldn't be serving our users'
interests: we'd be neglecting to inform them that they can re-use the
files under GPL-3 or later if they wanted to.
> > The copyright status of the images/ subdirectory is also unclear.
>
> Besides the purple-theme directory (as stated below), I am willing to believe
> that those files are released under GPL-2 as stated by the Nixnote2 author.
Have you tried e-mailing the author? I agree that it would be
reasonable to assume that they are GPL-2 if he doesn't reply.
> > The address of the FSF offices in screencapture.cpp is not correct. It
> > would be best to patch it and submit that upstream. Similarly
> > screencapture.h.
>
> Patch sent to upstream as PR (https://github.com/baumgarr/nixnote2/pull/200).
> Not accepted yet, but I put it inside debian/patches for now.
> The patch will be removed after the PR is merged.
You should add a "Forwarded: https://github.com/baumgarr/nixnote2/pull/200";
patch header.
> > The copyright status of faderdialog.{cpp,h} needs looking at -- the
> > files claim they were taken from some web forum!
>
> Good news: as stated in the forum rule http://www.qtcentre.org/rules/:
>
> "Unless stated otherwise by the author all code published on this site is
> public domain and can be used by anyone for anything without any affiliation
> to the original author."
>
> No statement was found in the related post, so I have updated the copyright
> file as public-domain.
Great! That was a lot easier than it might have been!
> > The qevercloud/ dir seems to be an embedded code copy of ...
>
> OK. Here comes the tough part.
>
> In short: Nixnote2 upstream said he/she is forking and maintaining the
> embedded code, qevercloud original upstream dead, no need to worry.
>
> A slightly long story: https://github.com/baumgarr/nixnote2/issues/187
>
> Someone is picking up and forking the project. The qevercloud library
> was not made into shared library before (in 2.x series). The new forker
> is releasing 3.x releases with shared library support. However, the author
> of Nixnote2 is not willing to use the forked codes now.
>
> I made some investigations and find that the code for Nixnote2 needs
> slight modifications to use qevercloud 3.x. So far I have tried to pack
> libqevercloud* as debian package and some result can be found on
> GitHub (https://github.com/hosiet/qevercloud), but I am not going to
> file ITP/RFS until upstream agrees to adapt QEvercloud 3.x branch.
Thanks for the the explanation and the link to the GitHub thread.
The issue here is no longer about copyright or licensing: it's about the
fact that qevercloud should be packaged as a shared library. The reason
for this is that it is clear qevercloud 3.x's author intends for
qevercloud to be a general-purpose library that different third-party
applications can link with. If we were to upload nixnote with an
embedded copy, we wouldn't be making qevercloud's full potential
available to Debian users and other packagers.
You've worked really hard on nixnote's packaging and so I hope you don't
feel too disappointed about this delay -- I think that we can still get
both nixnote and qevercloud in before the stretch freeze.
I suggest that you work with the qevercloud author to get qevercloud
into Debian as a proper shared library. It sounds like he's already
done most of the work. And it sounds like the nixnote author would be
willing to make the necessary modifications once this has been done.
> > ... generated cpp source files in qevercloud ...
>
> That is generated from Evernote Cloud API Thrift IDL files [1], an abstract
> description of Evernote Cloud API, and generated files should be considered
> as part of the source code. It is barely impossible and does not make sense
> to regenerate those files.
>
> [1] https://github.com/evernote/evernote-thrift , some more stories in
> https://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/ .
From the links you've provided, it seems that the Evernote *.thrift
files ought to be packaged as a build-dependency which are then used to
generate the *.cpp files when the package is build.
If it's impossible to regenerate them, arguably we wouldn't be shipping
the full source code to qevercloud. Opinions in Debian diverge here,
though. You might consider asking on debian-devel@lists.debian.org for
anyone else who has dealt with files generated from *.thrift files in
their packaging work.
> > There's a further issue with at least some of the files in images/.
> > The check-all-the-things tool reveals:
> >
> > # Check with upstream where the GIMP XCF source files are.
> > $ find -type f \( -iname '*.png' -o -iname '*.gif' -o -iname '*.jpg' -o -iname '*.jpeg' \) -exec grep -iF gimp {} +
> > Binary file ./images/purple-theme/synchronize.png matches
> >
> > i.e. images/purple-theme/synchronize.png was probably created with the
> > GIMP. That means the preferred format for modifying this file is
> > probably a *.svg file. Similarly, the other files in the theme might
> > have been prepared with a tool that works with *.svg files and exports
> > to *.png.
> >
> > In order to satisfy DFSG (and indeed the GPL), the *.svg files need to
> > be included in the source package.
>
> Upstream gives no response, and I am patching to move the entire purple
> theme away from the source code for now.
>
> Issue sent (https://github.com/baumgarr/nixnote2/issues/201).
As well as removing the theme files from the tarball using
"Files-Excluded:", you seem to have edited theme.ini. It would be
better not to edit theme.ini in the tarball and instead use a quilt
patch, since it's a Debian-specific change. The reason for this is that
it allows you to explain what's going on in a patch header, so others
can see why the purple theme was removed.
> > I think you need to patch readme.txt to remove reference to installation
> > instructions, since (rightly) you're not installing install.txt and
> > Readme_Arch_Linux.txt.
>
> Patch added.
>
> Not sending patch to upstream, since it is merely a debian-package issue.
You should add a "Forwarded: not-needed" patch header.
> > Finally, it seems that spellchecker.cpp hardcodes paths to
> > OpenOffice dictionaries in /opt. They're not installed to /opt on
> > Debian. And maybe you need a dependency on libreoffice.
>
> The software already has a dependency to libhunspell to provide spell checking
> feature with top priority as stated in the source code. I believe
> those legacy paths
> of OO.o should not cause problems if they still exist in the source code.
>
> Libreoffice is not needed as well, according to the author [2]. So I
> am not intended
> to fix it.
>
> [2] https://github.com/baumgarr/nixnote2/issues/183#issuecomment-234800970
That sounds fine, but it would be a good idea to put this information in
README.source. Someone else might notice the /opt references and wonder
why they exist in a Debian package.
> OK. Now I believe all copyright-related issues are fixed or explained by now.
> The GitHub repository is updated and the new version has been uploaded onto
> mentors.debian.net/package/nixnote2.
Thanks again for your efforts.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature