A
Andy Dingley
What's the difference between a Permission and a Prohbition?
(in ref to)
http://creativecommons.org/ns
http://creativecommons.org/schema.rdf
permits vs. prohbits (lower case, properties) is obvious. One allows
some condition of the licence, the other forbids it.
However there are also a Permission and a Prohbition (capitalised,
thus Resources (in the RDF sense))
The comments for each are straightforward and are phrased in terms of
"the _thing_ that is permitted / prohibited" (rather than the act of
permission / prohibition), which makes sense for resources.
Permission "an action that may or may not be allowed or desired"
Prohbition "something you may be asked not to do"
What's puzzling me though is the fact that these form a set of three
(with Requirement) and that while Requirements are something of a
disjoint set with them, there's clearly a large overlap between those
that (in another world, where CC had been stated differently) might in
different licences be considered as either a Permission or a
Prohbition.
"Commercial Use" is defined by type as a Prohibition
<rdfescription rdf:about="http://creativecommons.org/
ns#CommercialUse">
<rdfs:comment xml:lang="en-US">exercising rights for commercial
purposes</rdfs:comment>
<rdfs:label xml:lang="en-US">Commercial Use</rdfs:label>
<rdf:type rdf:resource="http://creativecommons.org/ns#Prohibition"/>
</rdfescription>
"Derivative Works" are defined by type as Permissions
<rdfescription rdf:about="http://creativecommons.org/
ns#DerivativeWorks">
<rdfs:comment xml:lang="en-US">distribution of derivative works</
rdfs:comment>
<rdfs:label xml:lang="en-US">Derivative Works</rdfs:label>
<rdf:type rdf:resource="http://creativecommons.org/ns#Permission"/>
</rdfescription>
So for the NC-ND licence (which forbids both)
http://creativecommons.org/licenses/by-nc-nd/3.0/rdf
only the Prohibition needs to be explicitly stated
<ccrohibits rdf:resource="http://creativecommons.org/
ns#CommercialUse"/>
Derivative Works aren't described in the explicit licence and are only
forbidden by their omission and the implied need for this right to be
stated if it's to be permitted.
Similarly "No-commercial" in RDF must state both triples
http://creativecommons.org/licenses/by-nc/3.0/rdf
<ccrohibits rdf:resource="http://creativecommons.org/
ns#CommercialUse"/>
<ccermits rdf:resource="http://creativecommons.org/
ns#DerivativeWorks"/>
whilst "No-derivatives" doesn't need to state either
http://creativecommons.org/licenses/by-nd/3.0/rdf
This approach would seem to have a few drawbacks:
* It's unclear to humans. c.f. XBRL and recent issues about use of
sign and high error rates for US tax filing. In particular it's
different to the naming, legalese, human description and even the URI
for this licence. If the licence descriptions (e.g. by-nc-nd-sa)
generally state the requirements and prohibitions and can omit the
permissions, why should this be different for derivative works when
described through RDF?
* It distinguishes between uses of the resource in a way that seems
arbitrary for the resource. Why distinguish them at all? We already
have a property for identifying the use we're referring to.
* It requires access to the schema before the implied content of the
licence document can be understood.
and today's problem for me:
* It's unclear how to extend it.
The Jaxen licence explicitly forbids "endorsement".
http://jaxen.codehaus.org/license.html
Now how should I best represent that within a locally extended
licensing schema? Permission or Prohibition?
(and does using them as an example here qualify as "endorsement"?!)
As my (local) RDF representation of Jaxen would appear to deserve a
local statement of the fact (I have no wish to go through and annotate
all my other licence representations for this new constraint), then
that suggests that it's a Prohibition
<rdfescription rdf:about="http://example.com/licensing/
rights#Endorsement">
<rdfs:comment xml:lang="en-GB" >Prohibits the name of the
original product or its authors to be used to endorse the derivative.
e.g. this is forbidden for the Jaxen licence:
"Neither the name of the Jaxen Project nor the names of its
contributors may be used to endorse or promote products
derived
from this software without specific prior written permission."
</rdfs:comment>
<rdfs:label xml:lang="en-GB" >Endorsement</rdfs:label>
<rdf:type rdf:resource="http://creativecommons.org/
ns#Prohibition"/>
</rdfescription>
Yet that now suggests that all the other licences that don't
explicitly forbid this are now permitting it! Surely not the
situation that "real world" assumptions would suggest, even though few
licences bother to explicitly state this. Or is that simply a
defensible real world position, if only I were thick-skinned and
weaselish enough? (I'm English, I'd never be this presumptuous!)
A licence procesor that was available of my "new extended licensing
schema" might be made smart enough to recognise that the default
behaviour for this new Endorsement ought to be inferred from the
schema in effect for the overall licensing schema namespace - yet this
is RDF, not merely XML, and so practice is that the granularity of
such a schema follows the namespace closely per XML node, i.e. with
granularity at the property / Resource level, not for any sort of
"overall schema".
(in ref to)
http://creativecommons.org/ns
http://creativecommons.org/schema.rdf
permits vs. prohbits (lower case, properties) is obvious. One allows
some condition of the licence, the other forbids it.
However there are also a Permission and a Prohbition (capitalised,
thus Resources (in the RDF sense))
The comments for each are straightforward and are phrased in terms of
"the _thing_ that is permitted / prohibited" (rather than the act of
permission / prohibition), which makes sense for resources.
Permission "an action that may or may not be allowed or desired"
Prohbition "something you may be asked not to do"
What's puzzling me though is the fact that these form a set of three
(with Requirement) and that while Requirements are something of a
disjoint set with them, there's clearly a large overlap between those
that (in another world, where CC had been stated differently) might in
different licences be considered as either a Permission or a
Prohbition.
"Commercial Use" is defined by type as a Prohibition
<rdfescription rdf:about="http://creativecommons.org/
ns#CommercialUse">
<rdfs:comment xml:lang="en-US">exercising rights for commercial
purposes</rdfs:comment>
<rdfs:label xml:lang="en-US">Commercial Use</rdfs:label>
<rdf:type rdf:resource="http://creativecommons.org/ns#Prohibition"/>
</rdfescription>
"Derivative Works" are defined by type as Permissions
<rdfescription rdf:about="http://creativecommons.org/
ns#DerivativeWorks">
<rdfs:comment xml:lang="en-US">distribution of derivative works</
rdfs:comment>
<rdfs:label xml:lang="en-US">Derivative Works</rdfs:label>
<rdf:type rdf:resource="http://creativecommons.org/ns#Permission"/>
</rdfescription>
So for the NC-ND licence (which forbids both)
http://creativecommons.org/licenses/by-nc-nd/3.0/rdf
only the Prohibition needs to be explicitly stated
<ccrohibits rdf:resource="http://creativecommons.org/
ns#CommercialUse"/>
Derivative Works aren't described in the explicit licence and are only
forbidden by their omission and the implied need for this right to be
stated if it's to be permitted.
Similarly "No-commercial" in RDF must state both triples
http://creativecommons.org/licenses/by-nc/3.0/rdf
<ccrohibits rdf:resource="http://creativecommons.org/
ns#CommercialUse"/>
<ccermits rdf:resource="http://creativecommons.org/
ns#DerivativeWorks"/>
whilst "No-derivatives" doesn't need to state either
http://creativecommons.org/licenses/by-nd/3.0/rdf
This approach would seem to have a few drawbacks:
* It's unclear to humans. c.f. XBRL and recent issues about use of
sign and high error rates for US tax filing. In particular it's
different to the naming, legalese, human description and even the URI
for this licence. If the licence descriptions (e.g. by-nc-nd-sa)
generally state the requirements and prohibitions and can omit the
permissions, why should this be different for derivative works when
described through RDF?
* It distinguishes between uses of the resource in a way that seems
arbitrary for the resource. Why distinguish them at all? We already
have a property for identifying the use we're referring to.
* It requires access to the schema before the implied content of the
licence document can be understood.
and today's problem for me:
* It's unclear how to extend it.
The Jaxen licence explicitly forbids "endorsement".
http://jaxen.codehaus.org/license.html
Now how should I best represent that within a locally extended
licensing schema? Permission or Prohibition?
(and does using them as an example here qualify as "endorsement"?!)
As my (local) RDF representation of Jaxen would appear to deserve a
local statement of the fact (I have no wish to go through and annotate
all my other licence representations for this new constraint), then
that suggests that it's a Prohibition
<rdfescription rdf:about="http://example.com/licensing/
rights#Endorsement">
<rdfs:comment xml:lang="en-GB" >Prohibits the name of the
original product or its authors to be used to endorse the derivative.
e.g. this is forbidden for the Jaxen licence:
"Neither the name of the Jaxen Project nor the names of its
contributors may be used to endorse or promote products
derived
from this software without specific prior written permission."
</rdfs:comment>
<rdfs:label xml:lang="en-GB" >Endorsement</rdfs:label>
<rdf:type rdf:resource="http://creativecommons.org/
ns#Prohibition"/>
</rdfescription>
Yet that now suggests that all the other licences that don't
explicitly forbid this are now permitting it! Surely not the
situation that "real world" assumptions would suggest, even though few
licences bother to explicitly state this. Or is that simply a
defensible real world position, if only I were thick-skinned and
weaselish enough? (I'm English, I'd never be this presumptuous!)
A licence procesor that was available of my "new extended licensing
schema" might be made smart enough to recognise that the default
behaviour for this new Endorsement ought to be inferred from the
schema in effect for the overall licensing schema namespace - yet this
is RDF, not merely XML, and so practice is that the granularity of
such a schema follows the namespace closely per XML node, i.e. with
granularity at the property / Resource level, not for any sort of
"overall schema".