Subject: Copyright issues and authors (was: Re: One copyright issue or Two?)

From: John C Klensin <[email-masked]>
Date: Sat, 10 Dec 2005 20:03:25 -0500

Simon, Chuck, and others,

While I applaud your efforts to try to come up with exactly the
right text here, from my perspective some of the point may be
getting lost in the discussion.

I want to note that I've contributed more RFCs, both standards
track and informational, to the IETF than both of you combined,
and made major contributions to several more on which my name
does not appear except occasionally in Acknowledgements.  That
doesn't give my views any special standing, but I feel a need to
stress that I have considerable skin in this game -- I'm not
just theorizing or arguing on behalf of some communities of
standards-users of unknown size, in some cases communities who
appear to be uncommonly inflexible.  At various times, I've done
that work while working in a research position for a university,
for a couple of different corporations, for a UN-component
agency, and while self-employed.  That collection of
organizations run the full spectrum of attitudes toward their
rights in IPR that was developed on their funds from "very
relaxed" to "extremely protective".

As I've noted before, I've also worked in standards bodies (and
continue to do so) in which the price of admission is either any
agreement that any contribution is a work for hire by the
standards body itself or agreement to explicitly sign over all
copyrights and any associated rights as a condition of approval
and publication.  More on that below.

The following comments are very personal ones.  I am probably
far more conservative and protective about this than most of the
community.  But I believe that we have been hearing a little too
much from the other extreme, so the conservative- traditional-
protective needs to be clearly on the table.

The long-term position of the IETF and its predecessors has been
that, if my name appears at the top of a document, it is _mine_.
I release to the IETF precisely those rights, and only those
rights, necessary to permit unlimited distribution of an intact
document and to permit the IETF to use the document in
conjunction with the standards process.  Period.  Full stop.  I
am willing to give the IETF (presumably via the IESG and/or
IAOC) considerable latitude to interpret what is necessary "in
conjunction with the standards process" as long as they have a
set of principles about the decisions that are to be made and
that the are applied consistently.   

Our efforts to express that position precisely in IPR language
have never been very successful, IMO, but that is really a
separate issue. 

With regard to I-Ds and anything else not formally published
(e.g., by the RFC Editor), I have an even stronger position: I
take "expires after six months" very seriously.  While I have
never exercised it, and probably never will, I consider the
right to insist that an I-D older than six months old be taken
off servers and repositories to be very important.  I am willing
to make anything I say on an IETF-related mailing list available
for use by the IETF in the standards process, but for no other
purpose.  I believe that taking those rights away from me would
have a chilling effect on my ability and willingness to explore
ideas that might never go anywhere.  More important, if there
are others like me, I would expect that removing those rights
would push the IETF away from a "most real work gets done on
mailing lists" model and toward a model in which everything
important happens in face to face meetings.

There are many reasons for that collection of attitudes, but the
key one is that my name is on top of the document.  If someone
pulls text out of one of my documents without attribution and
for a non-IETF purpose, they cause me harm.  How much harm is a
matter between me and them, not a three-way situation in which
the IETF is involved.  Conversely, if something is extracted and
attributed to me (even by properly citing an RFC), but reflects
opinions I don't hold or is used in a context which I'm not
happy about, that also harms me.

Bluntly, if some organization wants to slice and dice an RFC for
its own purposes, disclaimers or prohibitions on using some text
are not, under the current model, going to be sufficient.  They
need to deal with the author(s) not the IESG or a blanket
license.  If an author wants to give blanket extraction and
derived works rights, I think it would be good for the IETF to
have a standard way to do that and to be able to specify what
IETF-related words cannot be included (and I would strongly
encourage looking at Creative Commons models, rather than
software licensing ones, for inspiration).  But the author needs
to be able to say "no" or even impose selective conditions
(including potential royalties or other charges) or the current
model falls apart.  And I think all of us need to understand
what is really at stake here:  copyright has never protected
ideas, only particular expressions of those ideas.  If rights to
extract and derive --beyond those needed to apply the standard--
are not granted to particular software developers, then those
software developers simply need to invest the resources to
develop their own documentation as needed.    The IETF should
not be in the business of guaranteeing a subsidy, one that
offsets some documentation costs, to a particular fraction of
the developer community, open source or otherwise.

I'm not going to give up those rights in previous documents.  If
the IETF insists that I give them up in future documents without
any other changes in the way things are done, I may vote with my
feet.  Brian has suggested that, beyond a certain threshold,
insisting that companies that are IPR-sensitive sign over more
rights than they think necessary would cause those companies to
drop out and forbid participation by their employees.  Whether
the number of them, added to the number of people whose
reactions are similar to mine, would be significant to the IETF
is anyone's guess.  But the IETF would be ill-advised to drive
away too many of the people who are are actually doing the work
in addition to or instead of hair-splitting over IPR.

Now, as I have pointed out before, there is an alternative to
this, which is to insist on transferring all rights to the IETF
and then let the IETF grant rights to others, including the
author(s).  I floated that as a possibility a few weeks ago.   I
didn't mention the second element that the standards bodies that
insist on doing things that way usually apply, which is to
publish their standards without authorship attribution: there
are no names at the top of the page and, depending on the
standards body and their conventions that year, it may be
reasonably hard to figure out who the editor actually was.  They
really do go together: the author(s) and editor(s) give up all
rights and the standards body presents the document as a
group/aggregate work with no one person having any special
responsibility (or credit or blame).  I believe I got one
positive response and many negative ones to that crude proposal.
Frankly, that was the outcome I had hoped for: I think the
current model is one of the things that makes the IETF both
unusual and effective.   Were we to make that shift, it would
undoubtedly cost us some contributors too: the motivations for
doing work around here vary and I don't think anyone understands
all of them.

So, if you are ready to propose to change the system entirely,
please make that proposal, preferably in I-D form, and let's
discuss it... with the understanding that such a proposal would
have impacts far outside the scope of this WG.   If you are not,
I suggest that you had best concentrate at least as much on what
those who are willing to contribute time as authors and editors
and, where relevant, the organizations who support them are
willing to give the IETF, and for what purposes, as on what you
think the IETF should give away.

regards,
   john

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

---

From: "todd glassey" <[email-masked]>
Date: Sat, 10 Dec 2005 20:14:47 -0800

Thank you John!

Todd Glassey
----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>; "Powers Chuck-RXCP20"
<[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 10, 2005 5:03 PM
Subject: Copyright issues and authors (was: Re: One copyright issue or Two?)

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Dec 2005 15:09:08 -0500

Hi.  I just received and answered a private note on this subject
that inspired another thought (I wish that, if people have
things to say to me (or others) that are of general interest,
they would just say them on-list).

In at least some contexts, it is clear that we are confusing two
separate roles of standards-track RFCs.  One of them, the
classic version, is to describe, define, and document a
standard.  As such, they are expressions of that standard and
all of my prior note applies.   But they often also contain
pieces of syntax -- ABNF, ASN.1, specific MIB definitions, XML
schema, etc. -- that people expect to extract directly into code
and process.

At least as a way of helping us to think about this, let's
separate the two (noting that we have done some of that in the
past).  Assume that, when standards are created that contain
code or definitions that are intended to be machine-processed,
we copy those excerpts into a separate library.  We leave the
decision as to what needs to be extracted to the library to the
IESG, acting on recommendations from authors, WGs, etc., and
subject to Last Call and appeal.   If we do things that way, the
library would essentially consist of reference definitions of
MIBs, XML schema, non-MIB chunks of ASN.1, certain tables, etc.,
without prose definitions.  We could then recast the RFCs as
_documentation_ of the elements of those libraries, recording
snapshots of their contents for archival purposes.  The
libraries could, presumably, carry a different set of IPR
restrictions (or permissions) than the RFCs themselves.

Even if we actually created such libraries, we would still have
some issues with legacy RFCs but the nature of those issues
changes.  Clearly, the IETF has the right to make the needed
extracts in support of the standards process.  I would think
that authors would, at least in general, be much more
comfortable about granting broad rights to executable
definitions and code snippets than to explanatory or
definitional prose (or even transferring all of those rights to
the IETF to support general use and reuse)... certainly I would
be.

As I said in my earlier note, I don't think anyone needs, or
has, the "right" to copy and alter descriptive text without
specific permission of the authors.  One can always incorporate
those materials by reference or rewrite them if permission is
not easily available.

Whether we actually need to make that separation or not is a
question that needs to be addressed to the lawyers.  Not making
it would essentially require different IPR rules for some
portions of some RFCs than for standards-track RFCs in general
and for being able to clearly differentiate between the
portions.   Making it would be much more clear, and would
provide us with a way to make clear corrections if errors were
found in those definitions without having to change the
underlying RFCs.  But it would involve some costs (although I'm
certain that they would be less that the total costs of this
ongoing discussion). 

But, at a minimum, it may be a helpful way to start thinking
about the problem.  And it may be a way to capture a variation
on what Dave Black has described as "permission to practice the
standard" into more concrete terms while preserving author
rights.

My thanks to my correspondent, who presumably wants to remain
anonymous, for inspiring the above.

      john

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Dec 2005 22:30:09 +0100

John C Klensin wrote:

> I would strongly encourage looking at Creative Commons
> models, rather than software licensing ones, for inspiration

+1  Apparently you wouldn't wish to go as far as CC BY SA for
texts with your name as one of the authors, and apparently (?)
Simon prefers CC BY or even less, very near to PD   Allowing
authors to pick an-IETF compatible CC license would be nice:

The "boilerplate" for this aspect of the legalese could be a
one-liner with a link to the relevant IETF compatible CC text.

And if these texts include the "must have" to protect ISOC,
RfC editor, and authors against potential damages, then they
could also reduce the amount of BCP 78 legalese required in
all drafts today.

For interesting cases involving patents and what not it's no
issue to offer monstrous boilerplates.  But for simple cases
like "self-employed author promises that this is his or her
own wannabe-brilliant idea as far as he or she can judge it"
there should be something less elaborated that the current
style of boilerplate.

Some authors and contributors, real or wannabe, are no lawyers,
have no lawyers, and might like to avoid any legalese as far
as possible.  With the CC model I have an idea what it means.

CC already covers what Sam proposed here, a human readable FAQ-
style explanation for folks like me, who are not supposed to
read this list, let alone post.  

Unlike many other articles here I hope that I understood what
you, Sam, and Todd were talking about.  For Simon and BCP 78/79
I'm less confident.  Not their fault that IANAL, but I'd really
like some "translations" for the POVs of ordinary readers and
authors.

If Simon wants some $insert-favourite-FOSS-license compatible
model, then I simply don't see how this would still protect me
against $insert-evil-company, and the latter has the budget to
fight it out.  
                              Bye, Frank

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Dec 2005 12:20:23 +0100

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

> past).

It seems I will have to discuss this issue in my draft too.

I don't believe this separation will solve all problems.  It would not
solve the following problems:

* Excerpts from RFCs included in source code comments.  This is a
  common example, many free IETF implementations embed excerpts from
  the RFC text in source code comments.

* Teaching material derived from RFC texts.  University teacher may
  want to modify RFCs to illustrate a point and as an implementation
  exercises, and include the resulting work in freely available online
  course material.

* Documentation for IETF implementations.  Both FreeBSD and Sun has
  shipped a getaddrinfo man page that is derived from the RFC.  I
  believe being able to inherit that text from the RFC helped getting
  getaddrinfo implemented and utilized.  If implementations are not
  permitted to do this, adoption of IETF protocols will likely be
  slower.  If we believe the IETF is producing standards that, if
  adopted, would benefit the IETF, I believe we should make sure they
  can be implemented as fast and as widely as possible.

There may be other problems as well, that would only be revealed if
someone wrote a document describing your approach in more details.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Dec 2005 12:31:45 +0100

Frank Ellermann <[email-masked]> writes:

> Simon prefers CC BY or even less, very near to PD

Creative Commons Attribution-Sharealike 2.0 [1] and Creative Commons
Attribution 2.0 [2] licenses are both GPL incompatible [3].

I think Public Domain (without further qualification) will not work,
since in several jurisdictions (like most of the European Union), it
is not possible to voluntary place works into the public domain.  I
believe the IETF should avoid to pick a US-centric license model.

> against $insert-evil-company, and the latter has the budget to

I don't follow.  What are you worried that a company might do?

Thanks,
Simon

[1] http://creativecommons.org/licenses/by-sa/2.0/legalcode
[2] http://creativecommons.org/licenses/by/2.0/legalcode
[3] http://www.gnu.org/licenses/license-list.html#TOCOtherLicenses

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Dec 2005 07:10:39 -0500

There is an interesting point about these examples.

As distinct from the issues of using the code-like portions, or fixing bugs 
in code one has used, these examples are optional.
It is not necessary in order to have an open implementation of the RFC that 
we permit the implementation to use the text of the RFC.  It is necessary 
that we permit the use of the code fragments.

At the moment (and my opinion has shifted and probably will shift again 
during this debate) my inclination is to find away to use code and code 
fragments in open source, with suitable warnings that changes are a bad 
idea (but permitted so as not to conflict with the necessary licenses.)
And to declare that reasonable excerpts from text can be used if they are 
preserved unmodified.
That may mean that some open source material can not use the text.
It is not clear that such is a fatal restriction.  Or even enough of a 
restriction to prompt folks to go write a competing standard.

Yours,
Joel

---

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

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

> As distinct from the issues of using the code-like portions, or fixing
> bugs in code one has used, these examples are optional.
> It is not necessary in order to have an open implementation of the RFC
> that we permit the implementation to use the text of the RFC.  It is
> necessary that we permit the use of the code fragments.

I don't follow this distinction.

Several code-like portions of RFCs are not normative.  It is not
always the case that you have to use the code-like portion to
implement the RFC.

Using your argumentation, we thus don't need a BSD/GPL compatible
license on the software published in RFCs either.

Examples of both sides of the coin:

1) Few free implementation of the MD5 or SHA-1 algorithm use the
   implementation in RFC 132 or RFC 3174.

2) The Punycode sample code in RFC 3492 is well-written and portable,
   and is thus being widely used.  (I'm using it in my GNU Libidn
   implementation.)  This certainly lead to faster adoption of
   Punycode.

I argue that making it _possible_ for people to use both the text and
the code in their implementations leads to faster adoption of the
standard and leads to a better Internet in general.

What portion of the RFC people chose to use should be up to them.  The
IETF's power is in providing reviewed specification that is possible
to implement widely.  The IETF has limited powers to force people to
do anything, it can only influence them by leading by example.  If the
IETF make it too cumbersome to follow or implement its specifications,
the IETF will lose its power.

> At the moment (and my opinion has shifted and probably will shift
> again during this debate) my inclination is to find away to use code
> and code fragments in open source, with suitable warnings that changes
> are a bad idea (but permitted so as not to conflict with the necessary
> licenses.)
> And to declare that reasonable excerpts from text can be used if they
> are preserved unmodified.

That is not compatible with the BSD or GPL licenses, nor Debian's Free
Software Guidelines.

Please answer this question for yourself: Do you believe it is in the
best interests of the IETF to use a license that enable free and/or
proprietary implementations to incorporate portions of the RFC?

> restriction to prompt folks to go write a competing standard.

I don't think we should need that impediment to change our license.
Simply making it as easy as possible for people to use and implement
IETF standards should be in the best interests of the IETF.

Given that Debian and the FreeBSD communities appear to route around
the IETF to avoid legal problems, the IETF should react and decide
whether it is in the best interest of the IETF to change the license.
That reaction and decision is what I'm trying to speed up by arguing
for my draft.

Thanks,
Simon

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 12 Dec 2005 13:43:27 +0000

> That is not compatible with the BSD or GPL licenses, nor Debian's Free

The code use suggestion is entirely compatible with the GPL and Debian's 
free software guidelines. The text use suggestion obviously isn't.

(I suspect that that's what Simon meant, but just wanted to clarify)

-- 
Matthew Garrett | [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Dec 2005 14:50:12 +0100

> protective needs to be clearly on the table.

Thanks for providing more input.  This process has been lacking in
input from all sides.

> that, if my name appears at the top of a document, it is _mine_.

I think the ISOC copyright notice on the document should have made you
think otherwise.

To me, the point of IETF documents is to serve its community and to
get "real" things done (i.e., interoperable implementations and
products).  IETF documents are not primarily an ego trip for the
author.  However, the community has realized that ego trips is one of
its best motivators to make things happen, though.  I imagine that
this is one of the reasons IETF doesn't require exclusive rights to
its documents.  Of course, this process has probably never been
consciously decided, but in retrospect we can extrapolate what factors
affected the unconscious decisions that lead to the IETF's growth and
influence power.

> conjunction with the standards process.  Period.  Full stop.

I'd like to modify that slightly.  Authors release the rights needed
by the community to make us of the document.

Those rights may change over time.  In the past, there was no need to
be able to modify the document.  People fortunately hadn't realized
the perils of IPR legal issues.  Today, I believe the community need
the right to adapt and modify portions of RFCs in order to protect
their investment.  If they don't have those rights, they will write
specifications and implementations from scratch, and the IETF will
lose its influence to those who actually do the real work.

> I am willing to give the IETF (presumably via the IESG and/or IAOC)
> considerable latitude to interpret what is necessary "in conjunction
> with the standards process" as long as they have a set of principles
> about the decisions that are to be made and that the are applied
> consistently.

I agree.  I believe the IETF has to realize that granting third
parties the rights to modify its output is one thing that is important
in the standards process.

> have never been very successful, IMO, but that is really a

Agreed.  I wish the intentions of past IPR documents had been
documented in more detail.  It is difficult for me who wasn't part of
the IETF during the early days to understand what the intentions
really were.

> feet.

You are not the only one who will do that.  Debian, and to some extent
FreeBSD, are doing that.  They appear to fear re-using material
derived from IETF RFCs due to license incompatibilities.

> think the IETF should give away.

Understood.  However, there is a trade-off.  You can't protect all
rights to a document that is intended to be consumed by everyone.

I don't believe I'm proposing to change anything radically.  I'm
trying to tweak the license text in RFC 2026 to be free software
compatible.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Dec 2005 14:59:16 +0100

> (I suspect that that's what Simon meant, but just wanted to clarify)

Right, thanks!  When I re-read that, I see how unclear it was.

I want to note that Debian (and FreeBSD) seem to want to be able to
re-use text and not only code.  The examples for that is that Debian
could not ship RFC text in their distribution, and that FreeBSD could
not ship the getaddrinfo etc man pages.

My point was that a license that restrict modifications to text will
not be BSD/GPL compatible, and thus not acceptable to the Debian
community.  In other words, if you believe you solve anything by
separating code and text, I think you are only making things more
complex.  I still would like to see Internet-Draft proposals on this
approach though.  It is difficult to extract what legal text people
intend based on mailing-list discussion.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Dec 2005 15:46:44 +0100

Matthew Garrett wrote:
> free software guidelines.

I think that's a pretty good approach, but Sam suggested that a restriction
in the IETF license that code extracts can only be open-sourced for use in
code conflicts with the GPL. We, presumably, don't want to prevent bugs
in code being fixed in implementations, but we do want to retain change
control when the code is placed in a "rival" specification.

> The text use suggestion obviously isn't.

And if that's the case, our requirement to retain change control will
prevent use of IETF text in GPL source.

     Brian

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 12 Dec 2005 15:24:41 +0000

> control when the code is placed in a "rival" specification.

Oh, yes - stating that code can only be used in executables is 
likely to be incompatible with all open source licenses. But it's not 
terribly clear to me why that would be desirable, and any attempt to 
enforce it would probably make things like printing application source 
code impossible...

> prevent use of IETF text in GPL source.

If there's a hard requirement that all change control be controlled by 
the IETF, then there's no way that the text can be considered compatible 
with open source work.

(There's a minor caveat here. Licenses such as the BSD license allow 
code under them to be incorporated into larger works that include 
portions under non-open source licenses. This is sometimes referred to 
as "license compatibility". However, the work as a whole is no longer 
under the BSD license, and the work cannot be described as open source)

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Dec 2005 15:56:48 -0500

--On Monday, 12 December, 2005 14:59 +0100 Simon Josefsson
<[email-masked]> wrote:

>...
> I want to note that Debian (and FreeBSD) seem to want to be
> able to re-use text and not only code.  The examples for that
> is that Debian could not ship RFC text in their distribution,
> and that FreeBSD could not ship the getaddrinfo etc man pages.
> 
> My point was that a license that restrict modifications to
> text will not be BSD/GPL compatible, and thus not acceptable
> to the Debian community.  In other words, if you believe you
> solve anything by separating code and text, I think you are
> only making things more complex.  I still would like to see
> Internet-Draft proposals on this approach though.  It is
> difficult to extract what legal text people intend based on
> mailing-list discussion.

Simon, 

I might write an I-D, although I want to hear other comments
first.  However, I'm not going to write "legal text".  It is my
personal opinion that much of what has caused the disconnects
between our intent and principles and what has gotten written
into the BCPs is a consequence of amateurs writing legal text or
approximations to it.  We then check that text with the lawyers,
who tune it to what they think the approximations means, and the
question of "does this end result adequately reflect our
principle and intent" never is  asked quite carefully enough
until someone discovers a glitch some months or years later.
Then we do it again.

But there is a difference in principles here, and that is what,
IMO, we should be addressing.  I'm going to create a
hypothetical example because I don't want to get distracted by a
debate about the requirements of particular entities.  

Suppose a new open software entity comes into being that
concludes that the most common licenses (open source, RAND, and
otherwise) are untenable and that the only real way to keep
software open is to have all rights, in everything, transferred
to it so it can hold them as a public trust.  Their license
isn't "share alike", it is the most extreme form of "what's mine
in mine and, if you have even looked at what is mine, what used
to be yours is mine too", but with the provision that use of
their software or documentation, for any purpose, is free and
unrestricted.   Let's call this hypothetical entity Snafuian.

Now, lets suppose that, in addition to that requirement, they
also assert that they would not accept and implement any
standard unless it was produced with both a reference
implementation that they were free to either incorporate as-is
or improve as they liked and complete user-level documentation
that they could also use in any way they considered appropriate.
They would exempt the reference implementation and the
documentation from their "we own it" requirement as long as they
didn't make any changes that added value (as they defined value)
but, as soon as such changes were made, it became theirs too.

Let's also suppose that this entity is headquartered in the
communities of Redmonk and Armond and that its strategies for
dealing with standards bodies and others involve (or have
involved from time to time) equal measures of trying to create
market pressures to overwhelm pressures to get things right,
doses of FUD, and raw threats of what they will do if people
don't roll over to their wishes.  And, of course, they have
several staff or supporters who can generate enough traffic on
mailing lists to constitute a denial of input attack on any
other discussion.

Now, this hypothetical entity and their licensing norms make
several things clear, at least to me:

(i) Because their license style appears to be incompatible with
all of Debian, BSD, GPL, and most commercial use and
implementations of software, having the IETF try to accommodate
the "needs" of all of them leads to madness. However, that
doesn't mean those needs can, or should, be ignored: the
community needs to make decisions about what can or cannot
reasonably be done.

(ii) There is a level of demands from any particular
organization or group of implementers to which the IETF should
not agree.  The question is figuring out the right boundary, not
simply saying "they make a large noise and have threatened to go
elsewhere, therefore we have to give in".

(iii) The IETF must make sure that its standards and IPR policy
are consistent with at least the minimum needed to actually
implement the standard.  That implies that copies of the
standard must be available and distribution must be possible to
those who are going to implement or evaluate implementations (it
is generally accepted in the community that requires
availability and distribution without fee or royalty is a
necessary part of this).  It implies that any code, tables, or
data structures that must be incorporated into implementations
be available for doing that.   But that is all -- anything else
is discretionary and a matter of judgment.  

If Snafuian requires that we provide user-level documentation in
order for them to adopt our standards, we can reasonably decide
to do that (although, IMO, it would result in our producing far
fewer standards), or to say "no, if the quality of our standards
is not good enough that you are willing to adopt them without
our providing free goodies, that is too bad".  Or, in principle,
we could create a user documentation-writing group, create such
documents, and charge anyone who wants to use that material for
its use... if Snafuian wants to buy, fine, and if not, also
fine.  But, if Snafuian insists that they need that
documentation, free, as a condition for adopting our standards,
well, sorry, but, IMO, that just would not be reasonable.

Similarly, if Snafuian requires production-quality reference
implementations that they can simply incorporate into their
systems and claim as their own, we could agree to that.  Or we
could respond that there are cases where it would be appropriate
and cases where it would not.  We would presumably be very
resistant to their claiming exclusive rights over our reference
implementations, but maybe we could talk them out of that before
they said "well, the way we read your rules, they don't
correspond to ours so we will go elsewhere until you guess what
we really want".  Or maybe we would say "we have never
_required_ a reference implementation, especially a free one,
and aren't going to start now" and then repeat some version of
the above comment about quality and free goodies.  

The line between making standards available with enough rights
to understand and implement them and being required to supply
free stuff to enable, enhance, or subsidize the efforts of
various developers isn't as clear as we might like, but it is
nonetheless there.  And some of this discussion seems to be
pushing it.

      john

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 12 Dec 2005 23:45:37 +0100

Simon Josefsson wrote:

>> If Simon wants some $insert-favourite-FOSS-license
>> compatible model, then I simply don't see how this would
>> still protect me against $insert-evil-company, and the
>> latter has the budget to fight it out.

> I don't follow.  What are you worried that a company might do?

http://en.wikipedia.org/wiki/Embrace%2C_extend_and_extinguish
as seen in the MARID SPF vs. PRA saga, where the state after
the appeals is still a SHOULD NOT vs. SHOULD stalemate.

> http://www.gnu.org/licenses/license-list.html#TOCOtherLicenses

Thanks for that link.  One thing I hate about all license
issues is the amount of legalese bound (instead of linked)
to the real text.  With BCP 78/79 it's about 3 KB.

With the GFDL 1.1 I'd get about 20 KB.  For an example see
<http://purl.net/xyzzy/Wget.htm#a50> - I can only hope
that I followed their rules, in other words I'm not sure.

Add another 21 KB for the GPL version 2 contained in this
document.  That makes a total of 41 KB legalese in about
150 KB.  This signal to noise ratio annoys me.

The more texts talk about legal issues the worse it gets
for authors and users.  Upper case text is an indicator
of legal trouble in US documents, or as BCP 79 puts it:

| Readers are advised to consult their own legal advisors
| if they would like a legal interpretation of their rights
| or the rights of the IETF in any Contributions they make.

My gut feeling is "I lose" with any legalese.  Bye, Frank

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Dec 2005 22:33:49 -0500

--On Monday, 12 December, 2005 14:50 +0100 Simon Josefsson
<[email-masked]> wrote:

>> far more conservative and protective about this than most of
>> the community.  But I believe that we have been hearing a
>> little too much from the other extreme, so the conservative-
>> traditional- protective needs to be clearly on the table.
> 
> Thanks for providing more input.  This process has been
> lacking in input from all sides.
> 
>> The long-term position of the IETF and its predecessors has
>> been that, if my name appears at the top of a document, it is
>> _mine_.
> 
> I think the ISOC copyright notice on the document should have
> made you think otherwise.

Nope.  The ISOC copyright notice makes me think that I have
released certain very specific rights to ISOC and the IETF, with
the expectation and on the condition that they pass reproduction
and distribution rights on to others.

> To me, the point of IETF documents is to serve its community
> and to get "real" things done (i.e., interoperable
> implementations and products).  IETF documents are not
> primarily an ego trip for the author.  However, the community
> has realized that ego trips is one of its best motivators to
> make things happen, though.  I imagine that this is one of the
> reasons IETF doesn't require exclusive rights to its
> documents.  Of course, this process has probably never been
> consciously decided, but in retrospect we can extrapolate what
> factors affected the unconscious decisions that lead to the
> IETF's growth and influence power.

Sorry, Simon.  I'm willing to do work for the IETF because I
think IETF's standards make the Internet work better and I'm
strongly committed to an Internet that works well.  I believe
that the cause of interoperable implementations and products is
well-served by giving implementers the ability to access, study,
and distribute standards documentation intact and by giving them
the ability to copy and reuse --without any restrictions at
all-- any code segments, tables, database definitions or the
like that are an integral part of the standards.  At the same
time --and I understand that we disagree about this-- I don't
believe that the interests of either implementations,
interoperability, or the overall good of the Internet are served
by encouraging the extraction and modification of explanatory or
definitional prose (mine or that of others) into other forms
that are "near standard" or "possibly-incompatible improvements
on the standard".   I also do not feel that it is reasonable for
you, Debian, or anyone else to insist that I supply you with end
user documentation as a condition of contributing something for
standardization.

>From my standpoint, one advantage of the current model is that
it permits me to enforce my own idiosyncratic preferences about
what can be done with my text without requiring that you share
my idiosyncrasies.  I firmly believe that, if you are ever the
author or editor of a standards track document, you should be
able to impose whatever restrictions you like --or the absence
of them-- on the portions of the text whose copying, extraction,
and modification into other works are not strictly required to
implement the standard.  I would also be happy to assign all
rights to the IETF, reserving only the right to reuse sections
of text for my own purposes, and letting the IETF handle any
further licensing.  However, we would then need to have a
discussion about the policies that the IETF leadership/ IETF
Trust should adopt and it is clear that reaching consensus on
those policies would be extremely difficult.

The notion that you need unlimited rights to extract textual
material from RFCs in order to write comments in programs
strikes me as completely bogus.  Even decent programmer I've
known or worked with understands both paraphrasing comments and
incorporation of material by reference: it is actually much
easier to write "; See RFC 9999 section 20.2" than it is to copy
large quantities of text.  You might have conventions that
encourage copying, but it is, at best, questionable whether that
is "necessary".

If you think that adds up to "ego trip", so be it.  But I'd
recommend, in the interest of the Internet and interoperability,
that you change your focus from tuning the IPR policies to
taking a more active role in actually getting standardization
work done around here.

>> rights, necessary to permit unlimited distribution of an
>> intact document and to permit the IETF to use the document in
> I'd like to modify that slightly.  Authors release the rights
> needed by the community to make us of the document.

See "considerable latitude" below.

> Those rights may change over time.  In the past, there was no
> need to be able to modify the document.  People fortunately
> hadn't realized the perils of IPR legal issues.  Today, I
> believe the community need the right to adapt and modify
> portions of RFCs in order to protect their investment.  If
> they don't have those rights, they will write specifications
> and implementations from scratch, and the IETF will lose its
> influence to those who actually do the real work.

You misread the history and may misunderstand the difference
between a standards body and, e.g., a technology development
consortium.  The history is that the companies who are most
proprietary about IPR tend to be extremely careful about what
they have the right to do and to change.  The IPR issues have
been around forever.  What is new is the claim that one has to
be able to copy large amounts of descriptive text out of RFCs,
and to modify that text at will and interleave it with other
text or code, with or without copying restrictive clauses, in
order to do effective implementations.  As far as "they will
write specifications from scratch", "they" will do so only if
they cease to care about interoperability between their
implementations and those of others.  If "they" do care about
interoperability, they will either use IETF specifications
--ideally after contributing to them-- or they will have to
invent a body to compete with the IETF, one that has a
reasonable level of participation from both the open source and
commercial implementation communities.

>> I am willing to give the IETF (presumably via the IESG and/or
>> IAOC) considerable latitude to interpret what is necessary
>> "in conjunction with the standards process" as long as they
>> have a set of principles about the decisions that are to be
>> made and that the are applied consistently.
> 
> parties the rights to modify its output is one thing that is
> important in the standards process.

To the standards process, no.  With one interesting group of
exceptions [1], no standards body of which I'm aware has ever
believed this.  The notion of a standard, especially a standards
that is to be used as the foundation for interoperability, is
that everyone starts and finishes with the same words, the same
protocol specification, and the same interpretation of those
words and that specification.   If third parties start modifying
things, each in their own way, then one may have a result that
is better than the standard in various ways, but won't have an
interoperable standard any more.

It might be important to grant those rights as one of the
"goodies" I referred to in an earlier note, but it isn't
important in the standards process.

>> discuss it... with the understanding that such a proposal
>> would have impacts far outside the scope of this WG.   If you
>> are not, I suggest that you had best concentrate at least as
>> much on what those who are willing to contribute time as
>> authors and editors and, where relevant, the organizations
>> who support them are willing to give the IETF, and for what
>> purposes, as on what you think the IETF should give away.
> 
> Understood.  However, there is a trade-off.  You can't protect
> all rights to a document that is intended to be consumed by
> everyone.

Nor has anyone suggested doing so.  Redistribution and copying
rights have always been available, to everyone.  If we have
botched that in the process of trying to improve our IPR text,
that needs to be fixed.  It is clear that code excerpts and
similar things have to be far less restricted than descriptive
or definitional prose for people to be able to implement the
standards and, again, if we have managed to botch that as we
have tried to get more specific, that needs to be fixed.  But
you can't have standards with some constraints on copying and
modification, at least without _extremely_ clear rules on
identifying the modified copies as different from the real
thing... rules that go well beyond the absence of boilerplate.
And you won't have standards if you make it a requirement that
people doing the development work either relinquish rights
considerably beyond those that are actually required to
implement the standard or if you require that they do free work
for you that are not necessary to getting the standard properly
defined.

> I don't believe I'm proposing to change anything radically.
> I'm trying to tweak the license text in RFC 2026 to be free
> software compatible.

Unless I have completely misunderstood you, your definition of
"free software compatible" goes well beyond the actual needs of
developers of free software.  It may not go beyond their wants
and desires, but that is another issue, having more to do with
free lunches than even free beer.

    john

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Dec 2005 10:25:25 +0100

> until someone discovers a glitch some months or years later.

Agreed.  That is why I believe the charter should include a mile stone
to produce a document that explain the requirements and intentions of
the license text.

This WG should not continue pushing out legal text that is not
reviewed.

I think we have all noticed how the minimal RFC 2026 legal text even
has typos, and that the RFC 3978 text forgot to grant third parties
the right to copy verbatim copies of RFCs.  Such gotchas should be
caught sooner, before they are used as legal instruments.

> to it so it can hold them as a public trust.

This example is not interesting until you include something like the
following:

  "Assume that software the organization produce is used to run a
   non-negligible portion of the Internet, and that the product is
   used by many large Internet organizations including several big
   companies."

Only then becomes this theoretical organization interesting enough for
the IETF to pay attention.  It is only then this organization can do
anything that influence the well-being of the Internet.

If you don't make this changes to the example, I think it is
irrelevant.  We should worry about what is practical and interesting
on a large scale.  In my responses below, I assume this change has
been made to your example.

> community needs to make decisions about what can or cannot

I agree with the last part.  I'm not sure about the former.  The IETF
should make decisions that lead to a better Internet.  Sometimes those
decisions are tough, and things beyond the control of the IETF may
affect the outcome of those decisions.  Accommodating a big powerful
player on the market may be one example.

> elsewhere, therefore we have to give in".

The decision should take into account the size of the organization,
and how the Internet will be affected if the player actually does vote
with its feet.

That's why my modification to your example above is important.  A
negligible player in the market is uninteresting for the IETF.  A
larger organization that affect how many people and companies behave
on the Internet will be more interesting for the IETF, because the
IETF is ultimately concerned with the well-being of the Internet.

> is discretionary and a matter of judgment.  

Sorry, I don't agree with this at all.

All provisions of what is granted to the community is subjective what
the IETF community believe they need.

The rights granted by the IETF cannot be fixated over time, the IETF
must adapt to the changing needs of its community.

The IETF need to have a never-ending discussion of what the community
need for the IETF to be able to deliver that.

The rights you claim we need, and in particular that we definitely do
not need anything else, seem like foregoing this entire discussion.

> the above comment about quality and free goodies.  

The IETF does not produce reference implementations.  The members of
the IETF does, in their other capacities.  The few implementations in
RFCs are usually non-normative examples, and few (if any?) of, e.g.,
the C code examples are usable verbatim.  They can serve as
inspiration for good developers to produce something that is
acceptable for actual customers.

> nonetheless there.  And some of this discussion seems to be

I'm surprised you feel that way.

The needs I am pushing are the needs of my own company, others in my
situation (look at who signed my petition), and Debian.  It has also
been suggested that the FreeBSD have similar concerns.  Weighting how
important we are to the Internet's well-being should be one factor in
deciding this.  That is in part what I hope to produce: a statement
whether the IETF (still) wants to accommodate free software developers
or not.  The free software movement was closely related to the IETF's
early principles of openness.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Dec 2005 10:50:20 +0100

I'm concentrating on the part of your e-mail that I think may actually
lead to something constructive.  I don't want this to turn into a
theoretical discussion that will never lead to a practical result.

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

> that needs to be fixed.

RFC 3978 doesn't permit verbatim copying or distribution.

> It is clear that code excerpts and similar things have to be far
> less restricted than descriptive or definitional prose for people to
> be able to implement the standards and, again, if we have managed to
> botch that as we have tried to get more specific, that needs to be
> fixed.

This has never been discussed before, as far as I know, and permitting
anything like it was not the intention of RFC 2026 or RFC 3978
according to Scott Bradner.

I'm glad you appear to agree that we need some changes of the RFC 2026
status quo.

> But you can't have standards with some constraints on copying and

Here is the interesting part.  Have you seen Chuck Powers proposal to
require that a warning label is added to modified documents, in
addition to removing all endorsements by the IETF?

That approach may be free software compatible.

What kind of text to make it absolutely certain that modified copies
can never be confused with the real thing for you?

I believe agreeing on this approach and some proposed text, as food
for thought for a requirements document if nothing more, would be very
valuable.

> considerably beyond those that are actually required to implement
> the standard or if you require that they do free work for you that
> are not necessary to getting the standard properly defined.

That is false.  There are certainly examples of standards developed
this way.

The Free Standards Group are producing the Linux Standard Base, which
is driven by the industry and has input from many people doing
development work.

The Unicode Consortium has changed their copying conditions to permit
modifications to some of their standards, to make it possible to use
them in free software.

> developers of free software.

That has not been my intention.

My primary concern is that my products -- a library that implement
internationalized domain names (which is used in libc on Linux), and
implementations of the SASL, Kerberos 5, GSS-API and TLS security
protocols -- which are used in Debian and several other Unix and
Windows environments does not seem to be legally distributable.

The same concern appear to exist with other free software
implementations of IETF protocols, including Apache, Samba, OpenSSL.

I have legal advice that claim the RFC 2026 and RFC 3978 license are
incompatible with the licenses I'm using, so there are legal basis for
my claims that we need changes.  Of course, the IETF can decide that
it doesn't want to change.  I haven't thought of the consequences of
that much, but it would seem problematic.

Thanks,
Simon