Subject: RE: "field of use" elaboration

From: [email-masked]
Date: Wed, 9 Nov 2005 18:02:34 -0500

Sam,

> I'd also like to understand why you are concerned about Simon's
> proposal.

Here are three reasons:

(1) I'm concerned about the IETF losing change control of our
protocols.  While anyone can publish a protocol spec outside IETF,
they currently have no right to use RFC text in doing so (something
I've learned the hard way ;-) ).  I don't want to make this sort of
activity easier by giving away that right without restrictions, unless
it is necessary to do so for other reasons.  Part of this is addressed
by the point made in the meeting that making any modification whatsoever
must remove any permission to claim that the modified result is the
original RFC.

(2) I believe that people who want or need to change IETF protocols
should tell the IETF about the changes (at the very least, we should
know, and we may be able to improve on the changes).  This is similar
to the open source desire that people make code changes available
(something the open source community backs with license requirements).
To make this work, IETF need a better Errata process, and I made that
point in the techspec BOF this morning.

While I'm here, let me acknowledge your point in the meeting that
RFC extracts that are intended for source code (e.g., ASN.1, MIBs)
MUST be distributable under the GPL (and similar open source licenses)
and that the ability to distribute MUST include modifications needed
to get the code to work (e.g., ASN.1 schema edits that don't affect
the protocol).  I need to spend more time thinking about how to do
this with a "field of use" approach, as I would not expect a "field
of use" restriction on source code to be GPL-compatible.

(3) I would like to solve the problems Simon points out in a minimal
fashion - without opening the gates to allow anyone to do anything,
as once we open those gates, we won't be able to close them.  I was
struck by the fact that all 5 of the examples in Simon's draft fell
within the "field of use" of implementation of the original RFC.  Of
the two new ones he's added, the protocol modification one (IMHO) falls
into "Send Draft" and the Education one is probably covered for the
most part by the combination of "field of use", "fair use" and
"Send Draft", although I see no problem in adding education to the
"field of use".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Nov 2005 00:36:13 +0100

[email-masked] writes:

> within the "field of use" of implementation of the original RFC.

I disagree with that, at least until I see actual license text on what
you mean.  The RFC 2026 license contain a "field of use" that is
expressed as:

          derivative works that comment on or
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind

To me, that is a very widely applicable "field of use".  Yet, it is
not sufficient, some aspects of my examples are not possible even
given the RFC 2026 license.  It seems difficult to craft a "field of
use" that would cover all uses I have identified, but I'm interested
in seeing your proposal.

I note that I believe any "field of use" restriction would be
incompatible with Debian's Free Software Guidelines.  Do you agree or
disagree with that?

Thanks,
Simon

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 09 Nov 2005 18:14:50 -0800

On Wed, 2005-11-09 at 15:02, [email-masked] wrote:

> know, and we may be able to improve on the changes). 

indeed.  another way of phrasing it would be:

 1) when modified derivative specs are created/redistributed, the
relevant  IETF WG (or its descendant) must get a copy.

 2) any or all of a derivative spec must be fair game for inclusion in a
future IETF spec.
--

(1) helps other implementors become aware of what liberties are being
taken with the protocol.

(2) allows the IETF to cherry-pick useful modifications for inclusion in
future revisions of the spec.

					- Bill

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Nov 2005 21:47:54 -0500

I'm sorry, this just bothers me.

One of the effects of open source is that there are many things under the 
same "name".
How many different things are under the label "linux"?  And linux is 
actually relatively well defined.

It is important to us that the IETF RFC be well defined, and that 
implementations of those specs interoperate.
Telling everyone in the world ~do something with this, feel free to change 
it as you like~
is just the wrong model.
It encourages many kinds of change, including change by other SDOs, 
careless implementors, and by folks who disagree with the decisions the 
IETF made about how to do the protocol.

I do not believe that telling people that they "should not make changes" 
will do us any good.

Yours,
Joel

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Nov 2005 05:35:40 +0100

I already replied to reason 3), but here is a minor comment on 1).

> must remove any permission to claim that the modified result is the

I don't see anyone proposing granting rights to create derivative
works, with modification, WITHOUT also requiring these third parties
to label the modified work clearly.  This is covered by my license
text.

I can understand the concern that IETF loses change-control, but as
I've tried to explain, I believe the fears are exaggerated.  It is
difficult to prove this though.

> (something the open source community backs with license requirements).

I understand what you are getting at here, but in a small detail, I
think you are misrepresenting how the open source community works
here.  The open source community does not (at least in general, but I
know of no counter-examples that are in wide use) require that the
original author is notified about changes.

Debian uses a thought experiment to decide whether a license would
qualify as free, called the "desert island test", here is a short
explanation:

  Imagine a castaway on a desert island with a solar-powered computer
  with a internet connection that can't upload. This would make it
  impossible to fulfill any requirement to make changes publicly
  available or to send patches to some particular place. This holds
  even if such requirements are only upon request, as the castaway
  might be able to receive messages but be unable to send them. To be
  Free, software must be modifiable by this unfortunate castaway, who
  must also be able to legally share modifications with friends on the
  island.

> point in the techspec BOF this morning.

There is no disagreement here.  However, even a properly working
errata process would not pass the "desert island test".

Regards,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Nov 2005 12:40:43 -0500

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> indeed.  another way of phrasing it would be:

    Bill>  1) when modified derivative specs are
    Bill> created/redistributed, the relevant IETF WG (or its
    Bill> descendant) must get a copy.

    Bill>  2) any or all of a derivative spec must be fair game for
    Bill> inclusion in a future IETF spec.  --

Note that this would be an unacceptable condition for source code
extracted from RFCs.  It's GPL incompatible.

It isn't my preference for specs but I could live with it.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Nov 2005 12:43:32 -0500

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> It is important to us that the IETF RFC be well defined, and
    Joel> that implementations of those specs interoperate.  Telling
    Joel> everyone in the world ~do something with this, feel free to
    Joel> change it as you like~ is just the wrong model.  It
    Joel> encourages many kinds of change, including change by other
    Joel> SDOs, careless implementors, and by folks who disagree with
    Joel> the decisions the IETF made about how to do the protocol.

This is one of the last times I'll say this; I'll probably say it
again in a consensus call.

I agree with you about the naming of RFCs.  If it says it is RFC 2026
then it should be the exact text of RFC 2026.

However everyone feelsfree to change our protocols.  The question we
should ask ourselves is whether they can document these changes
outside our process or whether we tell people who don't want to come
to our process that we'd rather they simply not document their
changes.

--Sam

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 10 Nov 2005 11:19:25 -0800

On Wed, 2005-11-09 at 20:35, Simon Josefsson wrote:

> qualify as free, called the "desert island test"...

The IETF exists to deal with reality, and desert islands of this form
simply do not exist in the world today.

I firmly reject the notion that the desert island test has any relevance
to what we do here.

						- Bill

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 12 Nov 2005 11:21:41 +0100

> I firmly reject the notion that the desert island test has any relevance

I would agree that the "desert island" scenario is not realistic.
However, it is not meant to be.

It is meant to make it easier to decide whether a specific piece of
license text is free or not, as defined by Debian's policy.

I believe it should be possible to include IETF Contributions, and
derived material (e.g., RFC excerpts in source code), in Debian.

Consequently, the desert island test is highly relevant here. because
Debian is using it to determine whether a license qualifies or not.

If we believe Debian should be permitted to include IETF
Contributions, we do have to use a license that qualifies.

If the IETF reject Debian's policies, it could be argued that the IETF
would harm the Internet, as Debian (as far as I understand) would have
to identify and remove all excerpts of RFCs in their packages.  That
would cause serious breakage.

Regards,
Simon

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 12 Nov 2005 04:43:32 -0800

> I would agree that the "desert island" scenario is not realistic.
...
> would cause serious breakage.

Or Debian can change its interpretation to remove a test which you admit
is unrealistic.

						- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Nov 2005 19:06:19 +0100

> extracted from RFCs.  It's GPL incompatible.

GPL is not the only license and nobody is forced to put their
code under the GPL. But if someone does extract code from
an RFC and purports to put it under the GPL, surely we can craft
a grant of license for RFCs that invalidates this (i.e. says
"you can include this code but whatever license you purport
to put it under, the IETF license applies").

    Brian

---

From: "Simon Josefsson" <[email-masked]>
Date: Sat, 12 Nov 2005 20:08:56 +0100 (CET)

> Or Debian can change its interpretation to remove a test which you admit

You misunderstood me.

The scenario that someone is stranded on an island with Internet
capability that can only download, and wishes to develop software and
spread it to others on that island, is unrealistic.

However, that is not the point.

The test was developed to make it easier to decide which licenses are
usable by the Debian community.  Licenses that fail the desert island test
-- and no important open source software does -- has a history of causing
legal troubles.  Like the current IETF copying conditions.  The Debian
community wishes to avoid those legal troubles.

The test identify which licenses permit redistribution of modified works
without informing the original author.  The FreeBSD community appeared to
want the same right, to be able to modify the RFC derived man page for
getaddrinfo.  FreeBSD is sometimes used in closed source products that may
be modified.  As far as I understand, the FreeBSD community wants to make
sure those closed source users are entitled to be able to modify the
getaddrinfo man page, and to distribute the resulting product.  WITHOUT
telling FreeBSD which changes it has made.

Further, if the copying conditions used by the IETF do not pass the desert
island test, I believe the open source community will develop its own
protocol descriptions and use them instead.  It is not like it doesn't
have the resources to do so.  I'm arguing that it further the IETF's goal
to make sure this doesn't happen.

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 12 Nov 2005 14:27:43 -0500

I see a distinction and an assumption here.
It is clearly important that protocols defined by the IETF, including the 
necessary code components, be useable in free or commercial software.

However,
free software != debian
free software != GPL

You are asking the IETFcommunity to change its policies to match the Debian 
policies.
The Debian organization could just as easily choose to change its policies 
to allow free distribution of IETF product within the IETF rules.

I am not asserting that the Debian community must change its religion.
I am asserting that it is unfair to claim that the IETF must believe in the 
Debian religion.

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 12 Nov 2005 22:11:44 +0100

I'm only using Debian as an example.  I think Debian is an important
example, as is FreeBSD, but there are many examples.  The issues are
similar to those described in my draft, they are only compounded
because a distribution include a lot of free software.  I realize that
we might not be able to chose a license that solve the problem in all
examples.

At this point, I believe it is useful to collect as many examples as
possible of where the current copying conditions cause problems.  That
is useful when deciding what kind of things we want to permit.

Thanks,
Simon

"Joel M. Halpern" <[email-masked]> writes:

> It is clearly important that protocols defined by the IETF, including
> the necessary code components, be useable in free or commercial
> software.
>
> However,
> free software != debian
> free software != GPL
>
> You are asking the IETFcommunity to change its policies to match the
> Debian policies.
> The Debian organization could just as easily choose to change its
> policies to allow free distribution of IETF product within the IETF
> rules.
>
> I am asserting that it is unfair to claim that the IETF must believe
> in the Debian religion.
>
> Yours,
> Joel M. Halpern
>

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 13 Nov 2005 01:56:54 +0100

Simon Josefsson wrote:

>> I firmly reject the notion that the desert island test has
>> any relevance to what we do here.
 
> I would agree that the "desert island" scenario is not
> realistic.  However, it is not meant to be.
 
> It is meant to make it easier to decide whether a specific
> piece of license text is free or not, as defined by Debian's
> policy.

I'm lost what it means.  Is it "compatible" with CC BY SA,
or is it more like CC BY ?  How do I get a CC BY SA effect
with the IETF boilerplates ?
                            Bye, Frank

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 12 Nov 2005 20:01:29 -0500

Actually, you had argued explicitly that we had to use a license that 
complies with the Debian requirements.
(See quote towards the end.)
Now you say it was only an example.
I hope you are not arguing that we MUST use terms which comply with every 
variation within the free software community.  While that would be a nice 
result in some regards, I do not believe it is theoretically possible, 
given the range of requirements.

Yours,
Joel

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Nov 2005 01:37:09 +0100

> to put it under, the IETF license applies").

I don't understand that.  Are you saying that the IETF should use
copying conditions license that are explicitly GPL incompatible?

If so, I think a lot of open source projects will have to be reviewed
and all inclusions of RFC excerpts have to be removed.  To illustrate
the magnitude and impact of that, we could develop a text recognition
tool that compare RFCs with open source code.  I manually conducted
that search as input to one of the example in my presentation, and
several well known open source products were affected (Apache,
OpenSSL, ...).

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Nov 2005 12:17:05 +0100

> Now you say it was only an example.

Right, I'm arguing for that.  But I realize the consensus process may
decide something else.  That's why it is important not to get stuck on
a particular example, if the consensus is that the example is
non-important.  I don't think we have agreed consensus that the IETF
wishes and the Debian copying conditions are inherently incompatible.

My strategy here is to produce several examples, and have the IETF
decide whether they want to permit that particular example or not, and
from that information infer what license might be applicable.

We can't arrive to a conclusion without carefully considering all
example uses, and their implications in detail, and on a case-by-case
basis decide whether the example use is something the IETF wishes to
permit or not.

> I hope you are not arguing that we MUST use terms which comply with
> every variation within the free software community.  While that would
> be a nice result in some regards, I do not believe it is theoretically
> possible, given the range of requirements.

I agree it would be a nice result.  I argue that it would be
preferable to use license terms that are compatible with a large set
of licenses.  Ranging from the Microsoft EULA to the GPL.

I don't see why it is difficult to achieve that goal.  A license such
as the MIT license, or the revised BSD license, is compatible with all
licenses we are concerned with, as far as I know.  Using that license
for RFCs would also result in a free software compatible license.

My hope is that the IETF intentions can be expressed in a license that
is compatible with free software licenses.

Thanks,
Simon

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Nov 2005 15:34:37 +0100

Simon Josefsson wrote:

> My hope is that the IETF intentions can be expressed in a
> license that is compatible with free software licenses.

The "desert island" test is apparently the same as "you can
grab it, modify it, and sell the modified version _without_
giving free access to the modification".  If that's the case
then it's apparently incompatible with CC BY SA "some rights
reserved", the share-alike aspect is lost on a desert island.

                           Bye, Frank

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Nov 2005 16:41:40 +0100

Frank Ellermann <[email-masked]> writes:

> giving free access to the modification".

The modifications are included in the text you release, aren't they?

Are you thinking of the distinction between binary source code without
released modifications?  I'm not sure how that apply here.  If you
release a RFC derived work in the form of text, you are releasing the
modifications.

If you are thinking about big tables from RFC that are included in
compiled binary software, I think you are right.  I believe the IETF
will want to give the right to everyone to derive IDN code point
tables from RFCs and put them into closed-source proprietary products.

If a vendor like Microsoft or Apple (who doesn't generally release
source code for their software publicly) want to apply a security fix
to the IDN tables, I believe they MUST have the right to do so, even
without first notifying the IETF and disclosing what modification they
did.  I believe this is how companies have operated for years.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2005 14:28:00 +0100

> several well known open source products were affected (Apache,

No. I'm no GPL expert, but I've certainly heard of cases where people
mix GPL source and (e.g.) BSD source in a single package. I was thinking
of something like that.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2005 15:44:51 +0100

Simon Josefsson wrote:
...
> to identify and remove all excerpts of RFCs in their packages.

Er, that would be "harm Debian" not "harm the Internet" but afaik the
IETF doesn't want to harm either.

And it isn't a matter of the IETF "rejecting" Debian policy or any other
open source community's policy. I think you're looking at this as if it's
a zero-sum game; it isn't. It's a matter of accommodating the IETF
policy to the entire ecosystem, which contains open source implementors,
software vendors, other standards bodies, and educational or tutorial
authors, to name but some.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 16 Nov 2005 16:02:49 +0100

> mix GPL source and (e.g.) BSD source in a single package. I was thinking

Ok.  Mixing GPL licensed code and BSD licensed code is perfectly
legal, and is done in many large GPL projects (e.g., the Linux
kernel).

Derivative works of the combined BSD+GPL work will have to follow the
terms in both licenses, of course.  You can't combine something and
only follow the license for one piece of the work.  Fortunately, the
BSD and GPL licenses are compatible.  The resulting work will
essentially be licensed under GPL, because the GPL is copyleft whereas
the BSD is not, and the licenses are otherwise similar.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 16 Nov 2005 16:17:54 +0100

> IETF doesn't want to harm either.

My thought was that if Debian is harmed, the operation of the Internet
is also harmed, since Debian is widely used.  As you imply below, the
two go hand in hand.

> authors, to name but some.

Right.  I believe it is possible to accommodate everyone here.  I
haven't seen much opposition to permit the things I identified.

Fixing the fake RFC problem is important, but since we all seem to
agree that fake RFCs are bad, perhaps we can regard solving that
problem as a technicality.

Thanks,
Simon

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 Nov 2005 16:26:04 +0100

> The modifications are included in the text you release,

Yes.  But my POV was as the author of the original text
(with CC-BY-SA), so it's "them" who modify it.  And I or
everybody else should be free to take their modifications
and integrate them into a new I-D and later RFC nnnnbis,
if the original document was published as RFC nnnn.

That's the idea of the "Share Alike" in CC-BY-SA (please
add tons of IMHO / AFAIK / IANAL).

In other words, if they grab it, modify it, and then try
to patent their modifications, it's not okay from my POV.

The US could be an excellent example of a "desert island",
legally.  Where I live any text talking about "patented
algorithms" (like the new MIME part 4) is utter dubious,
AFAIK it's impossible to patent algorithms here.

                         Bye, Frank

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 18 Nov 2005 17:06:56 +0100

> if the original document was published as RFC nnnn.

First, I don't see why this is important.  People will bring useful
modifications back to the IETF because there is value in doing so.
Forcing them to do so seem questionable.  Not even the BSD or GNU
communities require people to bring back changes to the original
author.

Secondly, I don't see how you could have a license that mandate that,
without becoming incompatible with many, if not ALL, widely used
licenses for IETF implementations:

   BSD/GPL: If I incorporate some text from an RFC into my GPL
   product, the license covering the product should preferably still
   be the GPL, and someone later modify that text, the modified work
   will be covered by the GPL.  If the IETF cannot accept that, they
   can't use the modified work.

   Closed source product: If commercial Unix vendors like Sun take RFC
   2133 and modify it into a getaddrinfo man page, they release their
   work under their own closed source proprietary license.  The IETF
   most likely doesn't accept that license either, so they cannot use
   the modifeid work.

> to patent their modifications, it's not okay from my POV.

Whoa.  That is a completely different discussion.

You don't patent specific text, you patent an idea.

Presumably, they would not patent the actual IETF protocol, because
there is prior art (in the IETF protocol).

They would patent some variation of the protocol.  They can do this
today anyway, so this changes nothing.  Having the right to re-use
text from an RFC won't make this easier.

The cost of patenting something is high.  I believe the cost of
rewriting a RFC to avoid copyright infringement is cheap in
comparison.

Thanks,
Simon