Problems with derivative works

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Problems with derivative works

nilfanion wiki
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?

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Bryan Tong Minh
On 10/25/07, Nilfanion <[hidden email]> 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

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Andre Engels
2007/10/25, Bryan Tong Minh <[hidden email]>:

> > * 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.

--
Andre Engels, [hidden email]
ICQ: 6260644  --  Skype: a_engels

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Magnus Manske-2
On 10/25/07, Andre Engels <[hidden email]> wrote:

> 2007/10/25, Bryan Tong Minh <[hidden email]>:
>
> > > * 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

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Andre Engels
2007/10/25, Magnus Manske <[hidden email]>:

> 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.

--
Andre Engels, [hidden email]
ICQ: 6260644  --  Skype: a_engels

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Andrew Gray
In reply to this post by nilfanion wiki
On 25/10/2007, Nilfanion <[hidden email]> 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
  [hidden email]

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Padraic Ryan
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 <[hidden email]> wrote:
On 25/10/2007, Nilfanion <[hidden email]> 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
  [hidden email]

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l


_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

David Gerard-2
On 25/10/2007, Padraic Ryan <[hidden email]> 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.

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Magnus Manske-2
In reply to this post by Andre Engels
On 10/25/07, Andre Engels <[hidden email]> wrote:

> 2007/10/25, Magnus Manske <[hidden email]>:
>
> > 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

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Fastfission
In reply to this post by nilfanion wiki
On 10/24/07, Nilfanion <[hidden email]> 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

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

geni
In reply to this post by Padraic Ryan
On 25/10/2007, Padraic Ryan <[hidden email]> 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.

--
geni

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Andre Engels
In reply to this post by Magnus Manske-2
2007/10/25, Magnus Manske <[hidden email]>:

> 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, [hidden email]
ICQ: 6260644  --  Skype: a_engels

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

nilfanion wiki
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 <[hidden email]> wrote:

> 2007/10/25, Magnus Manske <[hidden email]>:
>
> > 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, [hidden email]
> ICQ: 6260644  --  Skype: a_engels
>
> _______________________________________________
> Commons-l mailing list
> [hidden email]
> http://lists.wikimedia.org/mailman/listinfo/commons-l
>

Nilfanion

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Brianna Laugher
In reply to this post by Padraic Ryan
On 25/10/2007, Padraic Ryan <[hidden email]> 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

--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Mike Linksvayer-2
In reply to this post by David Gerard-2
On Thu, 2007-10-25 at 14:15 +0100, David Gerard wrote:

> On 25/10/2007, Padraic Ryan <[hidden email]> 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=derived

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.


--
 http://wiki.creativecommons.org/User:Mike_Linksvayer


_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Brianna Laugher
On 26/11/2007, Mike Linksvayer <[hidden email]> wrote:

> On Thu, 2007-10-25 at 14:15 +0100, David Gerard wrote:
> > On 25/10/2007, Padraic Ryan <[hidden email]> 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=derived
>
> 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

--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Mike Linksvayer-2
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
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Santiago Becerra Carrillo
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&limit=250&contribs=user&target=Sanbec&namespace=8

Someone could create a bot to make that work?

Sanbec


2007/11/26, Mike Linksvayer <[hidden email]>:
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
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l


_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Brianna Laugher
On 26/11/2007, Santiago Becerra Carrillo <[hidden email]> 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&limit=250&contribs=user&target=Sanbec&namespace=8
>
> 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
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: Problems with derivative works

Santiago Becerra Carrillo
:'(

2007/11/26, Brianna Laugher <[hidden email]>:
On 26/11/2007, Santiago Becerra Carrillo <[hidden email]> 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&limit=250&contribs=user&target=Sanbec&namespace=8
>
> 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
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l


_______________________________________________
Commons-l mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/commons-l
12