Re: 3 questions around source of GPL images
Ben Finney ben+deb...@benfinney.id.au writes: Thomas Preud'homme robo...@celest.fr writes: However opinions could diverge here and I think preferred form is not about a taste but about an absolute truth. I understand it as what is the easiest way to make modification. With the further caveats that forms of the work which no longer exist cannot qualify as “preffered form”, and non-software (i.e. not digital information) forms of the work cannot qualify. Don't get distracted by commonly-raised claims that some specific set of physical objects in front of a camera must be the “preferred form”. They're not software, and hence they don't get distributed in Debian. The caveat about existing is made because, even if someone might prefer it, it's not a form of the work since it no longer exists. The form of the work actually distributed as the “preferred form” must be a choice between options that actually exist. That latter paragraph is muddled. I'll try again: The caveat about existence is made because, even if someone describes some form of the work for making modifications and says that's what they prefer, if that form doesn't exist, it can't qualify as a “preferred form of the work”. The form of the work actually distributed as the “preferred form” must be chosen only from options that actually exist. -- \ “Don't be misled by the enormous flow of money into bad defacto | `\standards for unsophisticated buyers using poor adaptations of | _o__) incomplete ideas.” —Alan Kay | Ben Finney pgpUR1jTQYKNy.pgp Description: PGP signature
Re: 3 questions around source of GPL images
Le mardi 20 mars 2012 05:55:19, vous avez écrit : [SNIP] Is it supposed to be the preferred form for the author. If it's the user then it gets a bit complicated because it could vary from one user to another. Theoretically, it can vary. But in most cases it should be clear. For PNG files generated automatically from SVG, clearly the SVG is the preferred form of the work for making further modifications. In this case of course. But I checked quickly in oxygen-icons package and I didn't see a rule to construct the png from the svg (although I could just have missed it). It's just that there is a SVG with the same image as the png so one can assume that the SVG is that preferred form of modification. Whether he actually did modify them, a judgement needs to be made: for the software work that actually ends up in the binary package, what is the preferred form of that software (in this case, a graphic image file) for making modifications to it? If I were to decide the SVG would be the preferred form, even for image which were modified from the png. If you want to modify the text on an image for instance, it is much easier to do a sed on the SVG and the reapply whatever transformation the author did. However opinions could diverge here and I think preferred form is not about a taste but about an absolute truth. I understand it as what is the easiest way to make modification. With the further caveats that forms of the work which no longer exist cannot qualify as “preffered form”, and non-software (i.e. not digital information) forms of the work cannot qualify. Don't get distracted by commonly-raised claims that some specific set of physical objects in front of a camera must be the “preferred form”. They're not software, and hence they don't get distributed in Debian. The caveat about existing is made because, even if someone might prefer it, it's not a form of the work since it no longer exists. The form of the work actually distributed as the “preferred form” must be a choice between options that actually exist. I think I understand. Let me apply it to this situation to see if I understood correctly. 1) There is a file img1.png which has a source img1.svg 2) img2.png is made from img1.png It could be made more easily by creating an img2.svg from img1.svg and exporting it but since img2.svg do not exist and never existed the only source of img2.png is img2.png itself. Is it what the caveat means in this specific situation? I would say the SVG is the preferred form, even if upstream author didn't use it. It's only the preferred form *of the work* if it is actually the source form of *this work*, i.e. it includes all modifications or whatever automatic transformations are needed to achieve those modifications. If this work has diverged from some version of the SVG, then that SVG is no longer the source form of this work, and doesn't satisfy the source requirement of the GPL (nor of Debian). Ok. So the SVG are only the source for unmodified images. Got it. It's also the safest path as pointed out Simon McVittie. I will thus include the svg in addition of the png for the non modified files. I suspect the size increase should be quite minimal anyway. I agree with Paul Wise that it would be ideal to convince upstream to distribute the SVGs that directly correspond to the actual PNGs in the package, so they can more clearly be used as the source form of the work. I already discussed that with upstream. If SVGs don't make the tarball much bigger, he is OK to include them. Else, he will do a seperate tarball. The only difficulty is that he renamed the file he kept from the various icon packs and didn't note what image he used. So I'll have to find what images he kept from the icon packs and create a list of SVG that need to be included in consequences. I already started that work. Thanks for your help in clarifying the situation with regards the expression preferred form of modification. Best regards. signature.asc Description: This is a digitally signed message part.
Re: 3 questions around source of GPL images
Le mardi 20 mars 2012 14:39:14, Thomas Preud'homme a écrit : In this case of course. But I checked quickly in oxygen-icons package and I didn't see a rule to construct the png from the svg (although I could just have missed it). It's just that there is a SVG with the same image as the png so one can assume that the SVG is that preferred form of modification. I did missed it. There is an export_pngs.sh in the scalable directory. Regards. signature.asc Description: This is a digitally signed message part.
Re: 3 questions around source of GPL images
Thomas Preud'homme robo...@celest.fr writes: Le mardi 20 mars 2012 14:39:14, Thomas Preud'homme a écrit : But I checked quickly in oxygen-icons package and I didn't see a rule to construct the png from the svg (although I could just have missed it). I did missed it. There is an export_pngs.sh in the scalable directory. Great! That should make it rather easier to know which files to use as the source form: the SVG images, and all the scripts to transform those SVGs automatically into the corresponding PNGs. -- \ “A hundred times every day I remind myself that […] I must | `\ exert myself in order to give in the same measure as I have | _o__)received and am still receiving” —Albert Einstein | Ben Finney b...@benfinney.id.au pgpciRkldzz01.pgp Description: PGP signature
Re: 3 questions around source of GPL images
Le mardi 20 mars 2012 22:54:34, Ben Finney a écrit : Thomas Preud'homme robo...@celest.fr writes: Le mardi 20 mars 2012 14:39:14, Thomas Preud'homme a écrit : But I checked quickly in oxygen-icons package and I didn't see a rule to construct the png from the svg (although I could just have missed it). I did missed it. There is an export_pngs.sh in the scalable directory. Great! That should make it rather easier to know which files to use as the source form: the SVG images, and all the scripts to transform those SVGs automatically into the corresponding PNGs. Sorry, I was not specific enough. I was saying I didn't see the rule to build png from svg even in KDE oxygen-icon-theme. I just missed it, there is an export_png.sh For the package I'm interested it on the other hand there is nothing. Maybe a tool like fdupes could help me to find png in the package with similar checksum as png in oxygen-icon-theme package. If not, I'll have to do it by hand. It's probably what I'll do, as there is not so many files anyway. I already started today, it shouldn't be too long. Best regards. signature.asc Description: This is a digitally signed message part.
Re: 3 questions around source of GPL images
Le lundi 19 mars 2012 02:17:05, vous avez écrit : By the definition in the GPL (in GPLv3 §1, “the preferred form of the work for making modifications to it”), every work of software has a source form. So digital images are no exception. Totally agree. If the preferred form of a software work is the same as the one used directly by programs for displaying the image, then that doesn't change the fact that it's the source form of the work. Agree again but I have one question. Maybe the answer is obvious but who is to decide what is the preferred form? Is it supposed to be the preferred form for the author. If it's the user then it gets a bit complicated because it could vary from one user to another. If it is the developer, then the answer is simple. I never looked if there was any SVG. The images which were created were based on the png he got in the icon pack. However for the image he just included, the preferred form is SVG. From there, I have a few questions: * Should I include the SVG source in the package for the images he didn't modify? Whether he actually did modify them, a judgement needs to be made: for the software work that actually ends up in the binary package, what is the preferred form of that software (in this case, a graphic image file) for making modifications to it? If I were to decide the SVG would be the preferred form, even for image which were modified from the png. If you want to modify the text on an image for instance, it is much easier to do a sed on the SVG and the reapply whatever transformation the author did. However opinions could diverge here and I think preferred form is not about a taste but about an absolute truth. I understand it as what is the easiest way to make modification. If that's the SVG file, that's the source; if that's the PNG file, that's the source. I would say the SVG is the preferred form, even if upstream author didn't use it. It's also the safest path as pointed out Simon McVittie. I will thus include the svg in addition of the png for the non modified files. I suspect the size increase should be quite minimal anyway. * What about the image he modified? The source you need to include is the corresponding source form of the software. That is, the form of the software which a recipient can use to have exactly the same software, and make further modifications. Ok, definitely png then. That doesn't change simply because this work of software happens to be used as a graphic image. = My opinion is that since he based is work on the png, only the png need to be provided but I prefer to be safe than sorry, hence this question. I'm not clear on what software you have. But if you think of it in terms of “what is the source form of this software?” by the GPL definition, that would be informative, I think. * Some of the files with a SVG source come from KDE icon theme already packaged in the archive. Can I just add a comment in debian/copyright to say the SVG are in package X or do I have to copy the SVG in my own package? Each package in Debian must have the full source for that package in Debian. By “come from”, do you mean the exact corresponding source is already in another package? That would make it likely the “object form” (in GPL terminology) is also the same as that other software. Does your package declare a dependnecy on that other package? The icon in my package is the same as the icon in oxygen-icon-theme so yes they have the same source. I think it's better to include the source file, a dependency seems to me overkill. If by “come from” you mean “derived from” in the copyright sense of a creative transformation, then the original is no longer the corresponding source. You would need to include the corresponding source for this modified form, so a recipient has that source form if they want to make further modifications. Ok and as Simon McVittie said, declaring whatever dependency would maintain this version of the package in the archive even if my package is the only user. I will thus copy the SVG in the source package. = Since Debian distribute the source for both package X (the KDE icon theme) and my package, I'd say the image are correctly acompanied with the source (both are in Debian archive) as per GPL-2 3.a) or GPL-3 6.d (If the place to copy the object code is a network server, the Corresponding Source may be on a different server). Only if it truly is the corresponding source form of *this particular* software, including all modifications. If there are modifications from the other package, then that package's source is no longer the corresponding source form for this software. Thanks for taking the time to read thus far. I'm waiting your answer to enlighten me as to what I should do to respect all the license and DFSG requirements. Thank you for taking the time to treat this issue seriously. Thanks
Re: 3 questions around source of GPL images
While I think other folks in this thread have covered your question, I would like to request that you ask upstream to choose a more appropriate source form. For eg one wouldn't take a copy of /bin/ls and modify it, one would take a copy of the source code for /bin/ls, modify it and produce a new /bin/ls at build time. Similarly, they could be modifying SVG images and rendering the PNG images at build time using rsvg-convert or inkscape. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EpjgUW6G=alx-uum8qggyzan+xhesau69ueghvpdo...@mail.gmail.com
Re: 3 questions around source of GPL images
Thomas Preud'homme robo...@celest.fr writes: Le lundi 19 mars 2012 02:17:05, vous avez écrit : If the preferred form of a software work is the same as the one used directly by programs for displaying the image, then that doesn't change the fact that it's the source form of the work. Agree again but I have one question. Maybe the answer is obvious but who is to decide what is the preferred form? Ultimately, a judge would decide in a court case. Is it supposed to be the preferred form for the author. If it's the user then it gets a bit complicated because it could vary from one user to another. Theoretically, it can vary. But in most cases it should be clear. For PNG files generated automatically from SVG, clearly the SVG is the preferred form of the work for making further modifications. Whether he actually did modify them, a judgement needs to be made: for the software work that actually ends up in the binary package, what is the preferred form of that software (in this case, a graphic image file) for making modifications to it? If I were to decide the SVG would be the preferred form, even for image which were modified from the png. If you want to modify the text on an image for instance, it is much easier to do a sed on the SVG and the reapply whatever transformation the author did. However opinions could diverge here and I think preferred form is not about a taste but about an absolute truth. I understand it as what is the easiest way to make modification. With the further caveats that forms of the work which no longer exist cannot qualify as “preffered form”, and non-software (i.e. not digital information) forms of the work cannot qualify. Don't get distracted by commonly-raised claims that some specific set of physical objects in front of a camera must be the “preferred form”. They're not software, and hence they don't get distributed in Debian. The caveat about existing is made because, even if someone might prefer it, it's not a form of the work since it no longer exists. The form of the work actually distributed as the “preferred form” must be a choice between options that actually exist. I would say the SVG is the preferred form, even if upstream author didn't use it. It's only the preferred form *of the work* if it is actually the source form of *this work*, i.e. it includes all modifications or whatever automatic transformations are needed to achieve those modifications. If this work has diverged from some version of the SVG, then that SVG is no longer the source form of this work, and doesn't satisfy the source requirement of the GPL (nor of Debian). It's also the safest path as pointed out Simon McVittie. I will thus include the svg in addition of the png for the non modified files. I suspect the size increase should be quite minimal anyway. I agree with Paul Wise that it would be ideal to convince upstream to distribute the SVGs that directly correspond to the actual PNGs in the package, so they can more clearly be used as the source form of the work. -- \“Your [government] representative owes you, not his industry | `\ only, but his judgment; and he betrays, instead of serving you, | _o__)if he sacrifices it to your opinion.” —Edmund Burke, 1774 | Ben Finney b...@benfinney.id.au pgptS8U9wJWhE.pgp Description: PGP signature
3 questions around source of GPL images
Greetings everyone, [Please CC me as I'm not subscribed to the list.] one of the software I maintain contains several sets of images to change the theme/appearance of the software. Most images don't really have a source (they were done directly as png as far as I understand). However, a few themes comes from icon packs under GPL license whose icons have a SVG source. The situation is complicated because there is more image in the theme than in the original pack. The author took the *png* image from the pack and created some new image out of it (by removing the color or applying a color filter for example). What happened is that he downloaded the pack without the SVG source files. From there, I have a few questions: * Should I include the SVG source in the package for the images he didn't modify? * What about the image he modified? = My opinion is that since he based is work on the png, only the png need to be provided but I prefer to be safe than sorry, hence this question. * Some of the files with a SVG source come from KDE icon theme already packaged in the archive. Can I just add a comment in debian/copyright to say the SVG are in package X or do I have to copy the SVG in my own package? = Since Debian distribute the source for both package X (the KDE icon theme) and my package, I'd say the image are correctly acompanied with the source (both are in Debian archive) as per GPL-2 3.a) or GPL-3 6.d (If the place to copy the object code is a network server, the Corresponding Source may be on a different server). Thanks for taking the time to read thus far. I'm waiting your answer to enlighten me as to what I should do to respect all the license and DFSG requirements. Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part.
Re: 3 questions around source of GPL images
I have no opinion on whether the SVG files are required by the GPL/DFSG, or just count as an older version of the preferred form for modification in this case. Defining the preferred form for modification for non-programs gets a bit vague... If it's easy to find the corresponding SVGs, the safe option is to add them to the source package, and stop caring about whether the license required you to do so or you're just being helpful. If they *are* required by the GPL/DFSG, then you can't rely on another package to provide them without a dependency relationship: On 18/03/12 23:48, Thomas Preud'homme wrote: = Since Debian distribute the source for both package X (the KDE icon theme) and my package, I'd say the image are correctly acompanied with the source (both are in Debian archive) as per GPL-2 3.a) or GPL-3 6.d (If the place to copy the object code is a network server, the Corresponding Source may be on a different server). From a purely practical point of view, this is not guaranteed to remain true: packages, and specific package versions, get removed from the archive regularly. The KDE icon theme will hopefully never get removed, but the specific version from which your package is derived will disappear eventually. If your package needs to keep another source package in the archive in order to comply with the GPL (e.g. binutils-mingw-64 needs to keep its corresponding binutils in the archive), that's what the Built-Using field is for - but in this case that isn't really appropriate (it'd keep a particular version of the KDE icon theme in the archive indefinitely). S -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f667cc7.1020...@debian.org
Re: 3 questions around source of GPL images
Thomas Preud'homme robo...@celest.fr writes: [Please CC me as I'm not subscribed to the list.] Done. Most images don't really have a source (they were done directly as png as far as I understand). However, a few themes comes from icon packs under GPL license whose icons have a SVG source. By the definition in the GPL (in GPLv3 §1, “the preferred form of the work for making modifications to it”), every work of software has a source form. So digital images are no exception. If the preferred form of a software work is the same as the one used directly by programs for displaying the image, then that doesn't change the fact that it's the source form of the work. From there, I have a few questions: * Should I include the SVG source in the package for the images he didn't modify? Whether he actually did modify them, a judgement needs to be made: for the software work that actually ends up in the binary package, what is the preferred form of that software (in this case, a graphic image file) for making modifications to it? If that's the SVG file, that's the source; if that's the PNG file, that's the source. * What about the image he modified? The source you need to include is the corresponding source form of the software. That is, the form of the software which a recipient can use to have exactly the same software, and make further modifications. That doesn't change simply because this work of software happens to be used as a graphic image. = My opinion is that since he based is work on the png, only the png need to be provided but I prefer to be safe than sorry, hence this question. I'm not clear on what software you have. But if you think of it in terms of “what is the source form of this software?” by the GPL definition, that would be informative, I think. * Some of the files with a SVG source come from KDE icon theme already packaged in the archive. Can I just add a comment in debian/copyright to say the SVG are in package X or do I have to copy the SVG in my own package? Each package in Debian must have the full source for that package in Debian. By “come from”, do you mean the exact corresponding source is already in another package? That would make it likely the “object form” (in GPL terminology) is also the same as that other software. Does your package declare a dependnecy on that other package? If by “come from” you mean “derived from” in the copyright sense of a creative transformation, then the original is no longer the corresponding source. You would need to include the corresponding source for this modified form, so a recipient has that source form if they want to make further modifications. = Since Debian distribute the source for both package X (the KDE icon theme) and my package, I'd say the image are correctly acompanied with the source (both are in Debian archive) as per GPL-2 3.a) or GPL-3 6.d (If the place to copy the object code is a network server, the Corresponding Source may be on a different server). Only if it truly is the corresponding source form of *this particular* software, including all modifications. If there are modifications from the other package, then that package's source is no longer the corresponding source form for this software. Thanks for taking the time to read thus far. I'm waiting your answer to enlighten me as to what I should do to respect all the license and DFSG requirements. Thank you for taking the time to treat this issue seriously. -- \ “I must say that I find television very educational. The minute | `\ somebody turns it on, I go to the library and read a book.” | _o__)—Groucho Marx | Ben Finney b...@benfinney.id.au pgpGaYYgbNZm4.pgp Description: PGP signature
