View source

You do not have permission to edit pages, for the following reason:
The action you have requested is limited to users in the group Users.
You can view and copy the source of this page:
<entry-title>Licensing Brainstorming</entry-title>

Brainstorming proposals toward a [[licensing]] microformat per the microformats [[process]], based on:
* [[licensing-examples]]
* [[licensing-formats]]

== to do ==
* resort brainstorm proposals according to practicality/feasibility/functionality/usability of proposals, putting [[licensing-brainstorming#item_as_container|item as container]] at top.

== Discussion ==
Brainstorm proposals based on class names (and perhaps a rel value) to support real-world licensing and attribution publishing use cases. They could be used at webpage level or within specific microformats for scoped licensing, e.g.
* [[hNews]] - specifically uses the "[[licensing-brainstorming#item_as_container|item as container]]" brainstorm proposal, and [[rel-item-license]]. See [[hnews#Schema|hNews schema]] for details.
* [[media-info]]

=== reuse limitations ===
[[rel-license]] has already been specified to apply to the entire document, and thus many current [[implementations]] (e.g. [[search engines]]) already assume that whenever they see rel="license" that it applies to the whole page.

If we tried to re-use [[rel-license]] in the licensing microformat to refer to part of a page or an external resource, existing implementations would mis-interpret such a use as applying to the whole page.

Thus in order to not break backward compatibility with existing rel-license implementations, if we want something like [[rel-license]] for the licensing microformat, we must use a new rel value.

=== table of possible properties ===
The first column may be too URL-centric, see notes for parent work, may apply to others.

<table border="1" cellpadding="3" cellspacing="2">
<tr><th>Overly descriptive strawman not intended to conform with any convention</th><th>[[existing-classes|Existing class(es)]]; source</th><th>Notes</th></tr>

<tr>
<td>work title</td>
<td>fn; hCard</td>
<td>See [[licensing-examples#Attribution_with_work_title|examples#title]]</td>
</tr>

<tr>
<td>attribution name, creator?</td>
<td>author; hAtom, [[hcard]]</td>
<td>Might be a vcard with fn, may also be an organization
<br/>See [[licensing-examples#Attribution_to_creator|examples#attribution]]</td>
</tr>

<tr>
<td>attribution url</td>
<td>url; hCard</td>
<td>An author might have a url, should this be taken as the attribution url? If a work has a url, should it be taken as the attribution url?
<br/>See [[licensing-examples#Attribution_with_link_required|examples#link]]</td>
</tr>

<tr>
<td>donation url</td>
<td>payment; rel-payment<br/>
offer; hListing</td>
<td>How to disambiguate from commercial licensing and purchase?
<br/>See [[licensing-examples#Donation_related_to_work|examples#donation]]</td>
</tr>

<tr>
<td>commercial licensing url</td>
<td>payment; rel-payment<br/>
sell, offer; hListing<br/>
copyright; HTML LinkType</td>
<td>How to disambiguate from donation and purchase?
<br/>See [[licensing-examples#Commercial_licensing|examples#commercial]]</td>
</tr>

<tr>
<td>purchase url</td>
<td>payment; rel-payment<br/>
sell, offer; hListing</td>
<td>How to disambiguate from donation and commercial licensing?
<br/>See [[licensing-examples#Purchase_related_media|examples#purchase]]</td>
</tr>

<tr>
<td>content hash</td>
<td>checksum, sha1; [[hash-examples]]</td>
<td>See [[licensing-examples#License_notice_with_content_hash|examples#hash]]</td>
</tr>

<tr>
<td>provenance url<td>
<td> See [[licensing-examples#Rights_provenance.2Fwarranty.2Fidemnification|examples#provenance]] </td>
</tr>

<tr>
<td>parent work <em>url?</em>, derivitave-source</td>
<td></td>
<td>Should this be a url? Maybe it should be a TBD "media" microformat which may be otherwise described.
<br/>See [[licensing-examples#Attribution_to_derivative.27s_source_work|examples#derivative]]<br/>
Probably should be a URL -- a uf can have a #URL if it has an id.</td>
</tr>

<tr>
<td>attribution, copied-source</td>
<td></td>
<td>Shows where the media was immediately copied from (not necessarily the same as its original source).  Has the same challenges as derivative-source.  Perhaps use the approach loosely outlined in [[licensing-brainstorming#Attribution_Challenges|Attribution Challenges]]</td>
</tr>

<tr>
<td>source</td>
<td></td>
<td>Like 'copied-source' but points to the original source.</td>
</tr>

</table>


=== Attribution Challenges ===
Tags dealing with specifying sources and tracking a piece of media's path through the Web (any of the -source tags above) are a little ambiguous in terms of what they can reference.  For instance when specifying a derivative work it could be from another image on the Internet, in which case an URL would be appropriate, or it could be a quotation from a magazine or other "real" world source where an URL doesn't really work.  Perhaps we can encourage the content of these 'media source' tags to be one of the following:
<table border="1" cellpadding="3">
<tr>
 <th>Media source type</th>
 <th>Format</th>
 <th>Notes</th>
</tr>
<tr>
 <td>Internet source</td>
 <td>An URL</td>
 <td></td>
</tr>
<tr>
 <td>Person</td>
 <td>[[hcard]]</td>
 <td></td>
</tr>
<tr>
 <td>Publication <br />(book, magazine, etc.)</td>
 <td>[[citation]]</td>
 <td>Citation appears to be heavily weighed towards academia but it looks like it should work for most purposes</td>
</tr>
<tr>
 <td>Film/Video</td>
 <td> ?? </td>
 <td>I'm not sure about this one.  Would citation stretch over visual media? Perhaps [[media-info]]?</td>
</tr>
</table>

=== containing vs being contained ===
Based on the markup in the [[licensing-examples]], in may be useful to consider two ways that licensing information could be expressed:
# A license microformat that contains the item on the page that is being licensed, as well as the license URL and attribution requirements (if any).
# A license microformat that contains just a link to the license URL, and has:
#* a) an ID reference to the item outside the licensing markup OR implied item applicability by a containing [[media-info]], [[hAtom]] hentry etc.
#* b) and contains OR has an ID reference to the attribution requirements (if any)

Both these options should be explored, and tried out with markup from actual [[licensing-examples]] to see which of today's use cases each option would work well/better with.

It may be that we want/need a licensing microformat that allows for either method (containing or being contained) of indicating the license.

== brainstorms ==
Various thoughts, proposals, strawman examples of how licensing information could be marked up.

=== class attribution ===
Perhaps there should be an 'attribution' class which might hint that a fn or url should be used for attribution?  Something like (webpage scope):

<pre>
<nowiki>
<a class="url attribution fn" href="http://example.com">My First Cookbook</a>
<div class="author vcard">
  <div class="fn attribution">J Doe</div>
</div>
<a rel="license" href="http://creativecommons.org/licenses/by/2.5/">(cc)</a>
<a rel="payment" href="http://paypal.com/...">don't let me starve</a>
</nowiki>
</pre>


==== media info with attribution ====
Here is an example of [[media-info]] with class 'attribution'.

<pre>
<nowiki>
<div class="media">
  <img class="url attribution mediaitem" src="http://example.com/cake.jpg"/>
  <span class="fn">Picture of a giant cake</span>
  <div class="author vcard">
    <div class="fn attribution">J Doe</div>
  </div>
  <a rel="license" href="http://creativecommons.org/licenses/by-nc/2.5/">(cc)</a>
  <a rel="payment" href="http://paypal.com/...">don't let me <s>starve</s>eat cake</a>
  <a rel="payment" href="http://artdelivery.example">buy this pic, framed</a>
  <a rel="payment" href="http://photoclearing.example">get commercial rights</a>
  ...
</div>
</nowiki>
</pre>


=== reuse CC vocabulary ===
Here is an example using the Creative Commons vocabulary, with CamelCase conventions converted to dash separated lowercase words per microformats [[naming-principles]].

<pre><nowiki>
<div class="license">
  <a rev="license" href="http://example.org/work">The work</a> 
  is licensed under the 
  <a rel="legal-code" href="http://example.org/foo">Foo License</a>. 
  Summary: it permits 
  <abbr title="derivative-works" class="permits">derivative works</abbr> 
  but requires 
  <abbr title="attribution" class="requires">attribution</abbr>. 
  The credit to give when reusing the work is 
  "<span class="vcard">
    <a href="http://tobyinkster.co.uk" class="fn url attribution-name" rel="attribution-url">
     Toby Inkster
    </a>
   </span>
  ".
</div>
</nowiki></pre>

The microformat could use the following terms:

* '''license''' {1} (root class name)
** legal-code ? (rel value, not class)
** ''more-permissions'' * (rel value, not class)
** ''permits'' * ("reproduction" | "distribution" | "derivative-works") "high-income-nation-use" and "sharing" are deprecated by Creative Commons, they were used in the retired DevNations and Sampling licences.
** ''requires'' * ("copyright-notices" | "attribution" | "share-alike" | "source-code")
** ''prohibits'' * ("commercial-use")
** ''jurisdiction'' * (text | hCard | adr)
** attribution-name ?
** attribution-url ? (rel value, not class)
** deprecated-on ? (ISO date)

The license linked to using rel="legal-code" (if any) should be taken to be the definitive license. When such a license is present, the "permits", "requires", "prohibits" and "jurisdiction" classes are taken to be merely advisory. When no "legal-code" license is linked to, these classes are definitive.

[[rel-license]] {{should}} be used to link from the work to the license (an ID attribute on the license will help). A license {{may}} link back to the work using rev="license", but forward links are preferred.

As an extension to the creative commons vocabulary (which focuses on open-source-like licenses) a payment URL {{may}} be linked to using an anchor element simultaneously carrying class="requires" and rel="payment". Example:

<pre><nowiki>
<a class="requires" rel="payment" href="https://payment.example.org">buy</a>
</nowiki></pre>

If [[rel-payment]] is used without a class of "requires", then the link is taken to be an optional payment link - i.e. a donation.

==== ccREL issues  ====
<div class="discussion">
* '''license proliferation anti-pattern.''' The ''permits'', ''requires'', ''prohibits'' properties enable (and thus encourage) a combinatorial explosion in license proliferation, which is well known/understood to be a bad thing in open source circles as well as in/by the Creative Commons community itself - e.g. in a presentation on 2005-11-03, Lawrence Lessig indicated that license proliferation was a threat to [http://www.flickr.com/photos/tantek/85610375/ interoperability], and that that was one of the biggest problems that the open source and content communities needed to address.  Note that this is an issue with ccREL itself, independent of the syntax, whether converted to microformats class names or not. [[User:Tantek|Tantek]] 21:50, 29 May 2009 (UTC)
** Doesn't "proliferation" indicate a measure of growth?  I'm not sure I see that in the industry I work in (it may be applicable to other industries, or the open source community).  In the industry I work in, licenses are prolific.  With each business deal, it seems, there are new license terms and conditions.  That's the measure as it stands today--nothing in an REL that I can see would proliferate licenses further.  In fact, forcing current licenses into existing RELs (ccREL being just one) is a near futile effort.  It ''forces'' simplification.  When it comes down to it, it seems to me that expressing licenses in a REL that tools can parse and act on, enriching user experience, findability and interactiveness can only be a good thing.  This isn't--I don't think--about license proliferation, as the licenses are already proliferated.  Instead, this seems to be (and here, speaking from experience, so take it as anecdotal), about putting the cat back in the bag in many cases.  Maybe just the industry I work in?  [[User:JonathanMalek|Jonathan]]
*** Jonathan, it may be that the industry you work in, license proliferation is already a problem, in fact, one might even say that it was a problem ''before'' the creation of Creative Commons (CC), and that CC was in some part created to simplify/standardize on a small handful of licenses that would/could be easily understood and reused directly by content authors/creators/publishers *without* necessarily needing business deals (or lawyers potentially) to both *share* content, and *reuse* content. The point of fighting license proliferation is to both discourage *further* proliferation, and to make non-proliferation *easier* (cheaper) and thus more popular over time (as compared to one-off business deals etc.). In addition, technology should not be used to simply rubberstamp an existing practice (e.g. the microformats [[process]] itself contains a lot of critical analyses/simplifications of existing practices), and technology should especially not be used to promote what has been recognized as undesirable (even if common) practices, like license proliferation.  [[User:Tantek|Tantek]] 03:45, 19 August 2009 (UTC)
*** regarding enriching user experience (UX), proliferation does the opposite (makes the user interface *worse*), as it forces users to try to understand more and more different variants of licenses.  What actually enhances/enriches UX/UI is *re-use* of standard licenses which people are comfortable with. This has shown to be true in the open source world, in the wiki world (Wikipedia GFDL/CC-SA recent convergence demonstrates this), and in the content search world with the Creative Commons search interfaces that look for specific *licenses*, rather than expressions of rights. [[User:Tantek|Tantek]] 03:45, 19 August 2009 (UTC)
** The ''requires'' and ''prohibits'' properties should only be seen as refinements of the ''permits'' properties. ccREL is merely expressing licences, on top of copyright, so copyright is always the basis and thus all rights are reserved. Only permissions need to be expressed with ccREL. There is absolutely no need to fully model the permissions/prohibitions/requirements of Copyright. If you only plan to offer copyrighted content without any licenses applied to it, you may want to think about adding an "informative" statement like "all rights reserved". ccREL may not be useful in that case, except perhaps its ability to add cc+ additional information like payments, more permissions, etc. [[User:Patrickp|Patrickp]] 14:14, 18 August 2009 (UTC)
*** Even "refinements" can be viewed as divergence/proliferation and thus still contribute to the anti-pattern. [[User:Tantek|Tantek]] 19:27, 18 August 2009 (UTC)
*** "no need" is irrelevant - the point is that ccREL might even *enable* a specific piece of content to model any of numerous combinations of permissions/prohibitions/requirements, all of which amount to divergent/proliferant licenses, which makes those features undesirable. [[User:Tantek|Tantek]] 19:27, 18 August 2009 (UTC)
*** The only way to avoid content-specific license proliferation is to set the explicit design goal to *exclude* any rights enumeration related *features* (whether permits/prohibits/requires/optional or not), and to design a [[licensing]] microformat that instead only uses licenses by *reference*, with hyperlinks (e.g. to Creative Commons licenses as is existing common practice) to encourage data visibility, as the [[rel-license]] microformat has well established. [[User:Tantek|Tantek]] 19:27, 18 August 2009 (UTC)
* '''Rights Expression Language is proliferant framing''' - "REL" the specific unique aspect of the name of ccREL, "Rights Expression Language", encourages  the framing that it is acceptable to *express* *rights* (more than one, hence combinatorics result) in a (computer) *language*. The effect is highly undesirable as documented in the '''license proliferation anti-pattern''' issue and thus we should not only discourage any re-use of ccREL in microformats, but also discourage any use of ccREL at all, as well as discourage development of a "rights" microformat, because all of those propagate the undesirable license proliferant frame of the "REL" portion of "ccREL". [[User:Tantek|Tantek]]
* '''enumerated values are a known i18n problem.''' The above mapping creates a new en-us content enumeration ('derivative-works', etc). Shown here in <code>abbr</code> form, which as in hCard, will not internationalize acceptably. As per the advice we given to page authors, further use of the [[value-class-pattern]] as a DRY-violating get-out for this should be an absolute last resort to specification authors too. (Personally, I'd favour declaring prescribed enumeration an anti-pattern for future development.) --[[User:BenWard|BenWard]] 22:28, 29 May 2009 (UTC)
** +1 I agree with Ben Ward, new enumerations will likely be problematic and should be avoided. -- [[User:Tantek|Tantek]] 18:02, 31 July 2009 (UTC)
</div>

=== rel item license ===
Since [[rel-license]] already applies to an entire page, we likely need another rel value to indicate that a license only applies to a specific item on or referenced by the page.  Thus:

<code>rel="item-license"</code>

=== class license ===
Licensing information about an item could be contained in an element with class name "license", e.g.

<source lang=html4strict>
<div class="license">
  This 
  <span class="item">
   <a class="url" href="photo.jpg">photograph</a>
  </span>
  is licensed under a
  <a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
   Creative Commons attribution non-commercial 2.0 license
  </a>.
</div>
</source>




=== class license without hyperlink ===
Licensing information about an item could be contained in an element with a class name "license", without a hyperlink to another page, e.g.

<source lang=html4strict>
<div class="license">
Copyright 1996, Example Corporation. All rights reserved.
No part of this work may be reproduced or used in any form, without prior written permission of the
publisher, except in the case of brief quotations embodied in reviews. Making copies of any part of this
work for any purpose other than your own personal use is a violation of United States copyright laws.
For information, contact Example Corporation, 555 East 555th Street, San Francisco, CA 16399.
</div>
</source>

=== class names license and attribution ===

Attribution information could be added with the above-mentioned class name 'attribution':

<source lang=html4strict>
<div class="license">
  This 
  <span class="item">
   <a class="url" href="photo.jpg">photograph</a>
  </span>
  is licensed under a
  <a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
   Creative Commons attribution non-commercial 2.0 license
  </a>.
  Please provide the following attribution with any re-use of the photo:
  <div class="attribution">
   Photo by Mary Smith.
  </div>
</div>
</source>


with hyperlinks in attribution:


<source lang=html4strict>
<div class="license">
  This 
  <span class="item">
   <a class="url" href="photo.jpg">photograph</a>
  </span>
  is licensed under a
  <a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
   Creative Commons attribution non-commercial 2.0 license
  </a>.
  Please provide the following attribution with hyperlinks to the original and author with any re-use of the photo:
  <div class="attribution">
   <a href="photo.jpg">Photo</a> 
   by 
   <a href="http://mary.example.com/">Mary Smith</a>.
  </div>
</div>
</source>


=== item as container ===
It may be possible to simplify even further and only use the containing class "item" with rel="item-license" to indicate the scope of the thing that is being licensed, the license, and any optional attribution.

;<span style="font-size:smaller">short URL for this section</span>
:http://tr.im/ufitc

This section has been extracted and moved to its own page: 

* [[item-license]].

Please see that page for further updates.

== to do ==
* Examples with [[hAtom]] and [[hMedia]]

== see also ==
* [[licensing]]
* [[licensing-examples]]
* [[licensing-formats]]
* [[licensing-brainstorming]]
Templates used on this page:
Template:may (protected)
Template:should (protected)
Return to licensing-brainstorming.
Retrieved from "http://mt.microformats.org/wiki/licensing-brainstorming"
Views

Microformats Wiki

Toolbox

Hey! You're not logged in
