Subject: Re: draft-bradner-rfc-extracts-00.txt

From: [email-masked] (Scott Bradner)
Date: Thu, 10 Feb 2005 20:09:23 -0500 (EST)

Bill desires:

   - code changes to make RFC-derived code pass various static or dynamic 
     checkers (lint, purify, gcc -Wall, ...)

   - changes to make it match local conventions for indentation, identifier 
     naming, header file naming, etc.,

   - changes to eliminate global variables, add locking for multithread 
     safety, or allow for localized messages.

   - Translations into other programming languages or to cope with the
     evolution of the programming language (e.g., the K&R C to standard C 
     transition).

I like all of these - can you suggest a generic way to say the above?
(listing specific cases seems to be a way that will not scale)

Scott

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 10 Feb 2005 21:19:37 -0500

> I like all of these - can you suggest a generic way to say the above?

Before I try to do that, can you say more specifically what you want 
to prevent or preclude? 

In open source terms, I think you want to prevent forking of IETF specs
outside the context of the IETF. 

Forks are generally not looked upon well in the open source community, 
but, in practice, most changes contributed by external developers 
originate as a personal fork for experimental use by one or more people...

A number of the open source licenses I've found include a requirement 
that people distributing modified versions notify the original licensor 
of the changes.

Would it be sufficient to require that folks wishing to redistribute
non-interoperable derivative works document their changes in the form 
of either a note to a relevant WG or area list or an internet-draft 
submission?  This at least makes them stick a toe into the IETF process..

						- Bill

---

From: "todd glassey" <[email-masked]>
Date: Thu, 10 Feb 2005 19:53:48 -0800

By the way - if a document filed for publication with the IETF has a
code-clip from some other copyrighted document, isn't this an issue as far
as the authors re-conveying rights they dont own to the IETF? What I mean is
dont you need a formal release from the cited copyright holder for the code
clip to?

Just a thought.

Todd

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 10 Feb 2005 23:13:32 -0500

>dont you need a formal release from the cited copyright holder for the code

Section 5.1 of 3667 requires submitters to include this text:

   "By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668."

Copyright would certainly be covered by "other IPR".  In other words, I 
don't disagree with you, but I do feel that it's already covered.

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Feb 2005 09:48:55 +0100

> submission?  This at least makes them stick a toe into the IETF process..

That may fail the "Desert Island" test, which some organization appear
to be concerned with, compare
<http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines>.  It
may be helpful to review <http://www.debian.org/social_contract> to
understand the rationale behind such requirements.

However, if the real problem is that people would modify standards and
call them IETF standards, I believe it would be clearer to explicitly
forbid that in the license.  Instead of creating other problems.

> Before I try to do that, can you say more specifically what you want

I would also like to understand the answer to that question.

Thanks,
Simon

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 11 Feb 2005 09:20:01 -0500

> understand the rationale behind such requirements.

I read these pages.  Maybe I'm just dense but I don't see how the desert island
test follows from either the social contract or the DFSG.

Moreover, the open source initiative says it uses  
http://www.opensource.org/docs/definition.php, which is essentially the same as
the DFSG, to evaluate licenses, and it certified several licenses with
notification provisions, including:
http://www.opensource.org/licenses/nasa1.3.php
and
http://www.opensource.org/licenses/rpl.php

To top it all off, items #2 and #3 of the debian social contract themselves
appear to violate the spirit of the desert island test, as do provisions 3(b)
and 3(c) of the GPL (when redistributing binaries, allowing source to be
distributed later -- if an isolated person is physically incapable of notifying
the author of changes, they are also physically incapable of requesting the
sources from the author).

							- Bill

---

From: "todd glassey" <[email-masked]>
Date: Fri, 11 Feb 2005 07:38:23 -0800

So Steven- the IETF is supposed to believe the person submitting the
materials??? - What is the damage to the original owner if the person is
lying. What is the damage? - the point is that the ENTIRE IETF process is
based on TRUST and no other in the world is. No financial payment system is
based on "well trust you to do it". No other IP Conveyance or release
process is.

I think this is exactly where we formally set in the historical record of
the IETF and IESG that the IETF must not just blindly believe without basic
releases, anything sent to it, or that it and the IESG are willing to accept
the financial damages that their lack of anything like reasonable diligence
provides here. Or, that its not and that there is an implicit damager to the
actual IP Owners in participating in the IETF.

This is it - Steven thanks!

Todd Glassey

---

From: Don Armstrong <[email-masked]>
Date: Fri, 11 Feb 2005 11:44:22 -0800

As this is (probably) not particularly on topic for this list, please
feel free to respond privately if clarification on any of the points
is required.

On Fri, 11 Feb 2005, Bill Sommerfeld wrote:
> > That may fail the "Desert Island" test, which some organization
> > appear to be concerned with, compare
> > may be helpful to review <http://www.debian.org/social_contract>
> > to understand the rationale behind such requirements.
> 
> I read these pages. Maybe I'm just dense but I don't see how the
> desert island test follows from either the social contract or the
> DFSG.

It follows from DFSG §5 and §6.[1]

The basic premise of the desert island test is that a license should
not force an individual on a desert island to be in violation of the
license merely because they cannot communicate with the world at
large. See [2] and the thread that follows for much more information.

> http://www.opensource.org/docs/definition.php, which is essentially
> the same as the DFSG, to evaluate licenses,

This is a common misconception. The OSI applies the OSD with totally
different ends in mind. First, they evaluate licenses, whereas the
DSFG and debian-legal evaluate software that is under a license.
Secondly, the groups operate at cross purposes. The OSD is used to
indicate that a license is "open source" and rubber stamp licenses
that comply with the definition, even if they are very much against
the spirit of the Free Software movement. Debian uses the DFSG to
preserve the freedom of its users to modify, use, and redistribute
works that are actually included in Debian.

> if an isolated person is physically incapable of notifying the
> author of changes, they are also physically incapable of requesting
> the sources from the author).

There is a fundamental difference between an additional grant (You may
request source code from the author) and a requirement (You must
contact the original author.) As such, the desert island test (and its
cousin, the dissident test) applies to the latter, but not the former.

Don Armstrong

1: http://www.debian.org/social_contract#guidelines
2: http://lists.debian.org/debian-legal/2004/07/msg00437.html
-- 
Every gun that is made, every warship launched, every rocket fired
signifies in the final sense, a theft from those who hunger and are
not fed, those who are cold and are not clothed. This world in arms is
not spending money alone. It is spending the sweat of its laborers,
the genius of its scientists, the hopes of its children. This is not a
way of life at all in any true sense. Under the clouds of war, it is
humanity hanging on a cross of iron.
 -- Dwight Eisenhower, April 16, 1953

http://www.donarmstrong.com              http://rzlab.ucr.edu
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 11 Feb 2005 18:47:17 -0500

> large. See [2] and the thread that follows for much more information.

We spend enough time worrying about actual problems that worrying 
about hypotheticals like this is a waste of time.

IMHO, absent evidence of an actual desert island with incommunicado
developers, the desert island constraint you propose to apply here
fails the IETF's bedrock "running code" principle.

Given evidence of such developers, our energy would be better spent on 
removing barriers which prevent them from being connected to the Internet.

More importantly, both the "desert island" and the "dissident" tests presume
that the people enforcing the license are mindless automatons and would seek
to enforce it even when it would be unjust or destructive to the aims of the 
IETF to do so. 

					- Bill

---

From: Don Armstrong <[email-masked]>
Date: Fri, 11 Feb 2005 15:55:30 -0800

[Kindly refrain from Cc:'ing me, as I am subscribed to the list.]

> about hypotheticals like this is a waste of time.

This is merely a specific test that explains why such a clause is
necessarily non-free, and won't be suitable for inclusion in Debian.

Whether or not members of the ipr wg decide to address these concerns
are not is an issue to be determined by the ipr wg. Either way, the
issues remain, and are very real. [I would not have spent my time
attempting to explain them to you all if I felt they were not.]

Don Armstrong

-- 
It has always been Debian's philosophy in the past to stick to what
makes sense, regardless of what crack the rest of the universe is
smoking.
 -- Andrew Suffield in [email-masked]