Discussion:
dual licensed + build generated png (GPL-2+ or CC-BY-SA-4.0+)
(too old to reply)
Samuel Henrique
2018-09-14 06:30:25 UTC
Permalink
Hello,
I'm currently doing a review of a package Franciscarlos sent to me,
and I stumbled upon an interesting case which I would like to ask
advise about on this list.

The package in question is adapta-gtk-theme[0], tools like
licensecheck generate d/copyright as:
License: GPL-2+ or CC-BY-SA-4.0+

Looking at the files of the software, Example of that is that some
files like .sh ones are GPL-2+ and some .svg are CC-BY-SA-4.0+.

I'm assuming this can be solved by:

Files: *
Copyright: YEARS NAME
License: GPL-2+

Files: *.svg
Copyright: YEARS NAME
License: CC-BY-SA-4.0+

Although part of the build process consists of generating some png
files from the svg ones, and by using the above I would be licensing
them as GPL-2+, so...

Files: *
Copyright: YEARS NAME
License: GPL-2+

Files: *.svg *.png
Copyright: YEARS NAME
License: CC-BY-SA-4.0+

Should be able to do it, right? I'm not sure about the multiple
entries on the Files, I can't see a mention of that in DEP3[1].

Considering that the d/copyright above is ok, there's still one thing
missing, upstream don't explicitly mentions any license for png files,
so am I correct that as long as we respect the svg license, we can
chose the one we want to for the pngs and upstream doesn't have to
care about that? And in that case, the license would obviously be the
same as of the svg.

Oh, there is another thing, upstream does not mention its name on any
of the svg files, it don't even mention the proper license on the
file[2], the only place where there's [kinda] clearly attribution of
license to svg files is on the README.md[3].

Considering only this aspect, I would like advice on what I should
suggest upstream to change in order to explicitly license its svgs (I
would be glad to see examples on other softwares), it looks like
upstream could be using other RDF fields on the svg for that[4].

And now considering that upstream still didn't made this changes, I
could upload the package to Debian, right? I understand that the
license could be more explicit but having it that way on README.md and
on the other files seems like enough for a first upload, what do you
think?

[0]https://salsa.debian.org/debian/adapta-gtk-theme
[1]https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field
[2]https://salsa.debian.org/debian/adapta-gtk-theme/blob/6aa1f96171de5c8a3a45795c5153ade4e995a3fa/wm/asset/assets-xfwm/hide-inactive.svg#L6
[3]https://salsa.debian.org/debian/adapta-gtk-theme/blob/6aa1f96171de5c8a3a45795c5153ade4e995a3fa/README.md#L355
[4]https://creativecommons.org/ns#

Regards,
--
Samuel Henrique <samueloph>
Paul Wise
2018-09-15 01:15:16 UTC
Permalink
Post by Samuel Henrique
Looking at the files of the software, Example of that is that some
files like .sh ones are GPL-2+ and some .svg are CC-BY-SA-4.0+.
Files: *
Copyright: YEARS NAME
License: GPL-2+
Files: *.svg
Copyright: YEARS NAME
License: CC-BY-SA-4.0+
Correct.
Post by Samuel Henrique
Although part of the build process consists of generating some png
files from the svg ones, and by using the above I would be licensing
them as GPL-2+, so...
debian/copyright only documents the license of the source, not any
license for build products. If you want to document the license for
the contents of the binary package, you can add a
debian/foobinpkg.copyright that represents the built binary package.
There are no standards in Debian for what binary package
copyright/license information should look like. Generally Debian does
not care about accurately representing the copyright information for
binary packages and just copies the source package copyright file into
the binary package.
Post by Samuel Henrique
Considering that the d/copyright above is ok, there's still one thing
missing, upstream don't explicitly mentions any license for png files,
so am I correct that as long as we respect the svg license, we can
chose the one we want to for the pngs and upstream doesn't have to
care about that? And in that case, the license would obviously be the
same as of the svg.
I assume that the png files are the result of mechanical conversion
from svg. If so the SVG copyright holders and license are transferred
to the PNG files. So the SVG and PNG files are CC-BY-SA-4.0+ and IIRC
CC-SA licenses do not allow relicensing (similar to the GPL).
Post by Samuel Henrique
Oh, there is another thing, upstream does not mention its name on any
of the svg files, it don't even mention the proper license on the
file[2], the only place where there's [kinda] clearly attribution of
license to svg files is on the README.md[3].
This is not true. I only looked at one file and found a license declaration:

<cc:Work
rdf:about="">
...
<cc:license
rdf:resource="http://creativecommons.org/licenses/by-sa/4.0/" />
</cc:Work>

https://salsa.debian.org/debian/adapta-gtk-theme/raw/6aa1f96171de5c8a3a45795c5153ade4e995a3fa/wm/asset/assets-metacity/button_close.svg
Post by Samuel Henrique
Considering only this aspect, I would like advice on what I should
suggest upstream to change in order to explicitly license its svgs (I
would be glad to see examples on other softwares), it looks like
upstream could be using other RDF fields on the svg for that[4].
They seem to be using that RDF for the SVG you linked to:

<cc:Work
rdf:about="">
...
<cc:license
rdf:resource="http://creativecommons.org/licenses/by-sa/4.0/"
/>https://creativecommons.org/choose/#metadata
</cc:Work>

https://salsa.debian.org/debian/adapta-gtk-theme/raw/6aa1f96171de5c8a3a45795c5153ade4e995a3fa/wm/asset/assets-xfwm/hide-inactive.svg
Post by Samuel Henrique
And now considering that upstream still didn't made this changes, I
could upload the package to Debian, right? I understand that the
license could be more explicit but having it that way on README.md and
on the other files seems like enough for a first upload, what do you
think?
I think that if the RDF license information mentioned above was
actually missing and you made sure to comment on that and the note in
the README in debian/copyright, ftp-master would probably accept it.
--
bye,
pabs

https://wiki.debian.org/PaulWise
Samuel Henrique
2018-10-03 16:30:16 UTC
Permalink
Hello Paul,

Thank you for answering, we managed to do a correct d/copyright and I
just uploaded to NEW.
--
Samuel Henrique <samueloph>
Loading...