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/