licensing-brainstorming - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:28:50Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:28, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~Licensing Brainstorming~~</entry-title>~~		{{DISPLAYTITLE:Licensing Brainstorming}}

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

Tantek: /* to do */ did some, moved some to item-license page

2010-03-01T01:06:05Z

to do: did some, moved some to item-license page

← Older revision		Revision as of 01:06, 1 March 2010
Line 6:		Line 6:

	== to do ==		== to do ==
	* resort brainstorm proposals according to practicality/feasibility/functionality/usability of proposals		* resort brainstorm proposals according to practicality/feasibility/functionality/usability of proposals, putting [[licensing-brainstorming#item_as_container\|item as container]] at top.
	* extract [[licensing-brainstorming#item_as_container\|item as container]] ~~and write it up as a separate draft~~
	** have [[hNews]] reference the separate draft
	** write-up item-license examples similar to [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#licensing-works microdata works vocabulary] samples/examples (also [http://dev.~~w3.org/html5/md/#examples microdata works vocab to RDF example].)~~
	* post photo of whiteboard brainstorm 2010-055 with Tantek Çelik and Mike Linksvayer and details
	** item
	** attribution (1. on a href means URL to the item including copyright info; 2. on an [[hCard]] means use name of person/org from hCard, and optionally URL for the name if present; 3. else treat it as a name to attribute. may have multiple attribution properties per item.)
	** rel="item-license"
	** item-url

	== Discussion ==		== Discussion ==

Tantek: /* item as container */ moved most evolved/popular brainstorm to its own page

2010-03-01T01:03:30Z

item as container: moved most evolved/popular brainstorm to its own page

@@ Line 343: / Line 343: @@
 :http://tr.im/ufitc
-Here is an example of a chunk of hypertext content that is being licensed:
+This section has been extracted and moved to its own page:
-<source lang=html4strict>
+* [[item-license]].
-To specify a license on an external resource like a photograph, we can use a new class name "item-url" to identify the external resource as being the actual item:
+Please see that page for further updates.
 == to do ==

Tantek: note a few bits of brainstorm updates with Mike Linksvayer

2010-02-25T10:08:56Z

note a few bits of brainstorm updates with Mike Linksvayer

← Older revision		Revision as of 10:08, 25 February 2010
Line 1:		Line 1:
	<entry-title>Licensing Brainstorming</entry-title>		<entry-title>Licensing Brainstorming</entry-title>

	Brainstorming proposals toward a [[licensing]] microformat per the microformats [[process]].		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
			* extract [[licensing-brainstorming#item_as_container\|item as container]] and write it up as a separate draft
			** have [[hNews]] reference the separate draft
			** write-up item-license examples similar to [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#licensing-works microdata works vocabulary] samples/examples (also [http://dev.w3.org/html5/md/#examples microdata works vocab to RDF example].)
			* post photo of whiteboard brainstorm 2010-055 with Tantek Çelik and Mike Linksvayer and details
			** item
			** attribution (1. on a href means URL to the item including copyright info; 2. on an [[hCard]] means use name of person/org from hCard, and optionally URL for the name if present; 3. else treat it as a name to attribute. may have multiple attribution properties per item.)
			** rel="item-license"
			** item-url

	== Discussion ==		== Discussion ==
	~~Set of classes pertinent~~ to ~~supporting~~ licensing and attribution ~~requirements and complements~~. ~~These classes~~ could be used at webpage level or within ~~relevant~~ microformats, e.g., [[media-info]].		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 ===		=== reuse limitations ===

Smyles: /* class license without hyperlink */

2009-09-29T19:34:12Z

class license without hyperlink

@@ Line 258: / Line 258: @@
     Creative Commons attribution non-commercial 2.0 license
    </a>.
 </div>
 </source>

Tantek: /* ccREL issues */ follow-up to Jonathan's questions

2009-08-19T03:46:00Z

ccREL issues: follow-up to Jonathan's questions

← Older revision		Revision as of 03:46, 19 August 2009
Line 229:		Line 229:
	* '''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)		* '''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]]		** 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)		** 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)		*** 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)

JonathanMalek: aren't licenses already proliferated? Can

2009-08-18T23:22:37Z

aren't licenses already proliferated? Can

← Older revision		Revision as of 23:22, 18 August 2009
Line 228:		Line 228:
	<div class="discussion">		<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)		* '''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]]
	** 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)		** 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)		*** 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)

Tantek: /* ccREL issues */ summarize issues, follow-up to "refinement" / "no need" comments, add issue that ccREL name itself is proliferant framing

2009-08-18T19:27:14Z

ccREL issues: summarize issues, follow-up to "refinement" / "no need" comments, add issue that ccREL name itself is proliferant framing

← Older revision		Revision as of 19:27, 18 August 2009
Line 227:		Line 227:
	==== ccREL issues ====		==== ccREL issues ====
	<div class="discussion">		<div class="discussion">
	* 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)		* '''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)
	** 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 ~~licences~~ 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)		** 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)
	* 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)		*** 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)		** +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>		</div>

Patrickp: /* reuse CC vocabulary */

2009-08-18T14:14:18Z

reuse CC vocabulary

← Older revision		Revision as of 14:14, 18 August 2009
Line 205:		Line 205:
	** legal-code ? (rel value, not class)		** legal-code ? (rel value, not class)
	** ''more-permissions'' * (rel value, not class)		** ''more-permissions'' * (rel value, not class)
	** ''permits'' * ("reproduction" \| "distribution" \| "derivative-works" \| "high-income-nation-use" \| "sharing")		** ''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")		** ''requires'' * ("copyright-notices" \| "attribution" \| "share-alike" \| "source-code")
	** ''prohibits'' * ("commercial-use")		** ''prohibits'' * ("commercial-use")
Line 228:		Line 228:
	<div class="discussion">		<div class="discussion">
	* 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)		* 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)
			** 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 licences 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)
	* 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)		* 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)		** +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)

Tantek: /* item as container */ explicitly note use of rel item-license, style shortURL ref better

2009-07-31T20:06:42Z

item as container: explicitly note use of rel item-license, style shortURL ref better

← Older revision		Revision as of 20:06, 31 July 2009
Line 299:		Line 299:

	=== item as container ===		=== item as container ===
	;short URL for this section		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		:http://tr.im/ufitc

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

	Here is an example of a chunk of hypertext content that is being licensed:		Here is an example of a chunk of hypertext content that is being licensed:

← Older revision		Revision as of 03:46, 19 August 2009
Line 229:		Line 229:
	* '''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)		* '''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]]		** 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)		** 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)		*** 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)

← Older revision		Revision as of 23:22, 18 August 2009
Line 228:		Line 228:
	<div class="discussion">		<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)		* '''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]]
	** 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)		** 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)		*** 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)

← Older revision		Revision as of 19:27, 18 August 2009
Line 227:		Line 227:
	==== ccREL issues ====		==== ccREL issues ====
	<div class="discussion">		<div class="discussion">
	* 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)		* '''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)
	** 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 ~~licences~~ 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)		** 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)
	* 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)		*** 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)		** +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>		</div>