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-01.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
environnments, 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 . . . . . . . . . . . . . . . 7
3. Definition of scope modifiers . . . . . . . . . . . . . . . . 9
3.1 PRIVATE modifier . . . . . . . . . . . . . . . . . . . . . 10
3.2 PROTECTED modifier . . . . . . . . . . . . . . . . . . . . 10
3.3 INTERNET modifier . . . . . . . . . . . . . . . . . . . . 10
3.4 PUBLIC modifier . . . . . . . . . . . . . . . . . . . . . 11
3.5 Scope inheritance . . . . . . . . . . . . . . . . . . . . 11
4. Syntax of ownership declarations . . . . . . . . . . . . . . . 13
4.1 Formal declaration . . . . . . . . . . . . . . . . . . . . 13
4.2 Property line . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Attribution line . . . . . . . . . . . . . . . . . . . . . 14
4.4 License line . . . . . . . . . . . . . . . . . . . . . . . 15
5. Scope modifiers implementation . . . . . . . . . . . . . . . . 16
5.1 Handwritten implementation: the defaut modifier . . . . . 16
5.2 HTML implementation: the SCOPE tag . . . . . . . . . . . . 16
5.3 Dublin Core implementation . . . . . . . . . . . . . . . . 17
5.4 Using licenses . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22
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 semantic of the
operations applicable on ressources, based on the pair (URI,
ownership). Then we determine the modifiers which controls the
interoperability of resources. Finally we describe the general
syntax of the ownership declarations that use these modifiers.
Four modifiers are defined. The PUBLIC, PROTECTED and PRIVATE
modifiers are transpositions of the class programming equivalents. A
fourth modifier -- the INTERNET modifier -- works as a no-country
restriction: it allows the transformation, but does not allow the
reproduction, of a private resource exhibited in interoperable
environnments, such as Internet.
As an exemple, 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
countries of the Berne Union [BERNE].
RESOURCE is an IP Object defined unambiguously in an interoperable
environnment by two properties: an URI and an ownership declaration.
Maturana & Robredo Expires December 30, 2004 [Page 3]
Internet-Draft Internet(C) July 2004
More strictly, a resource is an interface defined by the pair (URI,
ownership) to an IP object available in an interoperable universe
OWNERSHIP is a resource property, defined by 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).
SCOPE MODIFIER, is a conventional token attached to an ownership
declaration, used to alter the behavior of the resource in an
interoperable environnment.
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 a client resource, but it designates specifically the
result of the transformation.
INTEROPERABILITY is defined as in the IEEE Standard Computer
Dictionary [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 ressources. 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 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 auhtor's country.
I.Robredo is the name of the rightsholder class,
derived
from the country class (usually the Author's
name, but it is not required).
... 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 is used when the rigthsholder wants to make
available an IP Objet in an interoperable environnment, under
specific conditions of ownership. This object is called a resource,
and two properties determines its behavior in the environnment: an
Maturana & Robredo Expires December 30, 2004 [Page 5]
Internet-Draft Internet(C) July 2004
URI and a ownership d‰claration.
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 alter the
interoperability properties 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
objets. This document shows that similar conventions can be applied
to the resources exhibited in interoperable environnments, such as
the Internet.
2.2 Categories of operations
A resource is defined by a couple of properties: URI and ownership.
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 righstholders cannot control the same URI.
We resume these logical relations by two questions. For any
operation:
o Will the operation on resource create a second URI?
o Who is the rightsholder of the client resource, if created?
Four operations are defined as follows (alias names are parenthized):
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 rihgtsholder 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 both URI
is the same or a duplicate, the ownership of
both server an client resources remains to the same,
and belongs to the original rightsholder.
TRANSFORMATION (Derivation) A new, persistent client resource
is created, with a separate property pair (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.
2.3 Reciprocity and equivalence
This section is not required to understand this document, and it
refers explicitely 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.
Maturana & Robredo Expires December 30, 2004
[Page 7]
Internet-Draft Internet(C) July 2004
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 these two operations:
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.
The otherness concept is the basis of two complementary principles:
reciprocity (Berne-A3 and A5) and equivalence (Berne A2.3) of server
and client resources. The only restriction is the potential
prejudice to the server ownership.
By definition, the application of these principles is associative,
and they determines a "follow-up" mechanism of interoperability. In
other words, provided that the client and server resources are
mutually recognized by its rightsholders, the capabilities of both
client and server are supposed to be equivalent.
For example, if the source code is exhibited, any reproduction or
transformation must be exhibited as well, under a different URI, or
not exhibited at all.
Similar behavior happens when the ownership are different: allowing
the transformation of a server resource implies that the client
resource can be transformed as well. For reproduction, however, the
potential prejudice to the original owner is typically invoked to
restrict this follow-up mechanism.
This follow-up mechanism determines the rules of inheritance of scope
modifiers.
Maturana & Robredo Expires December 30, 2004 [Page 8]
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 which are used to alter the
resource behaviors. The general syntax of the ownership declarations
will be described in the next chapter.
The comparison of relations between URI and ownership is resumed in
the following table:
Operation | Second URI Separate
| Creation ownership
------------------|--------------------------------
EXHIBITION | No No
EXECUTION | No No
|
REPRODUCTION | Yes No
TRANSFORMATION | Yes Yes
----------------------------------------------
We then extract the second-URI based operations to create the logical
table of REPRODUCTION and TRANSFORMATION capabilities. Each entry
corresponds to four scope modifiers, as shown by the following table:
If EXECUTION is allowed and you allow...
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.
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.
The resource is | When the resource can be
------------------------------------------------
PRIVATE | -REPRODUCED and -TRANSFORMED
PROTECTED | +REPRODUCED but -TRANSFORMED
INTERNET | -REPRODUCED but +TRANSFORMED
PUBLIC | +REPRODUCED and +TRANSFORMED
Maturana & Robredo Expires December 30, 2004 [Page 9]
Internet-Draft Internet(C) July 2004
------------------------------------------------
This table shows clearly that the space allocated to the INTERNET
modifier in the semantics of the interoperability is a logical
imperative.
3.1 PRIVATE modifier
The PRIVATE modifier means that no secondary URI, and no separate
Ownershipis allowed for the resource. No reproduction, and no
transformation is 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 forbiden.
The client resource inherits the same scope than server. By default,
it is posible 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 which
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 forbiden.
The INTERNET modifier can be defined as a "country excluder". This
exclusion rationale highlihgts 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 no
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 no country.
Conceptually, we recall that the traditional ownership is grounded on
Maturana & Robredo Expires December 30, 2004 [Page 10]
Internet-Draft Internet(C) July 2004
the country laws. The Internet scope modifier shows that the
ownership can be directly enforced by the good will of individuals.
Under this scope, the reciprocal and equivalent ownership of
resources is enforced by the otherness of the persons, rather than of
the countries.
To resume, 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
requires the authorization of the original rightsholder.
The internet resource can be also managed by a license. for example,
to authorize the reproduction of a specific version, based on t
he
polling of readers.
Without the INTERNET scope modifier, it would be impossible to
understand the widest part of the behavior of resources in
interoperable environnements, 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.
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
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.
Given 2 resources, server and client, the scope modifier of the
client declaration SHALL be either the same or a more restrictive
modifier.
Maturana & Robredo Expires December 30, 2004 [Page 11]
Internet-Draft Internet(C) July 2004
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 In theory, and internet client resource could allow the
reproduction, without prejudice to the server ownership (Berne
A-2.2 [BERNE]). In practice, allowing the reproduction of a
client version requires an explicit grant from the original
rightsholder.
o The client of a public resource can freely degrade to any scope.
This is done without prejudice to server rightsholder, who has
explicitely 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 12]
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 defined as server or
client declaration.
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 optionnaly, 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
delcaration, 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 a 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.
4.2 Property line
Property line MUST appear for all modifiers. The Property line is
composed of:
o The scope modifier, from the list: Private, Protected, Public,
Internet.
Maturana & Robredo Expires December 30, 2004 [Page 13]
Internet-Draft Internet(C) July 2004
o The (C) symbol. This symbol may be entered as a parenthized C,
uppercase or lowercase.
o The Date of first exhibition, oftentimes 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
it is not required by the Country Law.
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
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 contains
multiple attribution lines. For example:
Maturana & Robredo Expires December 30, 2004 [Page 14]
Internet-Draft Internet(C) July 2004
[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 may be used with any modifier to
override the default behavior of the resource.
The license line may 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 rely 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 an other example in French.
Internet(C) 2004, NomDuClient (http://www.client.fr)
& Internet(C) 2002-2004, NomDuServeur (http://www.serveur.ca)
Reproduction interdite
The license line may refer to a license identified with a separate
URI.
Internet(C) 2004, OwnerX (owner-x@somesite.com)
LGTv1r4: http://www.in3activa.org
Maturana & Robredo Expires December 30, 2004 [Page 15]
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 defaut modifier
The handwritten implementation matches the syntax specification of
scope modifiers. For a complete handwritten implementation, please
read the the previous chapter description.
However, 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 the many
possibilities, we only define the HTML implementation [HTML40],
because it can be easily adapter to other specifications (XML, RDF,
etc).
The RECOMMENDED implementation of this framework with the HTML 4.0
langage 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 an protected HTML resource:
Maturana & Robredo Expires December 30, 2004 [Page 16]
Internet-Draft Internet(C) July 2004
...
...
...
The content attribute defines the default scope of the resource.
This default scope may be overriden by HTML body tags that define
specific content boundaries.
In the following example, we defines a public portion inside the
default internet scope of the resource. The two 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 a possible addition of 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 17]
Internet-Draft Internet(C) July 2004
Le ravissement d'Europe
...
This Dublin Core example would imply the following handwritten
declaration 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 provides 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
default behavior of scope modifiers.
For example, a license may override the protected scope of software
resource, and authorize its transformation under specifics
Maturana & Robredo Expires December 30, 2004 [Page 18]
Internet-Draft Internet(C) July 2004
conditions.
Conversely, the license of an internet resource can be provided to
authorize the reproduction in the country of the licensee. 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/fr/LGT-FR.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 environnments, including the Internet.
Maturana & Robredo Expires December 30, 2004 [Page 19]
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 (http://www.w3.org/TR/REC-html40/), "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 (http://www.w3.org/TR/REC-rdf-syntax/), "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 (http://www.w3.org/TR/REC-xml/), "Extensible Markup
Language (XML)", 2004.
Maturana & Robredo Expires December 30, 2004 [Page 20]
Internet-Draft Internet(C) July 2004
Authors' Addresses
I.Maturana
in3activa
Aptdo 15.117
Madrid, Spain
EMail: imaturana@in3activa.org
I.Robredo
in3activa
Ziburu, France
EMail: irobredo@in3activa.org
Maturana & Robredo Expires December 30, 2004 [Page 21]
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 22]