Subject: Re: Last Call: draft-ietf-lemonade-rfc2192bis (IMAP URL Scheme) to Proposed Standard

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 Jun 2007 18:41:32 +0200

Hi!

This document contains two sections that may be useful to extract and
include into implementations.  I'm talking about section 11 (ABNF
specification) and Appendix A (Sample code).  The rights granted by the
IETF license in RFC 3978/4748 in section 3.3, including the right to
extract code portions from documents into products etc, are only granted
to "IETF Trust and the IETF", and there is no other license to indicate
that any similar rights are granted to third parties.  Being able to do
that seems desirable in order to allow implementation and adoption of
the technology.

The ABNF syntax is the most important, since being compatible with the
technology requires that you follow the formal definition of the URL.
Implementations cannot integrate the ABNF as-is today.  The alternative
for them, to re-specify the module from the text (if that is at all
possible), is bad for interoperability.  If you want to enable smooth
implementation of your standard by everyone (which I hope!), here is how
to solve it:

There are several solutions to this problem.  A simple solution that has
been used successfully in several documents (RFC 3492, RFC 4398 and a
few others) is to add, after the above notice, the following notice:

   -- Regarding this entire document or any portion of it (including
   -- the pseudocode and C code), the author makes no guarantees and
   -- is not responsible for any damage resulting from its use.  The
   -- author grants irrevocable permission to anyone to use, modify,
   -- and distribute it in any way that does not diminish the rights
   -- of anyone else to use, modify, and distribute it, provided that
   -- redistributed derivative works do not contain misleading author
   -- or version information.  Derivative works need not be licensed
   -- under similar terms.

This notice would give third parties the necessary rights they need to
be able to use the normative ABNF syntax module and the C Sample code
from your document.

Btw, you'd might want to modify the text slightly, so that "pseudocode
and C code" becomes "ABNF syntax and C code".  If you don't want to
grant the rights to the entire document, grant them only for the ABNF
and C code.

Btw^2, this and other issues are discussed in:
http://www.ietf.org/internet-drafts/draft-josefsson-free-standards-howto-00.txt

Best regards, and thanks in advance,
Simon

The IESG <[email-masked]> writes:

> The IESG has received a request from the Enhancements to Internet email 
> to Support Diverse Service Environments WG (lemonade) to consider the 
> following document:
>
> - 'IMAP URL Scheme '
>    <draft-ietf-lemonade-rfc2192bis-07.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2007-06-28. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13735&rfc_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Jun 2007 10:41:06 -0700

>implementation of your standard by everyone (which I hope!), here is how

Simon,
	I follow your argument for the sample code in Appendix A,
but I don't follow it for the ABNF.  What do you mean by "integrate
the ABNF as-is today"?  As I understand it, a developer reading the
specification and using the ABNF to develop an implementation is
within the "outbound rights" understood by the IETF community
to pertain to standards track RFCs.   Indeed, it's kind of the whole
point.   Is there something special about this document that causes
you to believe that it needs special licensing for the specification?
	If you do believe the ABNF needs special licensing in
this case, I am sorry to say that your remedy is not sufficient.  This
document imports ABNF from other documents (from RFC 3986,
to take one important example).  Those documents do not have
anything like what you suggest.
			regards,
				Ted

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Jun 2007 09:30:00 +0200

Ted Hardie <[email-masked]> writes:

> the ABNF as-is today"?

I mean: To extract from the document the ABNF syntax specification and
include it in an implementation.  For example, a generic parser that
uses the ABNF specifications as input.  That is not possible today.

> As I understand it, a developer reading the

I believe our disagreement is that the "outbound rights" in the IETF
license permits extracting and use of the ABNF syntax specification in
implementations.  In my initial post I explained this as follows:

   The rights granted by the IETF license in RFC 3978/4748 in section
   3.3, including the right to extract code portions from documents into
   products etc, are only granted to "IETF Trust and the IETF", and
   there is no other license to indicate that any similar rights are
   granted to third parties.

> anything like what you suggest.

True, but I don't believe that is relevant to the document under
discussion.

It is possible to avoid extracting the ABNF from the referenced
documents by writing up your own ABNF specification based on
implementations made available under a liberal license.  Take for
example:

http://www.ninebynine.org/Software/HaskellUtils/Network/URI.hs

It also _possible_ to implement the RFC 3986 ABNF without extracting the
ABNF specification from that document (but it takes much more time and
is error prone), and then use that implementation in the parser that
includes the ABNF specification inside draft-ietf-lemonade-rfc2192bis.
The new parser will support the draft-ietf-lemonade-rfc2192bis ABNF and
won't violate any copyright, assuming that my suggested remedy is used.

The conclusion remains that if the ABNF in this particular document is
made available under a more liberal license, it will make
implementations of this particular document easier and more reliable.
That should be in the interest of the IETF.

Generally, justifying a new mistake by pointing at older mistakes seems
like a poor approach.

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Jun 2007 11:16:51 +0100

> > anything like what you suggest.
I disagree, I think they do have what Simon's suggesting. But then, I 
think RFC2192bis does, as well.

> True, but I don't believe that is relevant to the document under
I think it's basically relevant - I agree that it may be possible to 
have a generic ABNF parser which is "preloaded" with sufficient 
knowledge to avoid the need for the several ABNF references in this 
document, but the fact remains that there's a lot more ABNF 
referenced in than there is in the document itself - but that, of 
course, assumes that there's a problem here.

> That should be in the interest of the IETF.

I readily agree that we should have ABNF treated as code which may be 
incorporated directly or indirectly into implementations under a 
liberal license, and I think you're quite right to raise this issue.

I disagree that this document is the place to start what I suspect 
would be a fairly lengthy process.

RFC4234bis, on the other hand, could reasonably start to address this 
from the ground up, and I feel that's the place to direct your 
energies.

However...

I'd personally expect that ABNF was treated as "executable code or 
code fragments" under BCP78, Section 3.3(a)E, much like a MIB, and 
hence your concerns would seem misplaced. Of course, clarifying this 
would be welcome, but the text within BCP78 is not referenced 
explicitly nor copied into recent MIB RFCs, and nor is that text 
limited to MIBs - MIBs are merely one example given - so I would be 
surprised if this weren't intended to be the case for ABNF as well.

Relatively recent comments I've seen have suggested to me that at 
least some other RFC authors believe that the ABNF can be extracted 
and used in the process of implementing a parser, for example 
http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-March/000136.html 
(Mark Crispin, referring to ABNF from RFC3501, "[...] you should use 
one of the excellent syntax generators that read ABNF.")

So unless I'm completely misreading what BCP78 says - and in that 
case I'm not the only one - I think we're covered anyway.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Jun 2007 12:42:05 +0200

> would be a fairly lengthy process.

Right, and I have brought this up within the IPR WG.  As you suspect,
the effort to revise the license is a multi-year effort.

I don't think it is reasonable to ask implementers to wait for the IPR
WG process to finish before potentially being able to more easily
implement RFC 2192bis.  It should be in the IETF's interest to make it
easy to implement all standards in a reliable way.  In this case, there
is something the IETF community and the document authors can do to help
improve the situation.

> from the ground up, and I feel that's the place to direct your

I see those as separate efforts -- improving RFC 4234bis is a worthy
cause, but improving that document shouldn't prevent us from improving
RFC 2192bis too.

> So unless I'm completely misreading what BCP78 says - and in that case
> I'm not the only one - I think we're covered anyway.

I think you are missing what I tried to explain in my initial e-mail:
Read Section 3.3 of BCP78 from the start.  It starts by defining who
gets the rights discussed later on, including 3.3(a)E:

3.3.  Granting of Rights and Permissions
...
   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
                               ^^^^^^^^^^^^^^^^^
      property rights in the Contribution:

(This is slightly altered by RFC 4748.)

Several people consider this license insufficient to make it possible to
include extracted material from RFCs into some implementations.
Supporters for the effort to revise the IETF licenses include the people
at the bottom of:

http://josefsson.org/bcp78broken/

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Jun 2007 12:57:02 +0100

> include extracted material from RFCs into some implementations.

Given your reading, and given that the same thing must apply to MIBs 
(which are explicitly used as an example), then it seems to me that 
virtually every SNMP implementation would be in violation of the 
copyright license, since MIBs are very commonly extracted from RFCs, 
often with errata patched in, and used as input to implementations, 
either directly or indirectly (by being used in MIB compilers and 
suchlike to create compilable code).

Now, BCP78 doesn't cover third party rights - its title is pretty 
clear on that - but it still includes section 7.5, at least, and more 
importantly it requires that the rights you're seeking are allowed to 
be granted by the IETF Trust, and the IETF Trust itself certainly 
appears to be granting them, such as in the answer to Question 6 and 
7 at http://trustee.ietf.org/24.html

Modulo a clarifying statement to the contrary from the IETF Trust, 
I'd say I've been explicitly granted rights to snarf the ABNF from 
anywhere I choose and slap it straight into my implementation, 
including the ABNF from RFC2192bis, and supporting documents.

This isn't to say it's a waste of time to get all this a little 
clearer, but I don't see how bogging down every document containing 
ABNF in legal tangles is going to help.

Dave.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Jun 2007 14:22:45 +0200

Dave Cridland <[email-masked]> writes:

> appears to be granting them, such as in the answer to Question 6 and 7
> at http://trustee.ietf.org/24.html
>
> Modulo a clarifying statement to the contrary from the IETF Trust, I'd
> say I've been explicitly granted rights to snarf the ABNF from

I don't see a clear license that "explicitly" grants third parties those
rights.  I see some hand waving referring to past behaviour and a link
to a FAQ without authorship or contact information.

Given this situation, my position is that modulo a clarifying statements
from the IETF Trust granting third parties the rights to extract and
modify parts of RFCs, we have to assume we haven't been granted those
rights.  That is how copyright law works, if I understand it correctly.

If the IETF Trust could publish something legally binding that covers
this, that would likely solve all my concerns with this document.

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Jun 2007 14:41:26 +0100

> rights.  That is how copyright law works, if I understand it 
The mere fact it's not couched in legal linguistic mumbo jumbo is 
really not a big deal - anything that says "You can do X", where the 
entity making that statement is capable of granting the rights 
required to do X, is legally granting you those rights. If not, then 
I've utterly misunderstood some fundamentals of law.

In this case, the entity is the IETF Trust, since the statements are 
visible on their official website. It's possible that the site has 
been hacked and this has been inserted, but I don't have any evidence 
at all to support that, whereas, being linked to from the front page, 
one would assume it'd have been noticed by now if it were the case. 
Furthermore, given the levels of technical expertise available to the 
IETF Trust, I have to consider that unlikely anyway. So I'd say the 
authorship is pretty clear - in fact, it's clearer than most 
copyright licenses.

The IETF Trust certainly appears to have the legal ability to grant 
rights of this form - that's what BCP78, as updated, is doing. Put 
another way, I have no reason to think that they don't have the 
ability to grant such rights, anyway.

The statements themselves explicitly state that such rights are (and 
have been) granted.

Given these, I see no reason to question the legitimacy of the grant 
of rights, in the absence of any statement to the contrary.

> this, that would likely solve all my concerns with this document.

I'd say, with my imperfect knowledge of international copyright law, 
that they already have published something legally binding.

But nevertheless, if something could be drafted and published by the 
IETF Trust with a more formal form to it, I'd hope this could settle 
the issue.

Dave.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 18 Jun 2007 08:32:22 -0700

>>to a FAQ without authorship or contact information.

<snip>

>The IETF Trust certainly appears to have the legal ability to grant rights of this form - that's what BCP78, as updated, is doing. Put another way, I have no reason to think that they don't have the ability to grant such rights, anyway.
>
>The statements themselves explicitly state that such rights are (and have been) granted.
>
>Given these, I see no reason to question the legitimacy of the grant of rights, in the absence of any statement to the contrary.
>

I agree with Dave's interpretation here, and I believe his is both the common
view and the common-sense view. 

Simon, if you continue to disagree with this view, can I ask you resolve it by
addressing a message to the IETF Trust for clarification?  As Dave notes, trying
to resolve it by inserting new language into each document as it passes is not
exactly an optimal solution, especially where there are significant ABNF
productions which are derived from grandfathered documents.

				regards,
					Ted

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Jun 2007 08:40:10 -0700

At 8:32 AM -0700 6/18/07, Ted Hardie wrote:
>addressing a message to the IETF Trust for clarification?

... and let at least the ietf-general list know of the results of your request?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Jun 2007 17:48:52 -0400

Clarification below.

At 06:16 AM 6/18/2007, Dave Cridland wrote:
>I disagree, I think they do have what Simon's suggesting. But then, 
>I think RFC2192bis does, as well.

Given existing wording, it is somewhere between an extremely good 
idea and necessary to indicate that the ABNF and the code (and yes, I 
agree with Simon that it needs to apply to both) can be extracted and 
modified as necessary by anyone.  And while we are trying to solve 
this for the future, that unfortunately can not help current documents.

My only caveat is that the wording suggested by Simon does much more, 
and it is not necessary to go that far to meet the requirements.  An 
indication that says that those specific parts can be extracted, 
modified, and used for any and all derivative works would 
suffice.  (I am not a lawyer and I am not going to try to write license terms.)

Yours,
Joel

---

From: Ted Hardie <[email-masked]>
Date: Mon, 18 Jun 2007 15:54:37 -0700

At 5:48 PM -0400 6/18/07, Joel M. Halpern wrote:
>>I disagree, I think they do have what Simon's suggesting. But then, I think RFC2192bis does, as well.
>
>
>Given existing wording, it is somewhere between an extremely good idea and necessary to indicate that the ABNF and the code (and yes, I agree with Simon that it needs to apply to both) can be extracted and modified as necessary by anyone.  And while we are trying to solve this for the future, that unfortunately can not help current documents.

I think we're in real danger of going down a very deep rathole.  We can start
dancing on the "what is code" pin-head and hope to avoid it, but it's a pretty
faint hope.  To refresh your memory, here is what the IETF trust FAQs that
Dave has pointed to say:
 
>6. Am I allowed to reproduce extracts from RFCs?
>It is common to use extracts from RFCs that are in
>the form of computer code by incorporating them
>in software. This is the only usage formally allowed
>by the current IETF rules (RFC 3978).
>
>Generally speaking the IETF Trust will tolerate fair use
>of other extracts, but you must indicate the source of the
>extract and you must mention the original copyright statement
>if present.
>
>7. Am I allowed to publish modified extracts from RFCs?
>It is acceptable under the current IETF rules (RFC 3978)
>to modify extracted code if necessary.
>
>Modification of other extracts requires the permission of the original
>authors. The IETF Trust does not in general grant the right to
>create derivative works of RFCs; in fact it does not have
>the right to do so, under the current IETF rules (RFC 3978).
>
>The IETF is currently discussing various possible
>modifications of its rules to permit the publishing
>of modified extracts in certain circumstances.

(As noted, 3978 is where the IETF gets these rights from Contributors).

If ABNF is code, in other words, we are covered.

So, I believe we all also agree a human can read the RFC and code an
implementation after having done so without a copyright violation. 
If the ABNF is specification, in other words, we are covered provided
the process to turn it into code is in wetware. 

If the process is in other code,  the question becomes  whether the syntax
expressed in ABNF in the relevant document is code or input on which the
code works.  I certainly think that can be treated as code, as do others.
If Simon wants to write a one-line RFC that says
"ABNF [RFC4234] productions in IETF RFCs are code for the purposes of BCP 78[BCP 78]",
I will think it redundant but harmless.  But having this conversation on the IETF
list for every document that contains ABNF as it goes by is not really how this
should go, and having everyone have to make up new license terms to include
can run into its own problems, as Simon and I both know all too well.

				regards,
					Ted

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Jun 2007 21:28:05 -0400

Since the FAQ specifically says that code extracts can be modified, 
and since RFC 3978 specifically gives us the right to modify code for 
any purpose (explicitly not limited to the standards process) it 
seems that we are already covered on this, and no extra or special 
license is required.
(Sent to the list since I publicly said I thought we needed something extra.)

Yours,
Joel

---

From: Dave Cridland <[email-masked]>
Date: Tue, 19 Jun 2007 10:11:47 +0100

> If ABNF is code, in other words, we are covered.
This did briefly occur to me, but then I realised...

> the process to turn it into code is in wetware. 
Indeed - if it's not code, we're already covered anyway, and the 
entire point is moot.

> code works.  I certainly think that can be treated as code, as do 

No, I disagree - the question is not that. A MIB, in particular, is 
typically used as "input on which the code works", either at 
compile-time or runtime. A MIB is essentially a formal syntax 
definition itself, being written in ASN.1, which is to hideous binary 
blobs what ABNF is to beautiful text strings - not that I'm biased - 
so I struggle to see how one could be obviously legal and yet the 
other not.

RFC3978 doesn't just say "code", but in fact says [In Section 3.3, 
para (a), part (E)]:

          [...] any executable code
          or code fragments that are included in any IETF Document 
(such
          as MIB and PIB modules) [...]

So, MIBs are "code", and that implies that other formal syntax 
definitions written in a standard notation must surely also be 
"code", since there's nothing particularly magical about ASN.1.

The more interesting question is whether the authors of those RFCs 
with ABNF in them intended the ABNF to be treated as code, or at 
least don't object. If RFC authors *do* object, then we have a more 
serious problem. But, at least so far in this thread, nobody has - I 
wondered if that might be because it's hidden in a thread apparently 
concerned with IMAP URLs, hence the change of subject line.

Dave.

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jun 2007 10:19:14 +0100

On Mon, 18 Jun 2007, Ted Hardie wrote:
> faint hope.

The solution to that is to grant the same freedoms to all kinds of text in RFCs.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHANNON ROCKALL MALIN: NORTHEAST BECOMING CYCLONIC IN SHANNON LATER, 5 OR 6,
OCCASIONALLY 7. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2007 13:59:53 +0200

On 2007-06-19 11:11, Dave Cridland wrote:
...
> 
> The more interesting question is whether the authors of those RFCs with 
> ABNF in them intended the ABNF to be treated as code, or at least don't 
> object. If RFC authors *do* object, then we have a more serious problem. 
> But, at least so far in this thread, nobody has - I wondered if that 
> might be because it's hidden in a thread apparently concerned with IMAP 
> URLs, hence the change of subject line.

Thanks for that. "When you change the subject, please change the Subject."

I suggest people who are interested in this should read section 6.3
of draft-ietf-ipr-outbound-rights-03 and if they disagree,
say so on the IPR WG list.

     Brian