Whilst browsing over the QI candidates page I noticed this image: http://commons.wikimedia.org/wiki/Image:EM_Spectrum_Properties.svg. The image itself is licensed as public domain. However it is a derivative of two images licensed under the GFDL (http://commons.wikimedia.org/wiki/Image:P_biology.svg and http://commons.wikimedia.org/wiki/Image:Skyscrapercompare.svg). Unless I am misreading something quite badly, releasing a derivative of a GFDL-licensed work to the public domain is a violation of the GFDL.
It is easy to fix one image, but I suspect we have deeper problems throughout the project with a lack of respect for copyleft. Establishing just how serious this issue is will be non-trivial, never mind resolving it.
I can think of a number of approaches to this situation, some of which are obviously harmful to the project and/or the free content movement as a whole. * Ignore the terms of the GFDL (or any other copyleft licenses) in this context. * Treat them the same as any other copyright violation. * Contact the creator of the derivative and inform him of the pertinent terms of the original license; and ask him to change the licensing on the derivative. * Changing the licensing on the derivative work to be compatible with the original work, and inform the creator of the new work of the change and the reason why.
Furthermore we probably have the difficulties associated with of a CC-BY-SA work and a GFDL work being combined. I'm no lawyer, but I suspect to truly sort these cases out will need an additional release from some of the creators of the original works.
If we cannot enforce the copyleft terms on our own community, can we really expect external groups to?
On 10/25/07, Nilfanion nilfanion@googlemail.com wrote:
- Contact the creator of the derivative and inform him of the
pertinent terms of the original license; and ask him to change the licensing on the derivative.
That would be the best thing to do
- Changing the licensing on the derivative work to be compatible with
the original work, and inform the creator of the new work of the change and the reason why.
You can't legally do that. If you release a derivative work of a GFDL work under something different than the GFDL, you violate the terms of the license and your license terminates. So you commit copyright infringement. It does nto mean that your derivative automatically becomes GFDL. IANAL.
Bryan
2007/10/25, Bryan Tong Minh bryan.tongminh@gmail.com:
- Changing the licensing on the derivative work to be compatible with
the original work, and inform the creator of the new work of the change and the reason why.
You can't legally do that. If you release a derivative work of a GFDL work under something different than the GFDL, you violate the terms of the license and your license terminates. So you commit copyright infringement. It does nto mean that your derivative automatically becomes GFDL. IANAL.
Actually, in this case I think we can - by stating it's public domain, the creator of the derived image is reneging on their copyright on the work. It is perfectly allowed to publish a public domain work under the GFDL (although it is not effective, because being in the public domain, people can copy it anyway). It would be different if they had put another license on it, but if they put it under PD or copyrightedfreeuse, I think putting it back under the GFDL would be unproblematic.
On 10/25/07, Andre Engels andreengels@gmail.com wrote:
2007/10/25, Bryan Tong Minh bryan.tongminh@gmail.com:
- Changing the licensing on the derivative work to be compatible with
the original work, and inform the creator of the new work of the change and the reason why.
You can't legally do that. If you release a derivative work of a GFDL work under something different than the GFDL, you violate the terms of the license and your license terminates. So you commit copyright infringement. It does nto mean that your derivative automatically becomes GFDL. IANAL.
Actually, in this case I think we can - by stating it's public domain, the creator of the derived image is reneging on their copyright on the work. It is perfectly allowed to publish a public domain work under the GFDL (although it is not effective, because being in the public domain, people can copy it anyway). It would be different if they had put another license on it, but if they put it under PD or copyrightedfreeuse, I think putting it back under the GFDL would be unproblematic.
Putting it back under GFDL is not the issue. Releasing GFDL content as public domain is.
The GPL (and the GFDL) werde designed to prevent incorporation into proprietary software (or texts). Putting GFDLd data into PD would allow for that.
I think there is one exception: If the new work is large enough, compared to the GFDLd part, the work can be released under any license (or as PD) as long as the GFDL parts are marked as such (and the license included, authors named etc.)
I doubt that's the case here, though.
Magnus
2007/10/25, Magnus Manske magnusmanske@googlemail.com:
Putting it back under GFDL is not the issue. Releasing GFDL content as public domain is.
True, but if we republish the new content, for which public domain is claimed, under the GFDL, there is no 'releasing GFDL content as public domain'. There are two copyright issues here: the original GFDL work and the changes from the original to the derived work. The first part is allowed to be copied under the GFDL (including derivative works), the second is allowed to be copied in any way whatsoever. Thus, copying the resulting whole under the GFDL breaks copyright of neither.
On 10/25/07, Andre Engels andreengels@gmail.com wrote:
2007/10/25, Magnus Manske magnusmanske@googlemail.com:
Putting it back under GFDL is not the issue. Releasing GFDL content as public domain is.
True, but if we republish the new content, for which public domain is claimed, under the GFDL, there is no 'releasing GFDL content as public domain'. There are two copyright issues here: the original GFDL work and the changes from the original to the derived work. The first part is allowed to be copied under the GFDL (including derivative works), the second is allowed to be copied in any way whatsoever. Thus, copying the resulting whole under the GFDL breaks copyright of neither.
Maybe you (or I) misunderstand. I'm saying that the entire new work has to be released under GFDL, and not as PD, because it is a derivative work of GFDL data.
Magnus
2007/10/25, Magnus Manske magnusmanske@googlemail.com:
Maybe you (or I) misunderstand. I'm saying that the entire new work has to be released under GFDL, and not as PD, because it is a derivative work of GFDL data.
Yeah, either you misunderstood me or I misunderstood you, but in effect we seem to be arguing the same case.
Just to note that the specific image I cited at the start of this thread has been fixed now. I think it would be helpful if we could have a scrape of links between images to see if there are any other blatant violations.
On 26/10/2007, Andre Engels andreengels@gmail.com wrote:
2007/10/25, Magnus Manske magnusmanske@googlemail.com:
Maybe you (or I) misunderstand. I'm saying that the entire new work has to be released under GFDL, and not as PD, because it is a derivative work of GFDL data.
Yeah, either you misunderstood me or I misunderstood you, but in effect we seem to be arguing the same case.
-- Andre Engels, andreengels@gmail.com ICQ: 6260644 -- Skype: a_engels
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
Nilfanion
On 25/10/2007, Nilfanion nilfanion@googlemail.com wrote:
It is easy to fix one image, but I suspect we have deeper problems throughout the project with a lack of respect for copyleft. Establishing just how serious this issue is will be non-trivial, never mind resolving it.
I don't think this is a lack of respect for copyleft, per se, so much as a fundamental misunderstanding as to what a derivative work is - people not realising that making a changed version of something doesn't wipe the existing rights in it. We get this problem whether the original works are free or unfree...
I actually was thinking of this today when I was creating several "world membership maps" and realized that the only way to indicate that I was creating a derivative work of the previous blank map was to link to it - and that the only way to check what derivative works have been made from a Commons file is to use "what links here".
It seems to me a great first step to solving this problem is having an option at [[Commons:Upload]] page like "It is a derivative work of a media file already on the Commons" (perhaps also explaining what qualifies as a derivative work). This would allow (1) automatically insert some kind of template designed to indicate and keep track of derivative works, should one be made and more importantly (2) automatically check that the newly uploaded work is under the appropriate license - preventing someone from licensing a derivative of a GFDL file as CC-BY-SA or PD, etc. I have no technical knowledge in this area but that seems possible.
Just my two cents...first time poster. Padraic http://commons.wikimedia.org/wiki/User:Padraic
On 25/10/2007, Andrew Gray shimgray@gmail.com wrote:
On 25/10/2007, Nilfanion nilfanion@googlemail.com wrote:
It is easy to fix one image, but I suspect we have deeper problems throughout the project with a lack of respect for copyleft. Establishing just how serious this issue is will be non-trivial, never mind resolving it.
I don't think this is a lack of respect for copyleft, per se, so much as a fundamental misunderstanding as to what a derivative work is - people not realising that making a changed version of something doesn't wipe the existing rights in it. We get this problem whether the original works are free or unfree...
--
- Andrew Gray andrew.gray@dunelm.org.uk
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
On 25/10/2007, Padraic Ryan padraic.j.ryan@gmail.com wrote:
It seems to me a great first step to solving this problem is having an option at [[Commons:Upload]] page like "It is a derivative work of a media file already on the Commons" (perhaps also explaining what qualifies as a derivative work). This would allow (1) automatically insert some kind of template designed to indicate and keep track of derivative works, should one be made and more importantly (2) automatically check that the newly uploaded work is under the appropriate license - preventing someone from licensing a derivative of a GFDL file as CC-BY-SA or PD, etc. I have no technical knowledge in this area but that seems possible.
That sounds like precisely what we need. (Optional extension to allow naming more than one source file. Source can be on Commons, on another Wikimedia project, on the web or described in text.) This will also encourage a culture of reuse.
Bugzilla feature request, anyone? Writeup of request for wikitech-l?
- d.
On Thu, 2007-10-25 at 14:15 +0100, David Gerard wrote:
On 25/10/2007, Padraic Ryan padraic.j.ryan@gmail.com wrote:
It seems to me a great first step to solving this problem is having an option at [[Commons:Upload]] page like "It is a derivative work of a media file already on the Commons" (perhaps also explaining what qualifies as a derivative work). This would allow (1) automatically insert some kind of template designed to indicate and keep track of derivative works, should one be made and more importantly (2) automatically check that the newly uploaded work is under the appropriate license - preventing someone from licensing a derivative of a GFDL file as CC-BY-SA or PD, etc. I have no technical knowledge in this area but that seems possible.
That sounds like precisely what we need. (Optional extension to allow naming more than one source file. Source can be on Commons, on another Wikimedia project, on the web or described in text.) This will also encourage a culture of reuse.
Bugzilla feature request, anyone? Writeup of request for wikitech-l?
I don't see that anyone wrote this up or submitted a feature request, so I'm volunteering to (demonstrating and encouraging reuse is high priority for Creative Commons, eg, that's why we created ccmixter.org, but that's just an aside).
First, let me see if I understand the ideal way to surface this. I imagine one of these:
A)
On http://commons.wikimedia.org/wiki/Commons:Upload a new "Where is this work from?" option "Derived from one or more existing works"
On something like http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=de...
a field for the URL of work derived from, with (+) for adding multiple URLs if derived from more than one work.
These fields are added to the upload's article via a template, as licensing info already is.
B)
Nothing new on [[Commons:Upload]], but expandable URL-of-work-derived from field appears on [[Special:Upload]] always(?), much like the licensing drop-down seems to. As above, added to upload's article via template.
Is just the URL of the source work(s) good enough? Is it reasonable to suggest that the upload process attempt to scrape some info from provided URLs? This would presumably be required for part (2) of Padraic's suggestion.
On 26/11/2007, Mike Linksvayer ml@creativecommons.org wrote:
On Thu, 2007-10-25 at 14:15 +0100, David Gerard wrote:
On 25/10/2007, Padraic Ryan padraic.j.ryan@gmail.com wrote:
It seems to me a great first step to solving this problem is having an option at [[Commons:Upload]] page like "It is a derivative work of a media file already on the Commons" (perhaps also explaining what qualifies as a derivative work). This would allow (1) automatically insert some kind of template designed to indicate and keep track of derivative works, should one be made and more importantly (2) automatically check that the newly uploaded work is under the appropriate license - preventing someone from licensing a derivative of a GFDL file as CC-BY-SA or PD, etc. I have no technical knowledge in this area but that seems possible.
That sounds like precisely what we need. (Optional extension to allow naming more than one source file. Source can be on Commons, on another Wikimedia project, on the web or described in text.) This will also encourage a culture of reuse.
Bugzilla feature request, anyone? Writeup of request for wikitech-l?
I don't see that anyone wrote this up or submitted a feature request, so I'm volunteering to (demonstrating and encouraging reuse is high priority for Creative Commons, eg, that's why we created ccmixter.org, but that's just an aside).
First, let me see if I understand the ideal way to surface this. I imagine one of these:
A)
On http://commons.wikimedia.org/wiki/Commons:Upload a new "Where is this work from?" option "Derived from one or more existing works"
On something like http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=de...
a field for the URL of work derived from, with (+) for adding multiple URLs if derived from more than one work.
These fields are added to the upload's article via a template, as licensing info already is.
We are able to do quite a bit in terms of customisation without making a "feature request" on bugzilla for new functionality (which I don't recommend if you want to see it in action before 2010).
I started creating the messages necessary for a new option on Commons:Upload, see http://commons.wikimedia.org/wiki/MediaWiki:Uploadtext/commonsderivative
but I stopped because I don't know what else is important to mention...
(only admins can edit that page, but please put suggested text on the talk page and it will be copied over)
there is a tool called "Reworkhelper" which we could tell people as use http://tools.wikimedia.de/~luxo/reworkhelper/?lang=en just as we tell people to use CommonsHelper and FLinfo, however I find Reworkhelper has a very confusing interface. If someone could work with Luxo to improve it that would be good. Someone who regularly uploads derivs and has an idea of what info needs to be checked, would be good.
So basically 1) we have an option on Commons:Upload that is like 'Derivative of existing Commons work' then 2) that option directs them to a toolserver tool that gets all the required info and does some machine checks like "does source image exist, and not have deletion templates on it", and copies source license, author info and link (in {{information}} Source field?)
cheers Brianna
On Mon, 2007-11-26 at 11:52 +1100, Brianna Laugher wrote:
I started creating the messages necessary for a new option on Commons:Upload, see http://commons.wikimedia.org/wiki/MediaWiki:Uploadtext/commonsderivative
but I stopped because I don't know what else is important to mention...
Should it still be noted that the uploaded derivative can only incorporate your original work in addition to the source work already on the site? There are lots of ways one can make a derivative work that aren't simple operations on the source work.
(only admins can edit that page, but please put suggested text on the talk page and it will be copied over)
Ok, I made a pretty braindead suggestion, just appending something about the above and a link to the Reworkhelper to your text. :)
there is a tool called "Reworkhelper" which we could tell people as use http://tools.wikimedia.de/~luxo/reworkhelper/?lang=en just as we tell people to use CommonsHelper and FLinfo, however I find Reworkhelper has a very confusing interface. If someone could work with Luxo to improve it that would be good. Someone who regularly uploads derivs and has an idea of what info needs to be checked, would be good.
That's really neat, but indeed has a difficult UI.
Seems like improving Reworkhelper is clearly the way forward. I'll take a closer look at it and see if I can contribute to that.
Please, avoid the use of "uselang". It works fine in english, but not for other languages. If you create a new "language" you must translate too many interface messages.
See http://commons.wikimedia.org/w/index.php?title=Special:Contributions&lim...
Someone could create a bot to make that work?
Sanbec
2007/11/26, Mike Linksvayer ml@creativecommons.org:
On Mon, 2007-11-26 at 11:52 +1100, Brianna Laugher wrote:
I started creating the messages necessary for a new option on Commons:Upload, see http://commons.wikimedia.org/wiki/MediaWiki:Uploadtext/commonsderivative
but I stopped because I don't know what else is important to mention...
Should it still be noted that the uploaded derivative can only incorporate your original work in addition to the source work already on the site? There are lots of ways one can make a derivative work that aren't simple operations on the source work.
(only admins can edit that page, but please put suggested text on the talk page and it will be copied over)
Ok, I made a pretty braindead suggestion, just appending something about the above and a link to the Reworkhelper to your text. :)
there is a tool called "Reworkhelper" which we could tell people as use http://tools.wikimedia.de/~luxo/reworkhelper/?lang=en just as we tell people to use CommonsHelper and FLinfo, however I find Reworkhelper has a very confusing interface. If someone could work with Luxo to improve it that would be good. Someone who regularly uploads derivs and has an idea of what info needs to be checked, would be good.
That's really neat, but indeed has a difficult UI.
Seems like improving Reworkhelper is clearly the way forward. I'll take a closer look at it and see if I can contribute to that.
-- http://wiki.creativecommons.org/User:Mike_Linksvayer
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
On 26/11/2007, Santiago Becerra Carrillo sanbec@gmail.com wrote:
Please, avoid the use of "uselang". It works fine in english, but not for other languages. If you create a new "language" you must translate too many interface messages.
See http://commons.wikimedia.org/w/index.php?title=Special:Contributions&lim...
Someone could create a bot to make that work?
Sanbec
OMG Sanbec! I already have a bot that does *exactly* that!
http://commons.wikimedia.org/wiki/User:MediaWiki_Update_Bot
You should check before you waste so much time! :)
cheers Brianna
:'(
2007/11/26, Brianna Laugher brianna.laugher@gmail.com:
On 26/11/2007, Santiago Becerra Carrillo sanbec@gmail.com wrote:
Please, avoid the use of "uselang". It works fine in english, but not
for
other languages. If you create a new "language" you must translate too
many
interface messages.
See
http://commons.wikimedia.org/w/index.php?title=Special:Contributions&lim...
Someone could create a bot to make that work?
Sanbec
OMG Sanbec! I already have a bot that does *exactly* that!
http://commons.wikimedia.org/wiki/User:MediaWiki_Update_Bot
You should check before you waste so much time! :)
cheers Brianna
-- They've just been waiting in a mountain for the right moment: http://modernthings.org/
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
Is there any way this form/helper can also add a note to the original work (either automatically, or by generating a link to do so, like with CommonsHelper)? Padraic
Padraic Ryan wrote on Monday, November 26, 2007 3:58 PM:
Is there any way this form/helper can also add a note to the original work (either automatically, or by generating a link to do so, like with CommonsHelper)?
Luxo said that it would maybe better, if he developed a new tool. Meanwhile he should be on the list in order to join this conversation.
This thread was started on Oct 25 by Nilfanion and can be viewed on http://lists.wikimedia.org/pipermail/commons-l/2007-October/002959.html
Regards,
Flo
Hi all,
I heard that you speak about my Reworkhelper ;)
I developed this tool only for the German graphic lab (Wikipedia:Bilderwerkstatt), and his options were adjusted for this. So I think it will be easier to develop a new tool which is adjusted to commons. It should also be possible to add a note to the original work.
I created a sub-page for the new description page the tool should build:
http://commons.wikimedia.org/wiki/User:Luxo/derivative_works_uploader
Should it also be possible to upload derivatives from other wikis? This is not so easy to make because of the licences (e.g. {{Bild-GFDL}} in de and {{GFDL}} in commons) - they must been translated.
Greetings Luxo
p.s.: Sorry my bad English (en-1) - I hope you understand it ;)
2008/1/7, Florian Straub flominator@gmx.net:
Padraic Ryan wrote on Monday, November 26, 2007 3:58 PM:
Is there any way this form/helper can also add a note to the original work (either automatically, or by generating a link to do so, like with CommonsHelper)?
Luxo said that it would maybe better, if he developed a new tool. Meanwhile he should be on the list in order to join this conversation.
This thread was started on Oct 25 by Nilfanion and can be viewed on http://lists.wikimedia.org/pipermail/commons-l/2007-October/002959.html
Regards,
Flo
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
Hi,
I have released a alpha-version of the upload-tool for derivative works:
http://tools.wikimedia.de/~luxo/derivativeFX/
There are yet not all features implanted - but the basically things should work, except with Internet Explorer, he has problems with the first form (What else?). I'll fix that later.
If you find any bugs please notify them here: http://commons.wikimedia.org/wiki/User:Luxo/derivative_works_uploader#Bugs
I call it "derivativeFX" - that's not very creative, if you have a better idea tell it to me ;-)
regards Luxo
2008/1/7, Luxo luxo@ts.wikimedia.org:
Hi all,
I heard that you speak about my Reworkhelper ;)
I developed this tool only for the German graphic lab (Wikipedia:Bilderwerkstatt), and his options were adjusted for this. So I think it will be easier to develop a new tool which is adjusted to commons. It should also be possible to add a note to the original work.
I created a sub-page for the new description page the tool should build:
http://commons.wikimedia.org/wiki/User:Luxo/derivative_works_uploader
Should it also be possible to upload derivatives from other wikis? This is not so easy to make because of the licences (e.g. {{Bild-GFDL}} in de and {{GFDL}} in commons) - they must been translated.
Greetings Luxo
p.s.: Sorry my bad English (en-1) - I hope you understand it ;)2008/1/7, Florian Straub flominator@gmx.net:
Padraic Ryan wrote on Monday, November 26, 2007 3:58 PM:
Is there any way this form/helper can also add a note to the original work (either automatically, or by generating a link to do so, like with CommonsHelper)?
Luxo said that it would maybe better, if he developed a new tool. Meanwhile he should be on the list in order to join this conversation.
This thread was started on Oct 25 by Nilfanion and can be viewed on http://lists.wikimedia.org/pipermail/commons-l/2007-October/002959.html
Regards,
Flo
Commons-l mailing list Commons-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/commons-l
On 25/10/2007, Padraic Ryan padraic.j.ryan@gmail.com wrote:
It seems to me a great first step to solving this problem is having an option at [[Commons:Upload]] page like "It is a derivative work of a media file already on the Commons" (perhaps also explaining what qualifies as a derivative work). This would allow (1) automatically insert some kind of template designed to indicate and keep track of derivative works, should one be made and more importantly (2) automatically check that the newly uploaded work is under the appropriate license - preventing someone from licensing a derivative of a GFDL file as CC-BY-SA or PD, etc. I have no technical knowledge in this area but that seems possible.
Just my two cents...first time poster. Padraic http://commons.wikimedia.org/wiki/User:Padraic
The first is doable. The second might just be possible through some really weird template setups but I doubt it.
On 25/10/2007, Padraic Ryan padraic.j.ryan@gmail.com wrote:
It seems to me a great first step to solving this problem is having an option at [[Commons:Upload]] page like "It is a derivative work of a media file already on the Commons" (perhaps also explaining what qualifies as a derivative work). This would allow (1) automatically insert some kind of template designed to indicate and keep track of derivative works, should one be made and more importantly (2) automatically check that the newly uploaded work is under the appropriate license - preventing someone from licensing a derivative of a GFDL file as CC-BY-SA or PD, etc. I have no technical knowledge in this area but that seems possible.
It seems to be a common enough situation that a separate form would be useful. And given that we encourage deriv works it makes sense to make it easy for uploaders in that situation. I didn't know how common that situation was but I've seen several similar comments over the past months.
So.. http://commons.wikimedia.org/wiki/MediaWiki:Uploadtext/commonsderivative
I don't know what we can do about magic templates or whatever, but what's the essentials for this form?
cheers Brianna
On 10/24/07, Nilfanion nilfanion@googlemail.com wrote:
It is easy to fix one image, but I suspect we have deeper problems throughout the project with a lack of respect for copyleft. Establishing just how serious this issue is will be non-trivial, never mind resolving it.
It's one of the downsides of allowing so many incompatible copyleft licenses -- if you really want to be scrupulous you have to create crazy licensing schemes on the derivative images. This is one of the reasons people should be encouraged to multi-license (GFDL/CC/etc.) -- otherwise you end up with competing flavors of copyleft that are not compatible and are in the end no great increase in freedom.
I've thought for a long time that we should have a category of generic copyleft license that basically said that the WMF could add additional licenses to that category over time as long as they met a few basic requirements. So I would license an image as "Generic WMF-approved copyleft" and the license itself would say that GFDL and CC-BY-SA were currently included in that, but if in the future SuperCopyLeftLicense was developed then the WMF could deliberate and decide if it was included as well, and this could apply retroactively (in the same way that the FSF can update the GFDL as they see fit). To me that would seem like the perfect way to encourage interchangability over the long and short terms (will the GFDL be used for anything but Wikimedia-related projects in the next ten years? Was it really the best license to commit to? Why commit to any one license, why not leave it open just enough to allow evolution but constrained in such a way to make abuse unlikely?).
But nobody seems that enthusiastic about the idea but me. Oh well. :-(
FF