Subject: Trustees License Use of Templates in RFCs

From: IETF Administrative Director <[email-masked]>
Date: Thu, 12 Mar 2015 05:43:00 -0700

The Trustees of the IETF Trust decided by e-vote on 10 March 2015 to
add the following section to the Trust Legal Provisions licensing
the use of Templates in RFCs:

9.  Template Text

a.  Certain RFCs may contain text designated as “Template Text” by
the inclusion of the following legend in the introduction to the
RFC: “This RFC contains text intended for use as a template as
designated below by the markers <BEGIN TEMPLATE TEXT> and <END
TEMPLATE TEXT> or other clear designation.  Such Template Text is
subject to the provisions of Section 9(b) of the Trust Legal
Provisions.”

b.   In addition to the other rights granted under the TLP with
respect to each RFC, the Trust grants to all interested persons a
non-exclusive, royalty-free, worldwide, perpetual right and license
under all copyrights and rights of authors to insert specific
information in place of blanks or place-holders in the Template
Text, and to reproduce, publish and distribute the Template Text
combined with such insertions.

The Trust had been requested by the IESG and RFC Editor to provide a
license in cases where RFCs contain Templates.  The Trustees
proposed language to the community and clarified the proposed
language based upon the community input.

The Trustees will ratify their e-vote at its next schedule meeting
on 25 March 2015 in accordance with its Administrative Procedures
regarding electronic voting and then publish the next version of the
Trust Legal Provisions, TLP 5.0.

The Trust posted a request for review by the community on 27 January
2015. The comment period ran until 25 February 2015.

A number of specific matters were brought up that included:

1.  Text seemed to permit modification of the template text itself.
The text was revised to make the aim clearer:

Original Proposed Language for paragraph b:

b.   In addition to the other rights granted under the TLP with
respect to each RFC, the Trust grants to all interested persons a
non-exclusive, royalty-free, worldwide, perpetual right and license
under all copyrights and rights of authors to make, reproduce,
publish and distribute modifications of the Template Text (e.g., to
insert specific information in place of blanks or place-holders),
and reproduce, modify and distribute such modified Template Text.

2.  Option cannot be used on template based on pre-5378 RFCs.

Considered a non-issue for the TLP text since the enabling text
needs to be in the template RFC and any issue of pre-5378 can be
addressed at the time of the publication of the template RFC.

3.  Do I have to use this?

No, it is voluntary, however if you are writing a template RFC it
would be unworkable for its intended use as a template to not use
it.

4.  Should we go back to “do what you want with RFCs”?

Topic is out of scope for this particular matter, but re-discussing
may be inevitable in the future.

Ray Pelletier 
Trustee 
IETF Trust 
IETF Administrative Director

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Mar 2015 11:40:43 -0400

I'm disappointed that the trust chose to remove the right to modify
template text.

This makes it impossible to write open-source software for filling in
templates in these RFCs; I am disappointed the trust has chosen to take
this step.

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Mar 2015 11:35:45 -0400

--On Thursday, March 12, 2015 11:40 -0400 Sam Hartman
<[email-masked]> wrote:

> I'm disappointed that the trust chose to remove the right to
> modify template text.
> 
> This makes it impossible to write open-source software for
> filling in templates in these RFCs; I am disappointed the
> trust has chosen to take this step.

Sam,

This may go back to our earlier (apparent) disagreement on the
subject.   IANAL or nearly a good enough approximation to one to
be competent to assess the details, but my presumption continues
to be that the basic rules about RFCs, plus this language,
allows the type of application you are concerned about as long
as the version of the template in the application is an exact
copy.  Given that language, one would certainly have to
acknowledge where the template came from, but that would
probably be necessary for practical reasons (independent of
legal considerations). 

Given that the issue has been raised and is important, I'm
disappointed that the Trust didn't choose to make the intent and
limits absolutely clear whether they intended the narrow
interpretation you infer or the broader one that I do.  In
particular, if the intent is that someone building such an
application be required to ask permission (which I think would
be silly as well as damaging), it would be good for the text to
be clear about that).

  best,
    john

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Mar 2015 11:57:59 -0400

> be silly as well as damaging), it would be good for the text to

"as long as the version of the template in the application is an exact copy" 
is the problem.  Freedom to modify is a fundamental principle of free and open 
source software.  It's OK from a FOSS perspective to say "If you change it, 
you have to call it something else" to avoid confusion, but it has to be 
legally modifiable.

Scott K

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Mar 2015 14:32:30 -0400

--On Friday, March 13, 2015 11:57 -0400 Scott Kitterman
<[email-masked]> wrote:

>...
> "as long as the version of the template in the application is
> an exact copy"  is the problem.  Freedom to modify is a
> fundamental principle of free and open  source software.

Scott, I think that is an overgeneralization and a risk, but one
that is actually not relevant to what I see as the issue here.
I don't believe that anyone would seriously claim that the right
to misrepresent is a fundamental principle of FOSS or anything
else attractive.  So...

>  It's
> OK from a FOSS perspective to say "If you change it,  you have
> to call it something else" to avoid confusion, but it has to
> be  legally modifiable.

First of all, "use but acknowledge (and, by the way, don't
misrepresent)" is exactly what I believe is allowed under
existing rules.  If you, Sam, or others believe that existing
rules and/or the new template rules don't allow that, then I'm
in agreement with you that needs to be explicit in the template
rules (and, btw, for most uses of RFC text of other sorts).

Beyond that, if the rule says something equivalent to "copy
without modification other than providing for filling in
blanks", that doesn't prevent writing FOSS software that does
just that, nor does it prevent writing FOSS software that
supports filling in of templates.  I can imagine several ways in
which it would make such software less attractive than one might
optimally like.  If I believed your assertion in its broadest
form, I can imagine how the rule would offend someone's moral
sense and thereby cause them to decide to spend time in other
ways that writing such software.  But I'm unpersuaded that it
_prevents_ someone from writing such software.

   best,
    john

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Mar 2015 15:19:58 -0400

> to misrepresent is a fundamental principle of FOSS or anything

There are approximately as many visions of what FOSS is as there are people 
involved in it, so almost any generalization is inherently an over 
generalization.

It is OK (at least in the FOSS contexts with which I'm most familiar) to 
require renaming if something is modified.  Such a requirement allows concerns 
about misrepresentations to be mitigated.  

> rules (and, btw, for most uses of RFC text of other sorts).

If you look at what changed with the final version the change in paragraph b 
from "to make, reproduce, publish and distribute modifications of the Template 
Text (e.g., to insert specific information in place of blanks or place-
holders), and reproduce, modify and distribute such modified Template Text." to 
"insert specific information in place of blanks or place-holders in the 
Template Text, and to reproduce, publish and distribute the Template Text 
combined with such insertions." it's very clear that modifications to the 
template text are not meant to be allowed.

> _prevents_ someone from writing such software.

More precisely it prevents the template itself from being included in the FOSS 
software and having the combined work be considered Free. Writing the software 
to work without having the template immediately available isn't as you 
suggest, impossible, but it's substantially complicating.  Further, it's a 
complication that serves no purpose.  As I read it, the template text isn't 
modifiable at all.

Scott K

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Mar 2015 16:08:01 -0400

--On Friday, March 13, 2015 15:40 -0400 Sam Hartman
<[email-masked]> wrote:

>>>>>> "John" == John C Klensin <[email-masked]> writes:
> 
>     John> Sam,
> 
>     John> This may go back to our earlier (apparent)
> disagreement on the     John> subject.  IANAL or nearly a good
> enough approximation to one     John> to be competent to
> assess the details, but my presumption     John> continues to
> be that the basic rules about RFCs, plus this     John>
> language, allows the type of application you are concerned
> John> about as long as the version of the template in the
> John> application is an exact copy.  
> 
> You're absolutely right.  However, the requirement that the
> application be an exact copy is in and of itself enough to
> make such software fail to comply with the Open Source
> Definition, the Debian Free Software Guidelines, and the Free
> Software Foundation's definition of free software.
> So, on its face you cannot do that in a free software or
> open-source application.
> 
> My strong belief is that in this instance the IETF's interests
> are better served by cooperating with the
> open-source/free-software community than by preventing
> modification of the templates.

As I have been trying to explain in a different context to Scott
Kitterman, I suspect we agree in everything but language and
tone.    Certainly it is not in the IETF's best interest to
prevent reasonable software that enables template-filling-in
software from being written.  I personally contend that it is
also not in the IETF's best interest to encourage, or even
allow, modifications to templates that would permit
misrepresentation of the results or, more importantly, would
facilitate the creation of filled-in templates that IANA, for
example, would reject because they were inconsistent with the
templates specified for a given registry.

I don't see those two objectives as being inconsistent in any
way.  It is certainly possible to formulate heavy-handed ways to
express one or the other that would be a problem but, if the
community is in agreement with both principles (and I haven't
heard anyone speak up in opposition to either as long as they
don't have bad effects on the other), then the question is
whether the Trust's language is consistent with the community's
intent.

You and Scott (and probably others) apparently believe we have
gotten into exactly the situation in which the community's
intent about the first principle is being blocked by the Trust's
langauge.  I don't think I have a competent opinion on the
subject although it occurs to me that, if we are getting hung up
on what "exact copy" means, some long-term review of the
licenses you cite may be in order too.

But I hope the three of us could join in asking the Trust and
its Counsel to work directly with the relevant people associated
with the licenses you cite to come up with mutually-acceptable
language.  

IMO, if we can't sort this out without a lot more pain and
aggravation, we _really_ need to consider going back to some
reasonable approximation to "acknowledge, be clear about
changes, but otherwise do what you like with RFCs".  That may
not be the only reasonable answer, but, IMO, the cost of  these
discussions is rising above the benefits of more restrictive and
precise policies.

       john

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Mar 2015 16:55:53 -0400

> discussions is rising above the benefits of more restrictive and

I think your desire to prevent misrepresentation is quite reasonable.

I'd be glad to help out with coming up with something that meets both that 
goal and is free software friendly.

Scott K

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 13 Mar 2015 17:07:18 -0700

FWIW, the Trust doesn't actually own copyright to any of the templates
within RFCs.  At most, the Trust owns copyright to the RFC end-product,
as produced by the RFC editor, and can control republication as an RFC
(or similar compilations) with permission from the individual copyright
owners.

And it certainly isn't necessary to provide permission to fill-in a
template, since the document itself is telling you to fill-in the
template and reproduce it for the purpose of submission.  Hence,
that permission is implied by the author(s), one of which (or their
employer) is probably the true copyright owner of the template text.

And even if the Trust did own copyright to the template and chose to
forbid changes to that template, such copyright would not extend
to a software form that merely reflects the same or similar structure,
names, and purpose, even if it submitted incorrect fields to some
IANA address; none of those things are allowed to be copyrightable.
Patentable, perhaps, but not copyrightable.

And, for crying out loud, IT IS NOT NECESSARY TO PROVIDE LICENSING
TEXT WITHIN THE RFC INTRODUCTION!  You can do that as a general policy
for the IETF as a whole, within any webpage on the IETF website, and
it is just as legally valid notification of *permission* as pasting it
within a few thousand standards documents.  The only time that notices
might need to be pasted all over the place is when you are taking a
permission away that the recipient might otherwise expect to have,
and even then the only difference the notice makes is that it might
be easier for you to sue for damages.

In short, WTF?  The Trustees should know enough about basic
intellectual property law and the purpose of the IETF to avoid
this kind of ritualistic insanity.

....Roy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Mar 2015 20:17:21 -0400

> you have to call it something else" to avoid confusion, but it has to be

So according to open source ideology you have to be allowed to change the
value of pi if you like?

I think the IETF trust approach is obviously not a problem unless people
want to make it into one. At the end of the day the only place the words in
a legal document take precedence over common sense is a court of law.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Mar 2015 22:22:23 -0400

> So according to open source ideology you have to be allowed to change the

No.

> a legal document take precedence over common sense is a court of law.

Right, but the best way to stay out of that court is to pay attention to what 
they say.  There's no conflict between what the IETF needs and what free 
software needs, it just happens that this particular formulation doesn't work 
very well for both.

Scott K

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Mar 2015 15:40:51 -0400

John> Sam,

    John> This may go back to our earlier (apparent) disagreement on the
    John> subject.  IANAL or nearly a good enough approximation to one
    John> to be competent to assess the details, but my presumption
    John> continues to be that the basic rules about RFCs, plus this
    John> language, allows the type of application you are concerned
    John> about as long as the version of the template in the
    John> application is an exact copy.  

You're absolutely right.  However, the requirement that the application
be an exact copy is in and of itself enough to make such software fail
to comply with the Open Source Definition, the Debian Free Software
Guidelines, and the Free Software Foundation's definition of free
software.
So, on its face you cannot do that in a free software or open-source
application.

My strong belief is that in this instance the IETF's interests are
better served by cooperating with the open-source/free-software
community than by preventing modification of the templates.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Mar 2015 16:42:26 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> As I have been trying to explain in a different context to
    John> Scott Kitterman, I suspect we agree in everything but language
    John> and tone.  Certainly it is not in the IETF's best interest to
    John> prevent reasonable software that enables template-filling-in
    John> software from being written.  

I'd go beyond that and say that I want to be able to write open-source
software or free-software that accomplishes that goal.
Both of those are terms with specific definitions.
I want to be able to include such software in Debian GNU/Linux, I want
to be able to include such software in Fedora.
In order to do so, the software needs to be open-source/free-software.
That's how those communities work.

    John> I personally contend that it is
    John> also not in the IETF's best interest to encourage, or even
    John> allow, modifications to templates that would permit
    John> misrepresentation of the results or, more importantly, would
    John> facilitate the creation of filled-in templates that IANA, for
    John> example, would reject because they were inconsistent with the
    John> templates specified for a given registry.

    John> I don't see those two objectives as being inconsistent in any
    John> way.

I do.
If you remove the word allow from the above, we're in agreement.
In particular, I think the IETF should discourage such modifications.

However, the fundamental principle behind free software, and a huge
component of open-source software (if not a fundamental principle) is to
allow modification of every aspect of the software.

I see it as inherently inconsistent to disallow modifications while
requiring modifications be allowed.

    John> You and Scott (and probably others) apparently believe we have
    John> gotten into exactly the situation in which the community's
    John> intent about the first principle is being blocked by the
    John> Trust's langauge.  I don't think I have a competent opinion on
    John> the subject although it occurs to me that, if we are getting
    John> hung up on what "exact copy" means, some long-term review of
    John> the licenses you cite may be in order too.
for your review:

http://opensource.org/osd-annotated
https://www.debian.org/social_contract
https://www.debian.org/social_contract
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=92810 (older bug
discussing why IETF documents are problematic for free-software prior to
current BCPs)

The current BCPs make the problem significantly worse.

    John> But I hope the three of us could join in asking the Trust and
    John> its Counsel to work directly with the relevant people
    John> associated with the licenses you cite to come up with
    John> mutually-acceptable language.

Nod. I'm happy to engage within Debian.
For example if  you'd like us to come up with an official statement that
 forbidding modifications of the templates makes them something we
 cannot include, I could do that.  I am sure that would be an easy
 consensus to achieve, although there might be some disagreement on who
 should send such a statement or how to approve it.

I believe I could also help facilitate contact with the Free Software
Foundation.  I don't personally know folks at the Open Source Initiative
(or at least don't know that I know them) but I'm sure we could find
them and engage them.

    John> IMO, if we can't sort this out without a lot more pain and
    John> aggravation, we _really_ need to consider going back to some
    John> reasonable approximation to "acknowledge, be clear about
    John> changes, but otherwise do what you like with RFCs".  That may
    John> not be the only reasonable answer, but, IMO, the cost of these
    John> discussions is rising above the benefits of more restrictive
    John> and precise policies.

I'd strongly support this; I've always supported a less restrictive
approach.