I think this is a great start and I am willing to start drawing up plans 
about this on-wiki somewhere. I am rather slammed with pressing 
deadlines right now but I just wanted to contribute a little to the 
discussion.


> On Fri, 10 Sep 2010 23:11:27 +0000, Dan Nessett wrote:
>
>
> Implementation location: In an extension
>
> Permissions: include two new permissions - 1) addlicensedata, and 2)
> modifylicensedata.

Sounds good to me.


> Database schema: Add a "licensing" table to the db with the following
> columns - 1) revision_or_image, 2) revision_id, 3) image_id, 4)
> content_source, 5) license_id, 6) user_id.
>
> The first three columns identify the revision or image to which the
> licensing data is associated.

revision_or_image is a wart, as others pointed out. Each image has its 
own dedicated wiki page so it is probably more useful to use that.

Otherwise your schema is already similar to work I've been doing with 
UploadWizard, building on typical licensing workflows and templates.

There are "Deeds" which are composed of:

- Source -- some information that tells us where this came from. 
Currently we use a variety of wiki templates here. It could be a URL, a 
bibliographic record, anything.

- Author, which again is rather free-form. It can be a particular user 
on the wiki. But it also common to use a Creator template for a famous 
artist, or to simply write in the name in plaintext.

- License, which is just a template license, but in this new world 
should be something like license_id.

If we want to get more structured, it would be nice to also record the 
Uploader, since that is not the same thing as the Author or Source. 
Things may get complex when image replacement happens as you noted.

Right now our major use case is when the uploader is the author. But it 
will not always be so. In the case where the uploader asserts that 
someone else has okayed their work to be distributed under a free 
license, we want the author in question, or OTRS, to be able to check 
off that this was verified. OTRS has a workflow like this already, and 
in the Multimedia project we had plans to simplify this but I'm afraid 
it's unlikely I will get to that that soon.


> Add a "license" table with the following columns - 1) license_id, 2)
> license_text, 3) license name and 4) license_version. The license_id in
> the licensing table references rows in this table.

Sounds good to me although I would also add boolean columns that are 
useful to describe the salient features of the license in machine 
readable terms, like "attribution_required", "share_alike", etc. That 
will help with searching and with a uniform licensing display (see 
below). Another column which gives us the wiki-hosted image of a small 
icon for the license may also be helpful.

Licensing gets very complicated when it comes to country-by-country 
laws, so it may be useful to record the legal regime under which the 
deed falls, which could be something like a country code.

> Page rendering: You probably don't want to dump licensing data directly
> onto a page. Instead, it is preferable to output a short licensing
> statement like:

No, you almost certainly do want to describe the terms of the license 
(broadly) right on the main page for the content.

The description should be functional, from a potential re-user's point 
of view, in very plain language. As in:

    WANT TO USE THIS IMAGE?

    You are free to use this image for any purpose, even in works that 
you sell.
    If you use this image, you must credit the author, Joe Blow 
<[email protected]> http://joeblow.sample.com/ .
    If you use this image, you must allow others to share the image in 
the same way.

    Read more about the licensing terms here: <link to our template for 
cc-by-sa 3.0>

That's why machine-readable license properties will help. Even for 
images which don't allow re-use at all, it should say so quite clearly. 
(We host Wikimedia trademarked images, for instance.)


PS: I apologize if the threading is screwed up here -- WMF mail was down 
for a few hours so I missed this message.

-- 
Neil Kandalgaonkar  |) <[email protected]>

_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to