licensing-brainstorming

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 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 "item as container" brainstorm proposal, and rel-item-license. See 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.

Overly descriptive strawman not intended to conform with any convention	Existing class(es); source	Notes
work title	fn; hCard	See examples#title
attribution name, creator?	author; hAtom, hcard	Might be a vcard with fn, may also be an organization See examples#attribution
attribution url	url; hCard	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? See examples#link
donation url	payment; rel-payment offer; hListing	How to disambiguate from commercial licensing and purchase? See examples#donation
commercial licensing url	payment; rel-payment sell, offer; hListing copyright; HTML LinkType	How to disambiguate from donation and purchase? See examples#commercial
purchase url	payment; rel-payment sell, offer; hListing	How to disambiguate from donation and commercial licensing? See examples#purchase
content hash	checksum, sha1; hash-examples	See examples#hash
provenance url		See examples#provenance
parent work url?, derivitave-source		Should this be a url? Maybe it should be a TBD "media" microformat which may be otherwise described. See examples#derivative Probably should be a URL -- a uf can have a #URL if it has an id.
attribution, copied-source		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 Attribution Challenges
source		Like 'copied-source' but points to the original source.

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:

Media source type	Format	Notes
Internet source	An URL
Person	hcard
Publication (book, magazine, etc.)	citation	Citation appears to be heavily weighed towards academia but it looks like it should work for most purposes
Film/Video	??	I'm not sure about this one. Would citation stretch over visual media? Perhaps media-info?

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:

1. 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).
2. 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):

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

media info with attribution

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

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

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.

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

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:

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

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

• 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 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. 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? 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. 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. 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. Patrickp 14:14, 18 August 2009 (UTC)
    • Even "refinements" can be viewed as divergence/proliferation and thus still contribute to the anti-pattern. 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. 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. 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". Tantek
• enumerated values are a known i18n problem. The above mapping creates a new en-us content enumeration ('derivative-works', etc). Shown here in abbr 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.) --BenWard 22:28, 29 May 2009 (UTC)
  • +1 I agree with Ben Ward, new enumerations will likely be problematic and should be avoided. -- Tantek 18:02, 31 July 2009 (UTC)

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:

rel="item-license"

class license

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

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

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.

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

class names license and attribution

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

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

with hyperlinks in attribution:

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

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.

short URL for this section

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