Re: dual licensed + build generated png (GPL-2+ or CC-BY-SA-4.0+)
On Fri, Sep 14, 2018 at 2:30 PM, Samuel Henrique wrote:
> 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+
Correct.
> 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.
> 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).
> 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
> 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
> 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
Reply to: