CreativeCommons RDF Permission vs. Prohbition?

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

<rdf:Description 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"/>
</rdf:Description>


"Derivative Works" are defined by type as Permissions

<rdf:Description 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"/>
</rdf:Description>


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
<cc:prohibits 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
<cc:prohibits rdf:resource="http://creativecommons.org/
ns#CommercialUse"/>
<cc:permits 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

<rdf:Description 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"/>
</rdf:Description>

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".
 
T

The Magpie

Andy said:
What's the difference between a Permission and a Prohbition?
"Permission" specifies what you *are* allowed to do with a document
and presumes anything else is not allowed. "Prohibition" specifies
what you are *not* allowed to do and presumes everything else is
permitted. Does that help?
 
A

Andy Dingley

"Permission" specifies what you *are* allowed to do with a document
and presumes anything else is not allowed. "Prohibition" specifies
what you are *not* allowed to do and presumes everything else is
permitted.

Are you discussing permits or Permission here?

For the property (lower case, by convention) I'd obviously agree with
your description. However my point is about "the thing that is
constrained" rather than the use being made or forbidden for it. Why
do we need to implictly categorize these too? Is it either necessary
or useful to do this? What's to stop us merely having a list of
"actions" and then making these the objects of appropriate properties,
the prohibition / permission being based on the property _alone_?
 
T

The Magpie

Andy said:
Are you discussing permits or Permission here?

For the property (lower case, by convention) I'd obviously agree with
your description. However my point is about "the thing that is
constrained" rather than the use being made or forbidden for it. Why
do we need to implictly categorize these too? Is it either necessary
or useful to do this? What's to stop us merely having a list of
"actions" and then making these the objects of appropriate properties,
the prohibition / permission being based on the property _alone_?
Its a bit of both, Andy - from your comments, I would guess that you
are American and more used to American legal systems where the sort of
nit-picking layering of restrictions and permissions provides a
field-day and cash-cow for the lawyers. The system of Creative
Commons, however, is designed from the ground up to be very different
and to apply very differently.

The basis of the Commons is twofold: first, the Berne Convention on
copyright (essentially. its yours because you did it and there is no
need for any sort of registration or statement to that effect) and the
Open Systems freedom to do what they hell you like with something as
long as you admit where it comes from and don't sell it as if it was
your own. On top of that, Creative Commons then lays down *specific*
permissions and restrictions on how it can be used which may vary a
little from country to country so that the licence can be applied
across the whole world.

If you are thinking of using it, I would also check out the GNU GPLv4
since that might be a better basis for work that you are doing if you
would like to distribute it. In either case, it is well worth reading
up on the details of each licence and checking case law that has been
applied (both have been upheld internationally but in slightly
different ways).
 
J

Johannes Koch

The said:
Its a bit of both, Andy - from your comments, I would guess that you
are American and more used to American legal systems where the sort of
nit-picking layering of restrictions and permissions provides a
field-day and cash-cow for the lawyers. The system of Creative
Commons, however, is designed from the ground up to be very different
and to apply very differently.

Andy's question, as I read it, is an RDF question, not a question about
CC licencing in general.
The basis of the Commons is twofold: first, the Berne Convention on
copyright (essentially. its yours because you did it and there is no
need for any sort of registration or statement to that effect) and the
Open Systems freedom to do what they hell you like with something as
long as you admit where it comes from and don't sell it as if it was
your own. On top of that, Creative Commons then lays down *specific*
permissions and restrictions on how it can be used which may vary a
little from country to country so that the licence can be applied
across the whole world.

If you are thinking of using it, I would also check out the GNU GPLv4
since that might be a better basis for work that you are doing if you
would like to distribute it. In either case, it is well worth reading
up on the details of each licence and checking case law that has been
applied (both have been upheld internationally but in slightly
different ways).

Now, what's the difference between the Permission and Prohbition _types
in RDF_?
 
A

Andy Dingley

Andy's question, as I read it, is an RDF question, not a question about
CC licencing in general.

It's about both, but mostly about the piece in the middle, the
_schema_ that the CC project have put together and that they use to
describe their own licences. My work is about software, so the CC
licences aren't a good choice for it. Besides which, I have to deal
with the 20 or 30 different licences that have already been applied to
the 3rd party code I'm using.

Few software licences, except CC, have a machine-readable version. Gnu
have (apparently - still haven't found it) only just ported their
licences for this, and have used an extended version of the CC schema
to do so. For the others, I need to set up my own <cc:License>
description documents for them. Some of these appear to need extension
to the existing CC vocabulary.

From there I annotate our Ivy repository, do some reasong on the top
and can show that our products are fit for distribution and can list
the set of licences I need to acknowledge or redistribute with them.


"The Commons" isn't really my focus today. I'm not using their
licences, just their schema. It looks like this:

* Permission
o DerivativeWorks
o HighIncomeNationUse
o Distribution
o Sharing
o Reproduction
* Prohibition
o CommercialUse
* Requirement
o SourceCode
o ShareAlike
o Copyleft
o LesserCopyleft
o Attribution
o Notice

The "default" behaviour for any CC-based licence might be said to be
that of the empty <cc:License> document, ie purely those constraints
that are inherited from the schema. A specific licence can of course
change this, such as by requiring Attribution, permitting Derivatives
etc.

As it is though, this "default" is broadly Berne Convention-like,
traditional restrictive copyright. It's a long way from the open,
copyleft or "four freedoms" world.

You can of course express such an open licence using CC schema (and CC-
by-sa has been there and done it) but you'll need to explicitly state:
<cc:permits rdf:resource="http://creativecommons.org/
ns#DerivativeWorks"/>
<cc:permits rdf:resource="http://creativecommons.org/
ns#Reproduction"/>
<cc:permits rdf:resource="http://creativecommons.org/
ns#Distribution"/>
<cc:requires rdf:resource="http://creativecommons.org/
ns#Attribution"/>
<cc:requires rdf:resource="http://creativecommons.org/ns#ShareAlike"/ <cc:requires rdf:resource="http://creativecommons.org/ns#Notice"/>

This is probably a good thing, as it makes for a nice clear expression
within the licence itself (no schema needed if the human wetware is
trying to infer restrictions by eyeball) where it's obvious that the
licence permits Reproduction & Distribution.

CommercialUse is less obvious - it's just not mentioned. It needs
access to the schema to inferthat it's permitted as it's not
prohibited.

Now this is where it gets confusing - what about
HighIncomeNationUse ? Berne Convention permits this (it's in Berne
after all!) and I believe that CC-by-sa does too. Yet as I read the
vocabulary it's a Permission and so I don't get to do it unless the
licence explicitly states it?!

So where am I going wrong here? And what is good practice when
extending these vocabularies to encompass new concepts in licensing
models? I'm assuming a useful goal is "Adding new vocabulary terms
should not change the implied constraints of existing licences", yet
how do I achieve this? Can I only do it by assuming that,
"Everything that wasn't explictly forbidden previously was really
permitted, even if you didn't and wouldn't ever have exercised that
right"?

Going back to my Jaxen example, how do I represent that licence and
express the "No endorsements" constraint?
<cc:prohibits rdf:resource="http://example.org/
licensing#Endorsement"/>

Do I need to add this to other licences that I'm modelling too? Must /
Should I?
 
A

Andy Dingley

If you are thinking of using it, I would also check out the GNU GPLv4
since that might be a better basis for work that you are doing if you
would like to distribute it.

Tried that
http://www.gplv4.org/

Still can't find the RDF / ccREL expression of GPL, but it would look
strangely at home on that page.
 
T

The Magpie

Andy said:
Andy's question, as I read it, is an RDF question, not a question about
CC licencing in general.

It's about both, but mostly about the piece in the middle, the
_schema_ that the CC project have put together and that they use to
describe their own licences. [snip complex bit]

From what you say, Andy, I'd say you got to the same point I did with
my own published XML schemas and submissions for Dublin Core and I
suspect your best answer will be the same as I opted for - hire a
lawyer to make sure it does what you need.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top