draft-josefsson-ipr-rules-update-04.txt   draft-josefsson-ipr-rules-update.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Updates: 3978 (if approved) Updates: 3978 (if approved)
Expires: June 16, 2006 Expires: June 17, 2006
RFC 3978 Update RFC 3978 Update
draft-josefsson-ipr-rules-update-04 draft-josefsson-ipr-rules-update-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 16, 2006. This Internet-Draft will expire on June 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Two problems with BCP 78 regarding the outbound rights granted to Two problems with BCP 78 regarding the outbound rights granted to
third parties are identified. A proposal to solve the problems is third parties are identified. A proposal to solve the problems is
proposed. proposed.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
The IETF suggests that any citation or excerpt of The IETF suggests that any citation or excerpt of
unmodified text reference the RFC or other document from unmodified text reference the RFC or other document from
which the text is derived. which the text is derived.
6. Requiring a warning label to be added 6. Requiring a warning label to be added
To further protect against works claiming to be the original work, it To further protect against works claiming to be the original work, it
has been suggested that the license should require that people who has been suggested that the license should require that people who
modify the contents should be forced to add a "warning label". There modify the contents should be forced to add a "warning label". There
are two ways to achieve this. The first is to explicitly suggest the are two ways to achieve this. The first is to explicitly suggest the
text that is to be added. The second is to implicitly require that, text that is to be added. The second is to implicitly require that
by stating that the derivative works must not be confusable with the text is added, by stating that the derivative works must not be
original. confusable with the original.
The first approach of using a particular warning label may lead to The first approach of using a particular warning label may lead to
problems when an implementation support many RFCs. If the particular problems when an implementation support many RFCs. If the particular
warning label include the RFC number, there may be a potentially huge warning label include the RFC number, there may be a potentially huge
list of warning labels that only differ in the RFC number. Even if list of warning labels that only differ in the RFC number. Even if
the specific RFC number is not part of the warning label, the text of the specific RFC number is not part of the warning label, the text of
the warning label may seem inappropriate and confusing in some the warning label may seem inappropriate and confusing in some
modified uses, making the reader question what the warning label is modified uses, making the reader question what the warning label is
adressing. adressing.
We believe the second approach, of requiring that implicit warning We believe the second approach, of requiring that implicit warning
labels protect against the same abuse but leads to more readable end labels protect against the same abuse but leads to more readable end
products. products.
A license that require warning labels to be added may be incompatible A license that require warning labels to be added may be incompatible
with certain free software licenses, and depending on the language with certain free software licenses, and depending on the language
used, it may even make the liecnse non-free. We believe further used, it may even make the license non-free. We believe further
review by the free software community is required if this solution is review by the free software community is required if this solution is
to be considered further. to be considered further.
As a starting point for further research, we propose to add the As a starting point for further research, we propose to add the
following implicit requirement for warning labels to the license following implicit requirement for warning labels to the license
below: below:
(d) clearly label a derivative work as such, to avoid similarity (d) clearly label a derivative work as such, to avoid
between the original work and the derivative work. similarity between the original work and the derivative
work.
7. Separating the license for code and text 7. Separating the license for code and text
It has been suggested that the license should be separated to cover It has been suggested that the license should be separated to cover
code and text separately. The intention is supposedly that code can code and text separately. The intention is supposedly that code can
use a free and GPL/BSD-compatible license, whereas the text portion use a free and GPL/BSD-compatible license, whereas the text portion
will not. will not.
We argue that this solution is sub-optimal, and in particular it We argue that this solution is sub-optimal, and in particular it
would prevent scenarios including the following: would prevent scenarios including the following:
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/