Preferred licenses

List overview All Threads
Download

newer

older

Reminder: Open IRC meeting with...

Fwd: [Wikitech-l] relocating...

Neil Kandalgaonkar

21 Jul 2010 21 Jul '10

12:31 a.m.

For the new uploader I'm working on[1], we want it to remember your previous preferences about what license to use and maybe a few other things. Here's what I'm thinking about: - We add a new preference for preferred license. - If present, this prefills the upload form with a license. - If absent, no license is prefilled. - Whatever you pick in this form overwrites the preference. That is, uploading a file has the side effect of storing a preference for the next time. I realize this doesn't capture every edge case, but the point is to get behaviour that's simple enough that most people can actually use, and experienced users can work with. Our main difficulty at this point in the upload form is going to be about explaining licenses. I don't want to ask them to do understand something else like "Do you want to keep the same license choice for next time?" before they've even finished uploading this one. If it turns out that we have to ask them about this explicitly, I'd rather leave that to the end of the process. [1] http://commons.prototype.wikimedia.org/ -- this is JUST a prototype, we're changing a lot -- Neil Kandalgaonkar |) <neilk(a)wikimedia.org>

Show replies by date

Sage Ross

21 Jul 21 Jul

2:46 a.m.

On Tue, Jul 20, 2010 at 6:31 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

...

My preferred behavior would be: * If no license is selected under preferences, then it remembers what you chose last time. * If a license is selected under preferences, then it sticks with that one even if you choose a different one for individual uploads. My default preference stays the same, but for various reasons I sometimes want or need to deviate from that. I would find it frustrating if the preference that I set manually got changed every time I used a different choice for a single upload. -Sage

Stephen Bain

4:28 a.m.

On Wed, Jul 21, 2010 at 10:46 AM, Sage Ross <ragesoss+wikipedia(a)gmail.com> wrote:

...

Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference? -- Stephen Bain stephen.bain(a)gmail.com

Neil Kandalgaonkar

4:48 a.m.

On 7/20/10 7:28 PM, Stephen Bain wrote:

...

Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference?

That might not be too bad. I think I'd put question that *after* the upload was done though. -- Neil Kandalgaonkar |) <neilk(a)wikimedia.org>

Maarten Dammers

9:32 p.m.

Op 21-7-2010 4:48, Neil Kandalgaonkar schreef:

...

On 7/20/10 7:28 PM, Stephen Bain wrote:

Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference?

That might not be too bad. I think I'd put question that *after* the upload was done though.

Just give the user the option to set a default license for own work files. If the user doesn't select own work in the upload form -> don't set the default license. Maarten

Gnangarra

22 Jul 22 Jul

3:50 a.m.

While default license is a good idea we need to remember that the uploaders are making a choice to release their work With that they should be making the choice and not having us(some automated process) do it for them because they are giving away rights to their work. A prefilled form could be argued as taking the licensing options away from the uploader, and therefore Commons taking responsability for the release of the material. Admins have always look unfavourably at deletion request because the loader says they didnt intend releasing the work for commercial use or thought they were only releasing for educational use or some other reason, we can do that because the person made the choice with each and every upload not us. Automatically prefilling the upload form with a license removes the choice/decision to over come that we would then need an alternative check box for the uploader to acknowledge that they understand the rights they are releasing. We need people to freely release media, we need them to do in such away that we can be confident that what ever licensing the uploader chooses it is them making the choice not us. As for a catergory option how do we distinguish the license choice where we have two or more different licensing options the Mark Twain example let say I have access to the a complete set of original books I lay them out in a display s as to show different features(not a reproduction of each book) I then categorise it under Photographs by me -- i use (cc-by-2.5) Books by Mark Twain -- PD-old the license because there is effort and originality in the composition I am the copyright holder of that image the license is CC-by-2.5, I was to then photograph each book individually and the image was entirely the book/page then it would be PD, no automotion process can distinguish between these two images to make a valid choice nor should it again because its the uploaders responsability to upload the images with the appropriate license. On 22 July 2010 03:32, Maarten Dammers <maarten(a)mdammers.nl> wrote:

...

Op 21-7-2010 4:48, Neil Kandalgaonkar schreef:

On 7/20/10 7:28 PM, Stephen Bain wrote:

Perhaps a checkbox could be displayed when the licence field is filled with the default preference but the user inputs something else, asking if they would like to update their preference?

That might not be too bad. I think I'd put question that *after* the upload was done though.

Just give the user the option to set a default license for own work files. If the user doesn't select own work in the upload form -> don't set the default license. Maarten _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

-- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com

John Vandenberg

7:05 a.m.

On Wed, Jul 21, 2010 at 8:31 AM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote:

...

For the new uploader I'm working on[1], we want it to remember your previous preferences about what license to use and maybe a few other things. .. [1] http://commons.prototype.wikimedia.org/ -- this is JUST a prototype, we're changing a lot

My upload of non-free "Bulogo.gif" went ahead because it was uploaded _before_ I was presented with the licensing dilemma. Will there be an automatic purge of incomplete uploads? My upload of PD-US "MajorGeneralHood.jpg" hung in the "Describe" phase. On Thu, Jul 22, 2010 at 11:50 AM, Gnangarra <gnangarra(a)gmail.com> wrote:

...

I was going to voice similar concerns! ;-) The breakdown on [[Commons:Upload]] is quite important. IMO, the only safe use for a preferred license is in the case of 'entirely my own work'. If the upload is 'a derivative work of a file from Commons' or 'from another Wikimedia project', the uploaders preferred license is not relevant. The ability to upload multiple files would be a nice feature, however given that the licensing phase of the wizard is simplifying the options, the design needs to be careful to ensure that the user confirms that all uploads files are of the same license type. -- John Vandenberg

Neil Kandalgaonkar

7:35 p.m.

On 7/21/10 10:05 PM, John Vandenberg wrote:

...

My upload of non-free "Bulogo.gif" went ahead because it was uploaded _before_ I was presented with the licensing dilemma. Will there be an automatic purge of incomplete uploads?

Correct. When we're finished, it won't even touch the database until you've given it a license and appropriately described it and so on. It may seem a bit weird to upload and then add metadata but this is the best solution we could come up with that works in all current browsers. It's also a workflow that more people are familiar with anyway. Previously, Commons has been extremely careful to ensure that every last bit of metadata was right before uploading, but not in a very friendly way (in our testing, many users lost the data they entered *multiple* times before being able to complete an upload). We also do the upload before adding metadata because it helps usability -- the server can give you a nice thumbnail, and by analyzing EXIF and the filename it can prefill certain fields. Very modern browsers are actually able to do that all in Javascript, so perhaps one day we'll perform the upload at the end of the wizard. Generally, our goal is to strengthen policies around having an appropriate license for media, not just for Commons but any MediaWiki that needs it. Currently the list of appropriate licenses is managed in a very ad-hoc way, via hacking and then parsing translation strings. Not only is this fragile and extremely obscure, it only works on Commons. In the UploadWizard, any MediaWiki can configure (a) whether the wiki requires a license (b) exactly which licenses (or kinds of licenses) are acceptable. Of course, nothing stops people from mucking with the license after the fact, since it's just a template, but this is a step in the right direction.

...

My upload of PD-US "MajorGeneralHood.jpg" hung in the "Describe" phase.

It's a prototype and that tends to happen right now, sorry.

...

IMO, the only safe use for a preferred license is in the case of 'entirely my own work'.

That was what I meant -- perhaps I didn't make that clear.

...

The ability to upload multiple files would be a nice feature, however given that the licensing phase of the wizard is simplifying the options, the design needs to be careful to ensure that the user confirms that all uploads files are of the same license type.

Yes. We have tried to make that very explicit. Some users still had difficulties so we have a few more interfaces we want to test about this. Stay tuned. -- Neil Kandalgaonkar |) <neilk(a)wikimedia.org>

Neil Kandalgaonkar

7:14 p.m.

On 7/21/10 6:50 PM, Gnangarra wrote:

...

The discussion was about letting users set a preferred license for their own uploads, where it's their own work. -- Neil Kandalgaonkar |) <neilk(a)wikimedia.org>

Platonides

8:55 p.m.

Gnangarra wrote:

...

Admins have always look unfavourably at deletion request because the loader says they didnt intend releasing the work for commercial use or thought they were only releasing for educational use or some other reason, we can do that because the person made the choice with each and every upload not us. Automatically prefilling the upload form with a license removes the choice/decision to over come that we would then need an alternative check box for the uploader to acknowledge that they understand the rights they are releasing. We need people to freely release media, we need them to do in such away that we can be confident that what ever licensing the uploader chooses it is them making the choice not us.

What about offering a "bookmark" of licenses? So you could save the 2-3 licenses you tend to use, and still need a click to apply them to the upload.

Gnangarra

23 Jul 23 Jul

4:20 a.m.

...

From what I've just read this is going ahead irreguardless in that case I

think that there should be at the very least a barrier/flag before its usable like rollback, file mover and handful of other functions<http://commons.wikimedia.org/wiki/Special:ListGroupRights>w… by an editor requests the function then an admin can assign it to them. That at least gives an opportunity for a review and an attempt at ensuring that the user at least understands what they are doing. It also gives us a time stamp/ip/username which we can point to that the user accepted/acknowledged that they are agreeing to an automated licensing process and accept responsibility for the end result. A bookmark list of the users common licensing choices would be a useful function to include because very few users only contribute one type of image, personally I have 3 types that I'd use frequently primarily CC-by(own photographs) also PD(self made maps), and PD-Aust(old photographs from Australia) On 23 July 2010 02:55, Platonides <Platonides(a)gmail.com> wrote:

...

Gnangarra wrote:

n -- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com

Ryan Kaldari

7:47 p.m.

IMO, the license/upload problem is not as complicated as everyone makes it out to be. First of all, the upload form should /not/ be a venue for educating people on copyright and free licenses. As painful as it may be, we need to abandon our maternal instincts and assume that the uploader knows what they're doing and give them the option of learning more /if they want to/, not spamming the interface with endless explanations and caveats. Secondly, we need to keep it simple. If the uploader owns the image, give them 3 options: * CC-zero (public domain) * CC-by (attribution) * CC-by-sa (attribution share-alike) If they don't own the image, expose the rest of the options. Thirdly, we should let each user set a default upload license for images they own. They get to choose one of the 3 options above in their preferences and that option is then preselected whenever the user starts uploading an image they own. Fourth, we leave the old crappy upload interface in place at some alternate URL that is linked in microscopic text from the new upload page and we rename it "Advanced Upload". Fifth, we develop some solid client-side uploading tools so that regular contributors don't have to bother with the web interface at all :) Ryan Kaldari On 7/22/10 7:20 PM, Gnangarra wrote:

...

LIcensing is a legal contract between the author, wikimedia and any reusers we should be ensuring the integrity of the authors choice in the matter especially since we are effectively requiring the author to abandon their rights altogether. From what I've just read this is going ahead irreguardless in that case I think that there should be at the very least a barrier/flag before its usable like rollback, file mover and handful of other functions <http://commons.wikimedia.org/wiki/Special:ListGroupRights> where by an editor requests the function then an admin can assign it to them. That at least gives an opportunity for a review and an attempt at ensuring that the user at least understands what they are doing. It also gives us a time stamp/ip/username which we can point to that the user accepted/acknowledged that they are agreeing to an automated licensing process and accept responsibility for the end result. A bookmark list of the users common licensing choices would be a useful function to include because very few users only contribute one type of image, personally I have 3 types that I'd use frequently primarily CC-by(own photographs) also PD(self made maps), and PD-Aust(old photographs from Australia) On 23 July 2010 02:55, Platonides <Platonides(a)gmail.com <mailto:Platonides@gmail.com>> wrote: Gnangarra wrote:

Admins have always look unfavourably at deletion request because the loader says they didnt intend releasing the work for commercial

use or

thought they were only releasing for educational use or some other reason, we can do that because the person made the choice with

each and

every upload not us. Automatically prefilling the upload form with a license removes the choice/decision to over come that we would

then need

an alternative check box for the uploader to acknowledge that they understand the rights they are releasing. We need people to freely release media, we need them to do in

such away

that we can be confident that what ever licensing the uploader

chooses

it is them making the choice not us.

What about offering a "bookmark" of licenses? So you could save the 2-3 licenses you tend to use, and still need a click to apply them to the upload. _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org <mailto:Commons-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/commons-l n -- GN. Photo Gallery: http://gnangarra.redbubble.com Gn. Blogg: http://gnangarra.wordpress.com _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

David Gerard

24 Jul 24 Jul

2:12 p.m.

On 23 July 2010 18:47, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote:

...

First of all, the upload form should not be a venue for educating people on copyright and free licenses. As painful as it may be, we need to abandon our maternal instincts and assume that the uploader knows what they're doing and give them the option of learning more if they want to, not spamming the interface with endless explanations and caveats.

Yes. Like so many things on Wikimedia, it's at the point of overwhelming instruction creep attempting to legislate clue. - d.

Maarten Dammers

28 Jul 28 Jul

8:43 p.m.

Hi Ryan, Op 23-7-2010 19:47, Ryan Kaldari schreef:

...

<snip point one to four> Fifth, we develop some solid client-side uploading tools so that regular contributors don't have to bother with the web interface at all :)

What about improving Commonist? Could be moved to Wikimedia svn so more people can work on it. Maarten

Ryan Kaldari

9:57 p.m.

Improving Commonist would be a good start. Especially the installation process, which is arcane to anyone who doesn't use a command line. Ryan Kaldari On 7/28/10 11:43 AM, Maarten Dammers wrote:

...

Hi Ryan, Op 23-7-2010 19:47, Ryan Kaldari schreef:

<snip point one to four> Fifth, we develop some solid client-side uploading tools so that regular contributors don't have to bother with the web interface at all :)

What about improving Commonist? Could be moved to Wikimedia svn so more people can work on it. Maarten _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

David Gerard

11:38 p.m.

On 28 July 2010 20:57, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote:

...

Improving Commonist would be a good start. Especially the installation process, which is arcane to anyone who doesn't use a command line.

And OpenJDK is now GPL all the way through. Yay free software! - d.

Maarten Dammers

29 Jul 29 Jul

6:44 p.m.

New subject: Improving Commonist (was Preferred licenses)

Hi guys, Op 28-7-2010 23:38, David Gerard schreef:

...

On 28 July 2010 20:57, Ryan Kaldari<rkaldari(a)wikimedia.org> wrote: > Improving Commonist would be a good start. Especially the installation > process, which is arcane to anyone who doesn't use a command line. >

Never did the installation process. The webstart on the other hand is nice. Things to do: * Move sources to svn (now at http://djini.de/software/commonist/) * Revive the translation process (now discontinued at http://translatewiki.net/wiki/Commonist) * Use a bugtracker. Maybe just https://bugzilla.wikimedia.org? Please extend this list.

...

And OpenJDK is now GPL all the way through. Yay free software!

And no Oracle label to crash your software ;-) Maarten

...

- d. _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

Gerard Meijssen

7:24 p.m.

New subject: Improving Commonist (was Preferred licenses)

Hoi, Does this mean that there is someone who looks after Commonist ? It used to be localised at translatewiki.net and it was dropped for lack of attention. It is likely that many localisations are still around somewhere. Thanks, GerardM On 29 July 2010 18:44, Maarten Dammers <maarten(a)mdammers.nl> wrote:

...

Hi guys, Op 28-7-2010 23:38, David Gerard schreef:

And OpenJDK is now GPL all the way through. Yay free software!

And no Oracle label to crash your software ;-) Maarten

- d. _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

Benjamin Esham

9:55 p.m.

New subject: Improving Commonist (was Preferred licenses)

Maarten Dammers wrote:

...

[improving Commonist] Never did the installation process. The webstart on the other hand is nice. Things to do: * Move sources to svn (now at http://djini.de/software/commonist/) * Revive the translation process (now discontinued at http://translatewiki.net/wiki/Commonist) * Use a bugtracker. Maybe just https://bugzilla.wikimedia.org? Please extend this list.

Gerard Meijssen

10:09 p.m.

New subject: Improving Commonist (was Preferred licenses)

Hoi, There is a Wiki for i18n and it is translatewiki.net. When the person(s) responsible for Commonist had reacted to the calls for contact and continued support so that the localisations would have become available in the software to the public, there would have been many more localisations available.

...

From what I understand, there is as much need for a source code repository

system for Commonist then for a bug tracker. There may be good things to say for trac but in my appreciation it is yet another tool making it more complicated. Thanks, GerardM On 29 July 2010 21:55, Benjamin Esham <bdesham(a)gmail.com> wrote:

...

Maarten Dammers wrote:

[improving Commonist] Never did the installation process. The webstart on the other hand is

nice.

Things to do: * Move sources to svn (now at http://djini.de/software/commonist/) * Revive the translation process (now discontinued at http://translatewiki.net/wiki/Commonist) * Use a bugtracker. Maybe just https://bugzilla.wikimedia.org? Please extend this list.

Doesn’t Wikimedia have a Trac installation? Would it be easiest just to use that as a (D)VCS, a wiki for i18n, and a bug tracker? Regards, -- Benjamin D. Esham | bdesham(a)gmail.com “Come to think of it, there are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare!” — Blair Houghton _______________________________________________ Commons-l mailing list Commons-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l

Platonides

31 Jul 31 Jul

1:27 a.m.

New subject: Improving Commonist (was Preferred licenses)

Multichill added it to wikimedia subversion in r70174

Jan Luca

4 Aug 4 Aug

8:40 p.m.

New subject: Improving Commonist (was Preferred licenses)

Hi, I have added the "old" java-version to the Wikimedia SVN because I think if there will be more than one developer java is the better language. The code is without the login patch because I found no source with patch. The revision is r70471 (http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70471), URL: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist-java/ (ViewVC), http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/commonist-java/ (SVN direct link) Best regards, Jan

Marcin Cieslak

30 Aug 30 Aug

4:11 a.m.

New subject: Improving Commonist (was Preferred licenses)

Jan Luca <jan(a)jans-seite.de> wrote:

...

The revision is r70471 (http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70471), URL: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/commonist-java/ (ViewVC), http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/commonist-java/ (SVN direct link)

I have added missing bits (so it actually compiles), and provided my login problem patch to commonist 0.3.43 (naming it "0.3.44" now). This is now commited as r71919. However, file re-upload (existing filename, same hash, previously deleted file) still does not work with this version. Fixing this requires a bit of work. That said, however, I have my doubts about the future of the pure Java version: - it uses screen scrapping and is prone to changes of messages in Plattdüütsch (sic!) - original author uses a nice functional programming style (which I like) but this raises entry bar for the average Java programmer. -- << Marcin Cieslak // saper(a)saper.info >>

Neil Kandalgaonkar

21 Jul 21 Jul

4:47 a.m.

On 7/20/10 5:46 PM, Sage Ross wrote:

...

I thought of doing this, but then I realized this means I effectively have to have *two* preferences. When set as side effect of form choice... LicensePref: CC-BY-SA-30 LicensePrefDontUpdateOnChoose: false / empty When set by preference: LicensePref: CC-BY-SA-30 LicensePrefDontUpdateOnChoose: true Which seems slightly silly, to have a preference about a preference. We're supposed to think very, very hard before adding new prefs to MediaWiki. -- Neil Kandalgaonkar |) <neilk(a)wikimedia.org>

Lars Aronsson

2:53 a.m.

On 07/21/2010 12:31 AM, Neil Kandalgaonkar wrote:

...

Another way to solve the problem is to always upload new files "towards" an existing category, and allow categories to carry a default license. Users who want to upload their own photos, should first create a category:photos_by_user_XYZ and set a default license for this category. This could be done as part of creating a new account. If I'm uploading scanned books by Mark Twain, I would upload them towards category:Books_by_Mark_Twain, which should contain some PD template, and this would not depend on my personally preferred license. If a user wants to upload some photos with one license, and other illustrations with another license, they could simply create two categories. This scheme is not in conflict with yours. You could use the category's preferred license as the initial default and fallback to the user's preferred license. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

4981

days inactive

5022

days old

commons-l@lists.wikimedia.org

Manage subscription

24 comments

14 participants

tags (0)

participants (14)

Benjamin Esham
David Gerard
Gerard Meijssen
Gnangarra
Jan Luca
John Vandenberg
Lars Aronsson
Maarten Dammers
Marcin Cieslak
Neil Kandalgaonkar
Platonides
Ryan Kaldari
Sage Ross
Stephen Bain