Network Working Group I. Maturana
Internet-Draft I. Robredo
Expires: December 30, 2004 in3activa
July 2004
Scope Modifiers in Intellectual Property Declarations
draft-maturana-ipscope-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The purpose of this RFC is to focus discussion on intellectual
property problems in the Internet.
This document introduces and defines scope modifiers to be used in
intellectual property declarations. These modifiers abstract the
ownership behavior of resources available in interoperable
environments, such as the Internet.
Maturana & Robredo Expires December 30, 2004 [Page 1]
Internet-Draft Internet(C) July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Intended audience . . . . . . . . . . . . . . . . . . . . 3
1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Requirement notation . . . . . . . . . . . . . . . . . . . 4
2. Semantics of interoperability . . . . . . . . . . . . . . . . 5
2.1 An analogy: the logic of classes . . . . . . . . . . . . . 5
2.2 Categories of operations . . . . . . . . . . . . . . . . . 6
2.3 Reciprocity and equivalence . . . . . . . . . . . . . . . 8
3. Definition of scope modifiers . . . . . . . . . . . . . . . . 10
3.1 PRIVATE modifier . . . . . . . . . . . . . . . . . . . . . 11
3.2 PROTECTED modifier . . . . . . . . . . . . . . . . . . . . 11
3.3 INTERNET modifier . . . . . . . . . . . . . . . . . . . . 11
3.4 PUBLIC modifier . . . . . . . . . . . . . . . . . . . . . 12
3.5 Scope inheritance . . . . . . . . . . . . . . . . . . . . 13
4. Syntax of ownership declarations . . . . . . . . . . . . . . . 14
4.1 Formal declaration . . . . . . . . . . . . . . . . . . . . 14
4.2 Property line . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Attribution line . . . . . . . . . . . . . . . . . . . . . 15
4.4 License line . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Long names and short names of modifiers . . . . . . . . . 17
5. Scope modifiers implementation . . . . . . . . . . . . . . . . 18
5.1 Handwritten implementation: the default modifier . . . . . 18
5.2 HTML implementation: the SCOPE tag . . . . . . . . . . . . 18
5.3 Dublin Core implementation . . . . . . . . . . . . . . . . 19
5.4 Using licenses . . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Maturana & Robredo Expires December 30, 2004 [Page 2]
Internet-Draft Internet(C) July 2004
1. Introduction
This document defines four scope modifiers to be used in intellectual
property declarations of resources available in interoperable
environments, such as Internet. They help to abstract the ownership
behavior of these resources.
We proceed in three steps. We characterize the semantics of the
operations applicable on resources, based on the pair (URI,
ownership). Then we determine the modifiers that control the
interoperability of resources. Finally we describe the general
syntax of the ownership declarations that use these modifiers. An
fourth chapter will introduce various implementations of the
described syntax.
Four modifiers are defined. The PUBLIC, PROTECTED and PRIVATE
modifiers are transpositions of the class programming equivalents. A
fourth modifier -- the INTERNET modifier -- operates like an
all-country exclusion: it allows the transformation, but does not
allow the reproduction, of a private resource exhibited in
interoperable environments, such as Internet.
As an example, the following declaration illustrates a typical usage
of the PUBLIC and PRIVATE modifiers. This declaration asserts that
OwnerB's private resource (the client resource) is a derivative
version of OwnerA's public resource (the server resource).
Private(C) 2004, OwnerB (http://www.client.com)
& Public(C) 2002-2004, OwnerA (http://www.server.com)
All rights reserved.
1.1 Intended audience
No special knowledge is expected from readers. However, some
concepts have a background and rely on a vocabulary that is more
familiar to specialized readers:
o Intellectual property rights, as defined for protected works by
the Berne Convention [BERNE].
o Class modifiers such as Public, Private and Protected, as defined
in Class programming languages; [CPPREF]
1.2 Definitions
INTELLECTUAL PROPERTY BASED OBJECT (IP OBJECT) is an instance of a
work, as defined by Berne Convention (Art. 2), and the laws of the
Maturana & Robredo Expires December 30, 2004 [Page 3]
Internet-Draft Internet(C) July 2004
countries of the Berne Union [BERNE].
RESOURCE is an IP Object defined unambiguously in an interoperable
environment by two properties: its URI and an ownership declaration.
More strictly, a resource is an interface defined by the pair (URI,
ownership) of an IP object made available in an interoperable
universe
OWNERSHIP is a resource property, defined by the Berne Convention
(Art. 5), and the laws of the countries of the Berne Union [BERNE].
URI is a resource property, the Universal Resource Identifier of an
IP object, defined in [RFC2396].
SCOPE (OF OWNERSHIP), as used in this document, determines the
resource behavior in regard of specific operations: exhibition
(instantiation), execution (performance), reproduction (copy) and
transformation (derivation). Brackets only denote synonyms for
operations defined in this document.
SCOPE MODIFIER, is a conventional token attached to an ownership
declaration, used to alter the behavior of the resource in an
interoperable environment.
The aim of this document is to define and to describe such scope
modifiers.
SERVER and CLIENT RESOURCES. A server resource refers to the
original resource, which has been reproduced or transformed, to
create a client resource.
A client resource is the resulting reproduction or transformation of
a server resource.
A version is also a client resource, which designates specifically
the result of the transformation of the server resource.
INTEROPERABILITY is defined following the IEEE Standard Computer
Dictionary: "the ability of two or more systems or components
("resources") to exchange information and to use the information that
has been exchanged" [IEEE 90].
INTERNET, is an interoperable environment of resources.
In this document, INTERNET is also the conventional name of a scope
modifier.
1.3 Requirement notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Maturana & Robredo Expires December 30, 2004 [Page 4]
Internet-Draft Internet(C) July 2004
2. Semantics of interoperability
This first chapter will analyze the semantic of the operations
applicable on resources. Next chapter defines the scope modifiers
that alter the behavior of resources; and the last chapter describes
the general syntax of the ownership declarations.
2.1 An analogy: the logic of classes
As a starting point, we present an analogy between Resources
declarations and Class declarations used in class programming
languages. This analogy is not required to fully understand this
document.
Given the "(c) year, author" expression, the legal mention to the
Country is implicit. Indeed, we could write:
"France (c) 2004, I.Robredo"
In our example, "Country" is a virtual base class, from which we
derive a special rightsholder class: the class "I.Robredo". Each
instance of this Rightsholder class is a concrete IP Object,
identified unambiguously by an URI. For example, the URI of a
manuscript or a song is the title, the author's name and the date.
The declaration above may be read as follow:
"France (c) 2004, I.Robredo"
Is an ownership declaration of an IP object, where:
France is the name of the virtual, country base class.
Optional. By default, the author's country.
I.Robredo is the name of the rightsholder class,
derived from the country class
(usually the Author's name, but can be any
entity).
... 2004 is an instance of the I.Robredo class. The
IP object itself is defined by the 2004 version
(along with the title, the author's name, ...).
An ownership declaration can be used when the rightsholder wants to
make available an IP Object in an interoperable environment, under
specific conditions of ownership. This object is called a resource.
Maturana & Robredo Expires December 30, 2004 [Page 5]
Internet-Draft Internet(C) July 2004
Two properties will determine the resource behavior in the
interoperable environment: its URI and the ownership declaration.
Before being available, the resource is unknown and the ownership
declaration is not even required. This declaration is really
required to allow some interoperations on the resource. In other
words, the ownership declaration is used to determine or to alter
the interoperability of the resource.
In Class programming languages, special modifiers attached to Class
declarations are used to determine the results of operations on the
classes and on the object instances. In other words, these modifiers
can define the semantics of the relations between classes or between
objects. This document shows that similar conventions can be applied
to the resources exhibited in interoperable environments, such as
Internet.
2.2 Categories of operations
A resource is defined by a couple of properties: its URI and its
ownership declaration.
Some relations may be identified between these properties:
o The same URI cannot point resources from different rightsholders.
o Two URIs may point to either the same or duplicated resources.
o Different rightsholders cannot attach the same URI to their
ownership declaration.
All these relations are contained in the answers to the following two
questions. For any operation:
o Will the operation on a resource create a second URI?
o In case of URI creation, is there a separate ownership on the
client resource ?
Four operations are defined as follows (alias names are
parenthesized):
Maturana & Robredo Expires December 30, 2004 [Page 6]
Internet-Draft Internet(C) July 2004
EXHIBITION (Instantiation) The Owner instantiates an IP Object
by defining its URI and ownership properties.
Exhibition of the resource is always accomplished by
the rightsholder (for example: the author).
EXECUTION (Performance) There is no URI creation. A volatile
instance of the IP Object is performed.
Whether the performer is the rightsholder or another
different person, the ownership of this volatile
resource remains the same, and belongs to the original
rightsholder.
REPRODUCTION (Copy) A new, persistent URI is created, and the
resource exhibited under this new URI is called a
"client resource".
Whether the underlying object under each URI is the
same object or a duplicate object, the ownership of
both server and client resources remains the same, and
belongs to the original rightsholder.
TRANSFORMATION (Derivation) A new, persistent client resource
is created, with separate properties (URI, ownership).
This client resource is called a "version" of the
original server resource.
Even whether the rightsholder of both server and
client resources is the same person, the ownership
attached to the version resource is different from
the ownership of the original resource.
The ownership declaration on the version is asserted
by the exhibitor of the resource.
The following table resumes the above relations between URI and
ownership:
Operation | Question 1: Question 2:
| Is there a 2nd In case of URI creation, is
| URI creation? there a separate ownership?
----------------|--------------------------------------------
EXHIBITION | No -
EXECUTION | No -
|
REPRODUCTION | Yes No
TRANSFORMATION | Yes Yes
----------------|--------------------------------------------
Maturana & Robredo Expires December 30, 2004 [Page 7]
Internet-Draft Internet(C) July 2004
2.3 Reciprocity and equivalence
This section is not required to fully understand this document, and
it refers explicitly to the 5 first articles of the Berne Convention.
[BERNE].
The exhibition and execution operations require some explanations.
o Exhibition is a pragmatic equivalent of the verb "creation", which
is not defined by itself, but it is implied by Berne-A2.2, as a
work fixed in a form. Whether a work is published or not
(Berne-A3,1a), it can be exhibited.
The word exhibition is a shorthand to describe the instantiation
of a resource under 2 coordinates: its URI and its ownership
declaration. When an IP object is instantiated under the pair
(URI, ownership declaration), this object becomes accessible and
it is possible to inter-operate with it.
o Execution is a synonym for performance, which is not defined by
itself, but it is implied by Berne-A3,3: the performance of a
protected work shall not constitute publication. We choose the
word "execution" because it is typically used to describe software
execution, but it could be used for the recitation of a poetry, or
to describe the application of this document on Internet resources
as well.
Otherness is the key concept to differentiate exhibition and
execution: the person who executes a resource is not required to be
the same person who exhibits it. The exhibitor and the performer of
the work can be different persons. For example, given a computer
software, we say that only the rightsholder can exhibit the source
code, while any (authorized) person can execute the object code.
Otherness is the basis of two complementary principles: the
reciprocity in protection given by countries (Berne-A3 and A5) and
the equivalence in ownership of transformed resources (Berne A2.3).
Both principles are governed by an explicit non-damaging restriction:
client ownership cannot make prejudice to server ownership.
We say that this non-damaging rule governs the "inheritance" of
resource behaviors.
o Any reproduction or transformation of an exhibited work can be
exhibited as well (or it cannot be reproduced nor transformed).
o If the server resource can be executed, any client resource
(either transformed or reproduced) can be executed as well.
o Allowing the reproduction of a server resource under a different
URI will imply that the duplicate resource can be reproduced as
well.
Ideally, allowing the transformation of a resource does not imply
Maturana & Robredo Expires December 30, 2004 [Page 8]
Internet-Draft Internet(C) July 2004
that the derivative resource can be transformed as well. There is a
separate ownership between both server and client resources, in case
of transformation. However, the non-damaging rule still works here,
either explicitly, or implicitly:
o The non-damaging rule can be used to explicitly enforce the
inheritance: transformation of the server resource will be granted
only if the client resource will also allow the transformation.
Otherwise, transformation of the server resource is forbidden.
o Without an agreement, the non-damaging rule still works like a
safeguard of both reciprocity and equivalence principles.
Everything allowed for a server resource is expected to be
allowed for client resources, while anything excluded for the
server will be always excluded for clients. For example,
translation is allowed for a book, but some languages are
excluded. A translator cannot allow re-translation to the already
excluded languages; and trying to prevent the re-translation to
even more languages is unenforceable.
The non-damaging rule can enforce the inheritance. The same rule can
also alter the default reciprocity and equivalence behaviors. In
this case, the way to alter the default inheritance mechanism is
using scope modifiers.
Maturana & Robredo Expires December 30, 2004 [Page 9]
Internet-Draft Internet(C) July 2004
3. Definition of scope modifiers
In the previous chapter, we analyzed the semantics of
inter-operations on resources defined by the pair (URI, ownership).
In this chapter, we define the modifiers that are used to alter the
resource behaviors. The general syntax of the ownership declarations
will be described in the next chapter.
There is a formal relationship between the URI property and the
EXECUTION or REPRODUCTION operations. A second URI is always
attached to all reproductions of the resource. In other words, the
difference between a simple execution and a true reproduction raises
when a new URI is defined for the copied resource.
Conversely, there is a semantic relationship between the ownership
property and the EXHIBITION and TRANSFORMATION operations. An
exhibited resource is always managed by its rightsholder. However, a
true transformation implies a second user, which in turn, has a
complete ownership on the version produced.
The following summarizes REPRODUCTION and TRANSFORMATION operations,
and how they determines a new URI creation, or a separate ownership,
or both:
Operation | Separate Separate
| URI? ownership?
------------------|--------------------------------
REPRODUCTION | Yes No
TRANSFORMATION | Yes Yes
------------------|--------------------------------
Then we create the truth table of REPRODUCTION and TRANSFORMATION
capabilities to identify each entry with four scope modifiers:
REPRODUCTION TRANSFORMATION | SCOPE is
------------------------------------------------
No No | PRIVATE
Yes No | PROTECTED
No Yes | INTERNET
Yes Yes | PUBLIC
------------------------------------------------
The following table is the same than above, but it is possible to
read it out in a more natural way.
Maturana & Robredo Expires December 30, 2004 [Page 10]
Internet-Draft Internet(C) July 2004
The symbols '-' and '+' mean that the operation is denied, or
allowed, respectively. The symbol '-' can be read like 'not', while
the symbol '+' correspond to a silence (a consent).
The resource is | When the resource can be
------------------------------------------------
PRIVATE | -REPRODUCED and -TRANSFORMED
PROTECTED | +REPRODUCED but -TRANSFORMED
INTERNET | -REPRODUCED but +TRANSFORMED
PUBLIC | +REPRODUCED and +TRANSFORMED
------------------------------------------------
This truth table shows clearly that the space allocated to the
INTERNET modifier is a logical imperative of the semantics of
interoperability.
3.1 PRIVATE modifier
The PRIVATE modifier means that no secondary URI, and no separate
ownership are allowed for the resource. No reproduction, and no
transformation are allowed.
By default, the exhibition and the execution of a PRIVATE resource is
restricted to the rightsholder.
3.2 PROTECTED modifier
The PROTECTED modifier means that the reproduction of the resource is
allowed under a client URI, but no separate ownership is granted.
Reproduction is allowed, but transformation is forbidden.
The client resource inherits the same scope than server. By default,
it is possible to make news reproductions of the client resource.
A protected resource is typically managed with a license. For
example, a license can be used in a collective project that
encourages the reproduction of the work. A protected license can
even create a "mixed scope", by allowing some transformations
capabilities to resources.
3.3 INTERNET modifier
The INTERNET modifier means that the transformation of the resource
is allowed, but its reproduction is forbidden.
The INTERNET modifier can be defined as a "country excluder". This
Maturana & Robredo Expires December 30, 2004 [Page 11]
Internet-Draft Internet(C) July 2004
exclusion rationale highlights the fact that the server resource
appears just like a private resource under the laws of all countries.
In other words, the client version cannot be reproduced in any
country, and its ownership is only recognized by the original
rightsholder.
However, a separate ownership exists and the client version inherits
the same scope than the server resource. For example, it is not
possible (even to the original rightsholder) to reproduce the
transformed version in any country.
Traditional ownership is built upon country reciprocity. The
Internet scope shows that individuals can still enforce the resource
ownership under a country exclusion. Otherness is also matter of
individual, rather than of the countries.
To summarize, the Internet scope has three characteristics:
o Regarding the country laws, an Internet server resource works just
like a PRIVATE resource, with the exception that it is possible to
create new versions from it. However, by default no reproduction
and no execution of these versions are allowed in no country.
o Any version SHALL inherit the INTERNET modifier. The modifier has
equivalent capabilities than the server resource (section 2.3).
In other words, multiple versions of the same Internet resource
can be exhibited by different rightsholders.
o All Internet versions SHALL refer, directly or indirectly, to an
original server resource. Any operation on a client version
resource (even its exhibition or execution) may ultimately require
the original rightsholder's authorization.
The Internet resource can also be managed by a license. For example,
to authorize the reproduction of a specific version, based on the
polling of readers.
Without the INTERNET scope modifier, it would be impossible to
understand the widest part of the behavior of resources in
interoperable environments, such as Internet.
3.4 PUBLIC modifier
The PUBLIC means that the reproduction and transformation of the
resource is allowed under a client URI, and a separate ownership is
recognized to derivative versions.
The client resource inherits the same scope than server. By default,
the client resource is public.
PUBLIC scope must not be confused with "public domain". The
Maturana & Robredo Expires December 30, 2004 [Page 12]
Internet-Draft Internet(C) July 2004
rightsholder of the public resource keeps the full control on the
resource.
3.5 Scope inheritance
The rule of scope inheritance is described in the following table.
More advanced explanations on inheritance can be read in previous
section (see "Reciprocity and Equivalence").
Given 2 resources, server and client, the scope modifier of the
client declaration SHALL be either the same or a more restrictive
modifier.
Server | Client resource MAY be:
resource is | Private Protected Internet Public
----------------------------------------------------
PRIVATE | Yes -- -- --
PROTECTED | -- Yes -- --
-----------------------------------------------------
INTERNET | Yes -- Yes --
-----------------------------------------------------
PUBLIC | Yes Yes Yes Yes
-----------------------------------------------------
Notes:
o Internet and public client resources can degrade to private
because they recognize a separate ownership.
o The client of a public resource can freely degrade to any scope.
This is done without prejudice to server rightsholder, who has
explicitly allowed the transformation and the reproduction of the
client resources.
This document does not define precedence rules for scope modifiers.
Maturana & Robredo Expires December 30, 2004 [Page 13]
Internet-Draft Internet(C) July 2004
4. Syntax of ownership declarations
In previous chapters, we analyzed the semantics of interoperability,
then we defined four scope modifiers for ownership declarations.
This chapter describes the RECOMMENDED syntax of such declarations.
4.1 Formal declaration
The formal declaration is a multiline text. Server and client
resources declarations share the same declaration syntax.
The syntax is based on three possible line types.
o Property line. MUST appear. It contains the rightsholder's
declaration of the resource.
o Attribution line(s). SHALL appear in client resource
declarations. It refers to the rightsholder's declaration of a
server resource.
o License line. Optional. Free text or link that defines specific
conditions of ownership.
A server declaration contains a Property line and optionally, a
License line:
[modifier](C) [date][owner] (Property line)
[standard assertion or license link] (License line)
A client declaration contains the same lines than the server
declaration, plus one or more attribution lines:
[modifier](C) [date][owner] (Property line)
& [modifier](C) [date][owner] (Attribution line)
[standard assertion or license link] (License line)
Here is an example of an Internet client declaration:
Internet(C) 2004, ClientOwner (client-owner@clientsite.com)
& Internet(C) 2004, ServerOwner (server-owner@serversite.com)
All rights reserved in all countries.
Maturana & Robredo Expires December 30, 2004 [Page 14]
Internet-Draft Internet(C) July 2004
4.2 Property line
Property line MUST appear for all modifiers. The Property line is
composed of:
o The scope modifier, from the token list: Private, Protected,
Public, Internet.
o The (C) symbol. This symbol may be entered as a parenthesized C,
uppercase or lowercase.
o The Date of first exhibition, usually followed by the date of the
last update
o The Name of the resource rightsholder
o Any optional information, as the resource URL or the author's
email address.
Modifier Scope
-------------------------------------
(none) PRIVATE
[Private](C) PRIVATE
Protected(C) PROTECTED
Public(C) PUBLIC
Internet(C) INTERNET
-------------------------------------
In a compliant declaration, the (C) symbol MUST follow the scope
modifier. The (C) symbol MUST appears even if no modifier is used or
Country Law does not require it.
Two examples:
Internet(C) 2004, OwnerName (owner-x@somesite.com)
Public(C) 2002-2004, OwnerName (owner-x@somesite.com)
4.3 Attribution line
The Attribution line SHALL be used in an ownership declaration when
the resource is a transformed version of the original or when
multiple rightsholders share different rights on it.
The use of an AMPERSAND sign ('&') in front of Attribution line is
RECOMMENDED.
The syntax of Attribution line is otherwise similar to the Property
Maturana & Robredo Expires December 30, 2004 [Page 15]
Internet-Draft Internet(C) July 2004
line. For example:
Internet(C) 2004, OwnerC (http://www.clientC.com)
& Internet(C) 2002-2004, OwnerB (http://www.client_server.com)
& Public(C) 2002, OwnerA (http://www.server.org)
When multiple server resources have been used, or because there are
multiple rightsholders, the ownership declaration may contain
multiple attribution lines. For example:
[modifier](C) [date][Local Rightsholder for the translation]
& [modifier](C) [date][Worldwide Rightsholder for all languages]
& [modifier](C) [date][Author who sold the original rights]
[standard assertion or license link]
4.4 License line
License line is OPTIONAL and can be used with any modifier to
override the default behavior of the resource.
The license line can be multiline and MUST close the ownership
declaration, after the Property line and the Attribution line(s).
The license line is a free text that usually relies on conventional
expressions, as used in the country of the protected resource.
Private(C) 2004, Owner (http://www.clienttranslation.com)
All rights reserved
Here is another sample in French.
Internet(C) 2004, NomDuClient (http://www.client.fr)
& Internet(C) 2002-2004, NomDuServeur (http://www.serveur.ca)
Reproduction interdite
The license line can refer to a license identified by an external
URI.
Maturana & Robredo Expires December 30, 2004 [Page 16]
Internet-Draft Internet(C) July 2004
Internet(C) 2004, OwnerX (owner-x@somesite.com)
LGTv1r4: http://www.in3activa.org
4.5 Long names and short names of modifiers
Scope modifiers are chosen from a finite token list, with four
elements: Private, Protected, Internet, Public.
All uppercase or lowercase variations are allowed and these
variations do not modify the modifier semantics .
This document does not define localized names for these tokens.
However, it defines short equivalents, as in the following table:
Long name Short name
-------------------------------------
Private(C) pri(c)
Protected(C) pro(c)
Public(C) pub(c)
Internet(C) int(c)
-------------------------------------
Here is a compliant handwritten implementation using short names:
Int(C) 2004, RightsHolder ...
Note: usage of short equivalents is reserved to the handwritten
implementation of the syntax. Metalanguage descriptions (such HTML
or Dublin Core) MUST use long names for modifiers.
Maturana & Robredo Expires December 30, 2004 [Page 17]
Internet-Draft Internet(C) July 2004
5. Scope modifiers implementation
After we analyzed the semantics of the interoperability of resources
based on the pair (URI, ownership), we determined four scope
modifiers, and proposed a recommended syntax to use the ownership
declarations.
As a conclusion to this specification, this chapter describes three
compliant implementations of the scope modifiers.
5.1 Handwritten implementation: the default modifier
The handwritten implementation matches the full syntax specification
of scope modifiers. The handwritten implementation also allows the
usage of short names of modifiers. For a complete handwritten
implementation, see the previous chapter.
To follow the common usage in the countries of Berne Union, a
compliant handwritten implementation SHALL consider the PRIVATE
modifier as the default modifier.
The following declaration :
(C) 2004, RightsHolder ..
will be interpreted as:
Private(C) 2004, RightsHolder ...
5.2 HTML implementation: the SCOPE tag
Scope modifiers are well suited for automated processing by robots,
and for dissemination of resources in the Internet. Among multiple
possibilities, we define the HTML implementation [HTML40], because it
can be easily adapter to other metalanguage specifications (XML, RDF,
etc).
The RECOMMENDED implementation of this framework with the HTML 4.0
language MUST include:
o A SCOPE meta tag in the HEAD section, which defines the default
scope of the resource.
o Optionally, one or more scope tags in the body, which override the
default scope defined in the header.
The following example describes a protected HTML resource:
Maturana & Robredo Expires December 30, 2004 [Page 18]
Internet-Draft Internet(C) July 2004
...
...
...
The content attribute defines the default scope of the resource.
HTML body tags that define specific content boundaries may override
this default scope
The following sample defines a Public scope portion, located inside
the default Internet scope of the resource. Both syntax are allowed
and MUST be recognized by automatic processing:
...
or
...
5.3 Dublin Core implementation
The Dublin Core specification offers a richer layout for scope
modifiers. This section describes the addition of the "scope"
modifier to the Dublin core specification [RFC2731].
The addition is based on a new SCOPE element, to be used along with
the already defined Rights Element:
Maturana & Robredo Expires December 30, 2004 [Page 19]
Internet-Draft Internet(C) July 2004
Le ravissement d'Europe
...
This Dublin Core example would be equivalent to the following
handwritten declaration (possibly inserted at the end of the
resource):
internet(C) 2004, I.Robredo
http://www.in3activa.org/doc/fr/LGT-FR.html
5.4 Using licenses
The scope modifiers provide a powerful, although generic, framework
for resources. To enlarge or restrict the scope of the resource
ownership, the rightsholders may define a license and override the
Maturana & Robredo Expires December 30, 2004 [Page 20]
Internet-Draft Internet(C) July 2004
default behavior of scope modifiers.
For example, a license may override the protected scope of software
resource, and it can authorize the resource transformation under
specifics conditions.
Conversely, the license of an Internet resource can be provided to
authorize the reproduction in some countries, such as the licensee's
country. For example, the license attached to an Internet resource
may allow a book reproduction to be sold in specific countries,
without prejudice to the original ownership.
(c) 2004, I.Maturana for the Spanish version
&Internet (C) 1999-2004, I.Robredo
http://www.in3activa.org/doc/es/LGT-ES.html
The framework provided by scope modifiers introduces the opportunity
for rightsholders to create and develop powerful licenses schemas,
based on the analysis and the simulation of resource behaviors, in
interoperable environments, including the Internet.
Maturana & Robredo Expires December 30, 2004 [Page 21]
Internet-Draft Internet(C) July 2004
6. Security Considerations
None.
7 References
[BERNE] World Intellectual Property Organization, WIPO., "Berne
Convention for the Protection of Literary and Artistic
Works", Paris Act of July 24, 1971, as amended on
September 28, 1979,
.
[CPPREF] Ellis, M. and B. Stroustrup, "The annotated C++ Reference
Manual", 1990.
[HTML40] W3C, "Hypertext Markup Language 4.0 Specification", April
1998, .
[IEEE 90] Institute of Electrical and Electronics Engineers, "IEEE
Standard Computer Dictionary: A Compilation of IEEE
Standard Computer Glossaries. New York, NY", 1990.
[LGT] Maturana, I. and I. Robredo, "General license of
translation", 1990-2004, .
[RDF] W3C, "Resource Description Framework Model and Syntax
Specification", February 1999,
.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997,
.
[RFC2396] Berners-Lee, T., Fielding, R., Irvine, U. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
August 1998, .
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin
Core Metadata for Resource Discovery, RFC 2413", September
1998, .
[RFC2731] Kunze, J., "Encoding Dublin Core Metadata in HTML, RFC
2731", December 1999,
.
[XML] W3C, "Extensible Markup Language (XML)", 2004,
.
Maturana & Robredo Expires December 30, 2004 [Page 22]
Internet-Draft Internet(C) July 2004
Authors' Addresses
I.Maturana
in3activa
Aptdo 15.117
Madrid, Spain
I.Robredo
in3activa
Ziburu, France
Maturana & Robredo Expires December 30, 2004 [Page 23]
Internet-Draft Internet(C) July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Maturana & Robredo Expires December 30, 2004 [Page 24]