Subject: yet another comment on draft-housley-tls-authz-extns-07.txt

From: Bob Jolliffe <[email-masked]>
Date: Wed, 11 Feb 2009 14:21:33 +0000

Hello

I am writing to add my voice to those calling on the IESG not to
approve this draft.

I am a subscriber to this list and have tried to read and thoughtfully
digest what has been said already before adding my two cents.

It seems clear that, whereas the IPR Disclosure statement asserts that
the proposed standard can be implemented without infringing on the
RedPhone patent, from my reading it would be very difficult to work
around parts 2, 3 and 4 of the disclosure statement to actually use
the TLA Auth extentions for the purpose for which they are intended.
This is very different to the scenario that others have described in
this discussion ie. where a patent may be granted for a sufficiently
particular, novel and innovative use of an IETF standard which might
not even have been foreseen when the standard was published.

I don't believe the IESG should approve the draft without seriously
examining this issue.  That there is a record of previous "bad
behaviour", intentional or not, further reinforces the need for closer
scrutiny.  I think (I hope) their is a general consensus that IETF
standards should be freely implementable and usable for the manner in
which they are intended.

The comments from the TLS WG chairs are also a concern.  I support the
suggestion that this be re-submitted as a TLS WG work item.

Kind regards
Bob Jolliffe

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 11 Feb 2009 15:47:21 +0100

Hi,

On 2/11/09 3:21 PM, "Bob Jolliffe" <[email-masked]> wrote:

> [...]
> I think (I hope) their is a general consensus that IETF

The phrase "freely implementable and usable" may be the key
misconception/misunderstanding by the FSF people.  As several hundred IPR
disclosures with RAND terms against issued standards track RFCs show, the
consensus (at least in those cases) in the IETF has been, and still is, that
IETF RFCs do not necessarily have to be royalty-free or unencumbered.
Personally, I view those as "free" just as well; my definition of freedom is
somewhat different than the FSF's definition.

I fully understand that this is not aligned with FSF's position on standards
in general.  The way to address this misalignment is to work in the IETF
towards an FSF-compatible patent regime, and not rant about one specific
draft that somehow got on the FSF's campaign radar.  The best way, IMO, to
work towards such a regime, would be that FSF activists, instead of wasting
their time on mailbombing, invent great new concepts, protocols, and write
them down in the form of Internet drafts, and make them freely available in
the IETF and elsewhere.

Regards,
Stephan

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Feb 2009 16:43:18 +0100

> them down in the form of Internet drafts, and make them freely available in

That's not possible because the IETF policies does not permit free
software compatible licensing on Internet drafts published by the IETF.

/Simon

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 11 Feb 2009 17:27:01 +0100

Hi Simon,

On 2/11/09 4:43 PM, "Simon Josefsson" <[email-masked]> wrote:

>> The way to address this misalignment is to work in the IETF

I don't understand why inventing, designing protocols, and writing their
specification down in the form of Internet Drafts according to the IETF
policies would necessarily be incompatible with what some people call "free
software".  With a bit of flexibility and good will on both sides, I view
this as entirely possible.  The IETF can conduct process experiments if
those were required, including an experiment of temporarily suspending
certain features of its policies.  And, perhaps, the "free software" people
could be a little bit more relaxed in insisting on licensing terms of their
initial phases of contributions to the IETF.  I'm personally willing to
support such an effort, even I do not see an immediate benefit for myself.

Let me offer two alternatives:

1. People can attempt to make the IETF process more aligned with the
requirements of this "free software" movement---but please not through
mindless mail-bombing.  I think that both you and me understand that
entertaining an IETF policy initiative is much more an uphill battle if the
activist's actual technical contributions to the IETF are small or
non-existent, but still---the avenue is available.

2. Alternatively, and this is, of course, my preference, the same people can
attempt to make this so-called "free software" movement a little bit more
aligned with the requirements of the Real World.

Regards,
Stephan

---

From: Bob Jolliffe <[email-masked]>
Date: Wed, 11 Feb 2009 16:49:26 +0000

Hi

> somewhat different than the FSF's definition.

I agree that the consensus has been (and still is) that IETF standards
do not necessarily have to be royalty-free or unencumbered.  I also
think this is unfortunate.  And yet
ftp://ftp.rfc-editor.org/in-notes/bcp/bcp79.txt does express a clear
preference that "In general, IETF working groups prefer technologies
with no known IPR claims or, for technologies with claims against
them, an offer of royalty-free licensing."

I suspect that this preference is not solely for ideological reasons
or because of any misconceptions or misunderstandings.  But rather for
clear, practical and pragmatic reasons.

I think a concern here is that the IPR disclosure in this case is
crafted in such a way as to give the impression that you can "freely
implement" the standard ("No licence requirements") when in fact you
can't use it to perform authorisation based on legally binding
agreements.  This does seem to be simply misleading and I am not sure
why they have crafted such a statement.  Surely, to clear the low bar
of permissability, all they need to do is disclose the patent and not
offer any licencing information at all.  I'm sorry if I smell a rat.

> them down in the form of Internet drafts, and make them freely available in

I think this is a question of governance.  Firstly it's not just the
FSF who are concerned about patents in standards.  The South African
government, for example, have a strong commitment to using standards
which are available under royalty free terms.  As do many other state
and other actors.  And we all have an interest in using the internet
and IETF standards.  Not all of these stakeholders have the time or
expertise to engage more fully in IETF standards development.  But
they still have legitimate cause to be concerned about appropriation
of basic internet standards.  And to raise those concerns on the
mailing lists of the IETF.  It seems you (and some others) are
suggesting that in order to be heard at the IETF you need to clear
some sort of hurdle.  I fully agree that direct participation and
involvement is the best way to influence and drive agendas in
standards organisations.  But those who do participate must also
understand that they have some responsibility to a broader community.
Particularly when we are talking about internet standards.  I think
the IETF strives to be more than a place in which a sufficiently
driven and self-interested person or organisation can promote
standards which advance their economic or ideological position.  In
fact I know it does.

Regards
Bob

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 11 Feb 2009 09:44:13 -0500

On Wed, Feb 11, 2009 at 02:21:33PM +0000, Bob Jolliffe wrote:
> the TLS Auth extentions for the purpose for which they are intended.

I'd like to express my strong concurrence with Bob's statement.
(I was drafting something of my own along similar lines, but he
has phrased it more articulately than I, modulo one typo that
I took the liberty of fixing.)  I'm deeply concerned that anyone
attempting to implement these will -- despite their best intentions
and efforts -- find themselves ensnared by a subsequent assertion
of IPR claims.  While I realize that this is almost always a
possibility, unfortunately, I think that we need to be much more
cautious with technologies where the probability of such an outcome
is thought to be "high" -- and this appears to be one of them.

---Rsk

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 12:35:33 +0100

Stephan Wenger <[email-masked]> writes:

> software".

See RFC 5378:

   It is also important to note that additional copyright notices are
   not permitted in IETF Documents except in the case where such
   document is the product of a joint development effort between the
   IETF and another standards development organization or is a
   republication of the work of another standards development
   organization.  Such exceptions must be approved on an individual
   basis by the IAB.

The IETF copying conditions are not compatible with free software
licenses (modification is not allowed), and additional copyright notices
are not permitted.  The vast majority of free software licenses is built
on the concept of copyright notices and requires preserving the
copyright notice.

It is possible for authors to release the document outside of the IETF,
but the point above was that it is not possible to do within the IETF.

> With a bit of flexibility and good will on both sides, I view this as
> entirely possible.  The IETF can conduct process experiments if those
> were required, including an experiment of temporarily suspending
> certain features of its policies.  And, perhaps, the "free software"
> people could be a little bit more relaxed in insisting on licensing
> terms of their initial phases of contributions to the IETF.  I'm
> personally willing to support such an effort, even I do not see an
> immediate benefit for myself.

I would support an experiment like this as well.  It could for example
work by allowing contributors to license their contribution under the
BSD license.

/Simon

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Feb 2009 14:39:53 +0200

Simon,

>>> software compatible licensing on Internet drafts published by the IETF.
...
>    not permitted in IETF Documents except ...
...
> on the concept of copyright notices and requires preserving the

I agree that there are problematic case, but I believe I hope everyone 
realizes this is only the case if the RFC in question has code. 
Otherwise it really does not matter. Only some RFCs have code.

I support experiments in this space, though. And it would be really good 
to get more of the open source folk participate in IETF specification 
work. There are many important open source extensions and protocols that 
fit in IETF's scope but were never documented. Even if source code is 
freely available, you could have several implementations, commercial vs. 
open source interoperability issues, etc.

Jari

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Feb 2009 12:45:51 +0000

> Otherwise it really does not matter. Only some RFCs have code.

Except that it prevents using the text of an RFC as comments in an
implementation.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 12 Feb 2009 15:03:02 +0200

> open source interoperability issues, etc.

I was an open-source developper before, becoming a Nokia employee and 
sponsored IETF attendee (and I remain one). I was in a software field where 
IETF has high relevance (e.g. Teredo and RTSP). But there was no way in the 
world I could have afforded the travel, accomodation and attendance costs.

Oh, I was one relevant working group mailing lists. But from my experience, I 
was not at all taken seriously, until I started showing up at the meetings. In 
other words, remote participation does _not_ really work, in this venue, and 
on-site participation is often not possible.

Also, open-source is heavily dependent on running code (as are some 
standardization venues such as XSF). IETF is not, or not anymore, although I 
guess this varies from WG to WG. And IETF is very slow compared to the open-
source community.

All in all, I am not surprising that the IETF process is not so popular with 
open-source projects, and I am doubtful we can "fix" that without more 
disruptive changes that current IETFers and their sponsors, would be willing 
to accept.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Feb 2009 15:33:52 +0200

Tony,

> Except that it prevents using the text of an RFC as comments in an
OK -- I can see how that would be useful, but its not clear to me that 
it would necessarily be a blocking requirement. Reality check: I'm 
writing this e-mail to you and at least my side application, OS, and the 
first couple of hops are completely pure open source yet every protocol 
I use before until L2 is from an IETF RFC. Maybe the same on your side. 
And somehow that code got written, presumably without lots of copying of 
RFC text... And I can think of some RFCs where I'd rather not use that 
text... (Comments? Who needs comments?)

But in any case, I wouldn't mind if we experimented with a more relaxed 
license for some set of RFCs...

Jari

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Feb 2009 08:54:27 -0500

Excerpts from Rémi Denis-Courmont on Thu, Feb 12, 2009 03:03:02PM
+0200:
> Oh, I was one relevant working group mailing lists. But from my
> experience, I was not at all taken seriously, until I started
> showing up at the meetings. In other words, remote participation
> does _not_ really work, in this venue, and on-site participation is
> often not possible.

Given recent corporate budget changes I expect that getting things
done outside of face-to-face meetings is going to become more
important for others, so we can hope that this situation will improve.

---

From: Aaron Williamson <[email-masked]>
Date: Thu, 12 Feb 2009 10:02:23 -0500

Jari Arkko wrote:
> it would necessarily be a blocking requirement.

Jari is right about this.  For a bit of perspective, FSF distributes the text of
the GPL under these terms:

	Everyone is permitted to copy and distribute verbatim copies of this
	license document, but changing it is not allowed.

It is common to prohibit derivative works of standards and licenses, to keep
standards standard and to prevent, e.g., more- or less-restrictive versions of
licenses from being attributed to the original author.  These documents are
treated very differently from source code.

Aaron

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 12 Feb 2009 11:00:42 -0500

Hi Tony,

> Except that it prevents using the text of an RFC as comments in an

Ummm, no it doesn't...

There are two reasons why I don't believe that this statement could be  
true of RFC text with the either the old or new copyright template:

(1) No copyright actively _prevents_ anyone from doing anything.  You  
may or may not have a license to do something with copyrighted text,  
and if you copy the text without a license, there may be  
consequences.  However, I don't think that anyone actually believes  
that the IETF will track down people who copy RFC text into comments  
and sue them or attempt to get injunctions against them.

(2) Even if the IETF did try to sue you for copying sections of RFC  
text into your source code comments, they'd almost certainly lose, as  
that would probably fall under fair use provisions.

Realistically, the only way you will run into any sort of trouble is  
if you re-publish RFCs, or reuse large sections of RFC text in another  
publication and don't follow the licensing requirements.

Margaret

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Feb 2009 17:01:21 +0100

> Except that it prevents using the text of an RFC as comments in an
actually that's intended to be permitted by RFC 5377 section 4.2:

4.2.  Rights Granted for Quoting from IETF Contributions

   There is rough consensus that it is useful to permit quoting without
   modification of excerpts from IETF Contributions.  Such excerpts may
   be of any length and in any context.  Translation of quotations is
   also to be permitted.  All such quotations should be attributed
   properly to the IETF and the IETF Contribution from which they are
   taken.

You're not permitted to modify the text. You are permitted to use it.

                  Harald

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Feb 2009 16:06:29 +0000

> actually that's intended to be permitted by RFC 5377 section 4.2:

Oh, that's nice :-)

Tony.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Feb 2009 19:25:14 +0200

Harald, Margaret, and Simon,

Harald wrote

and Margaret wrote:

> However, I don't think that anyone actually believes that the IETF 
> will track down people who copy RFC text into comments and sue them or 
> attempt to get injunctions against them.
>
> text into your source code comments, they'd almost certainly lose

So it seems that we actually do have at least some ability to deal with 
comment-style use of RFCs fragments in free software. Simon, do you see 
any residual issues that we need to solve, or were your concerns in 
areas other than comments?

Jari

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 12 Feb 2009 14:17:02 -0500

Dear Jari et al.;

On Feb 12, 2009, at 12:25 PM, Jari Arkko wrote:

>> will track down people who copy RFC text into comments and sue them  
>> or attempt to get injunctions against them.
>>
> So it seems that we actually do have at least some ability to deal  
> with comment-style use of RFCs fragments in free software. Simon, do  
> you see any residual issues that we need to solve, or were your  
> concerns in areas other than comments?
>

I am not a lawyer, but I don't believe that the IETF has no legal  
existence and thus cannot sue. Any "IETF" suits would have to come  
from the Trust. If there are issues, the Trust can solve them by  
warranting that they will not sue under given conditions, as is being  
done with the Trust Legal Provisions.

Marshall

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 21:32:39 +0100

Jari Arkko <[email-masked]> writes:

> realizes this is only the case if the RFC in question has
> code. Otherwise it really does not matter. Only some RFCs have code.

I don't realize that, and completely disagree.  If you want free
software authors to publish free standards (as in free software
compatible) in the IETF, the IETF needs to allow free software
compatible licensing of their work.  Right now, the IETF disallow
standards published through the IETF to be licensed under a free
software compatible license.  The only alternative for these authors is
to release their work outside of the IETF.  This may result in some free
software authors doesn't bother publishing their work in the IETF
because the licensing models are incompatible.

> I support experiments in this space, though. And it would be really
> good to get more of the open source folk participate in IETF
> specification work. There are many important open source extensions
> and protocols that fit in IETF's scope but were never documented. Even
> if source code is freely available, you could have several
> implementations, commercial vs. open source interoperability issues,
> etc.

I agree.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 21:35:48 +0100

> You're not permitted to modify the text. You are permitted to use it.

Exactly, and disallowing modifications prevents using the text of an RFC
as a comment in implementations licensed under free software licenses.

For short excerpts, one can use the text anyway and claim "fair use",
but larger excerpts can be useful to quote in comments or documentation
and then there is a problem.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 21:38:44 +0100

> concerns in areas other than comments?

The discussion started by Stephan suggesting that free software authors
publish their work as free standards in the IETF.  My point was that
since the IETF disallow publishing standards under a license that is
compatible with free software licensing (e.g., allows modification), it
is not possible for free software authors to do this.  Thus, to me, this
discussion is not related to comments in source code at all.

/Simon

---

From: TSG <[email-masked]>
Date: Thu, 12 Feb 2009 12:39:47 -0800

Simon Josefsson wrote:
> I don't realize that, and completely disagree.  

Good point  Simon - lets amplify on that thought a tad...

    Whats the difference between the two of these statements?

    1 + 1 = 2

and

    One plus one equals two

One is a formula (i.e. code) and the other not?  This is the same point 
I brought out about controls in I-D's and RFC's per se, the code can be 
in any numbers of forms including actual code (as encoded), pseudo code, 
or just the written description of that process. All of these form code 
in one derivative form or another and as such all of them need to be 
covered.
> If you want free

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Feb 2009 15:49:38 -0500

I disagree Simon.

Free Software authors (for any variety of free software I know of) are 
free to submit I-Ds describing protocols that they define.

They can not take their licensed code, with license restrictions, and 
put it in the RFC.
The primary reason for this restriction, in my view, is that some of the 
licenses out there would actually interfere with commercial 
implementations of the RFC if such double-licensing were allowed and 
done.  And just as we want to allow free implementations of the RFCs, we 
also want to allow commercial implementations of RFCs, for a wide range 
of commercial goals (just as there are a wide range of free rules and 
goals.)
Preventing folks from putting code with non-IETF licenses into RFCs 
allows everyone to write RFCs, and allows a wide range of code to be 
included in RFCs.  Making sure that code which is included in RFCs can 
be used by any implementator, as they need to, is important and useful. 
  Extra licenses distinctly interfere with that.
(We do permit references to licensed code in our documents, including 
specific URLs.)

And having a restriction that folks can not take and modify large blocks 
of text from the RFC does not prevent them from either writing RFCs or 
implementing protocols defined in RFCs.

Yours,
Joel

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 22:00:59 +0100

> free to submit I-Ds describing protocols that they define.

Sure.  And some do...

> They can not take their licensed code, with license restrictions, and

Right.

> The primary reason for this restriction, in my view, is that some of
> the licenses out there would actually interfere with commercial
> done.  And just as we want to allow free implementations of the RFCs,
> we also want to allow commercial implementations of RFCs, for a wide
> range of commercial goals (just as there are a wide range of free
> rules and goals.)

Right.

(However, that doesn't explain why the IETF disallows BSD licensed code
in IETF documents.)

> be used by any implementator, as they need to, is important and
> useful. Extra licenses distinctly interfere with that.

Agreed.

> And having a restriction that folks can not take and modify large
> blocks of text from the RFC does not prevent them from either writing
> RFCs or implementing protocols defined in RFCs.

Right.

Please re-read what I said earlier, because I don't see any disagreement
with what I've claimed before.  My claim has been that authors cannot
publish "free", as in licensed under a free software compatible
licensed, documents through the IETF.  You explained again that this is
the case, and you gave the reasons for this.  So we seem to agree.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 22:03:39 +0100

Wes Hardaker <[email-masked]> writes:

> So, I couldn't find a statement that says automatic sublicenses will be
> given out for code related items.  It only says that the policies for
> creating those sublicenses ***will*** be guided by 5377 (which says
> about the right thing: you can modify code extracts).  IE, is it
> actually possible to use code from RFCs beyond 5378?  I think each
> company/organization/author would need to personally ask the IETF trust
> for a sublicense?

The IETF Trust sub-license third parties rights to code components in
(new) IETF documents under the BSD license, see section 4 of:

http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf

/Simon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 12 Feb 2009 13:05:36 -0800

Some points:

1) Open Source software and 'free software' as defined by the FSF are not the same thing.

Historically, open source licenses such as BSD and Apache or in the case of CERN libwww, a grant to the public domain have proved considerably more effective than GNU copyleft.

The World wide web code was made public domain rather than being GNU, expressly because we considered the GNU license to be counter-productive to our aims. 

2) Those of us who understand RMS's political agenda are more likely to oppose it than to support it.

RMS has on numerous occasions stated that his intention in drafting the GNU copyleft was to poison the well of proprietary works. He has made this statement to me personally and unambiguously. That is a political position that many are opposed to. If RMS chooses to place restrictions on FSF intellectual property to enforce compliance with his political views he has no standing when he opposes restrictions placed by others.

It is an entirely reasonable point of view for an IPR holder to craft a license grant in such a way that it is only compatible with a subset of open source licenses. In terms of Internet adoption Apache compatibility is sufficient. 

3) Write only campaigns decrease sympathy for the position being promoted.

I suspect I am not alone in reading only a portion of the FSF correspondence. Statistical sampling indicates a high probability that this is representative.

If RMS has an issue with an IETF protocol he should make the case himself, not set his rent-a-mob onto the IETF mailing list. Not a single one of the messages I have read has given a concise explanation of what the problem RMS has with the TLS-authz spec.

---

From: TSG <[email-masked]>
Date: Thu, 12 Feb 2009 13:09:36 -0800

> discussion is not related to comments in source code at all.
So then just create another IETF Standard for Open Source Licensing.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 12 Feb 2009 23:37:28 +0100

This whole line of reasoning does reminds me of stories about camels
jumping through eyse in needles, numbers of angels dancing of
pinheads and similar metaphores.

There is free/open source software distributed for 20 years or more
and all relevated RFCs are included in the resolution as well. I'm not
aware that the IETF ever protested against this practice.

	jaap

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 12 Feb 2009 12:47:36 -0800

>>>>> On Thu, 12 Feb 2009 14:39:53 +0200, Jari Arkko <[email-masked]> said:

JA> I agree that there are problematic case, but I believe I hope everyone
JA> realizes this is only the case if the RFC in question has
JA> code. Otherwise it really does not matter. Only some RFCs have code.

Actually, many RFCs have code.  XML, XML schemas, MIBs, etc are all
pseudo-code files that need to be redistributed and often contain syntax
errors (and thus need to be modified before they're usable; some
relevant copyrights (like IANA's MIB copyright [1]) don't let you modify
the potentially broken files and redistribute them.  Fortunately,
getting IANA to fix problems and publish a fixed copy of the MIB
probably isn't a problem.

Now, lets get back to whether code can be extracted.  Interestingly RFC5378
(which affects only all documents after it) says that:

              The IETF Trust may establish different policies for
   granting sublicenses with respect to different types of Contributions
   and content within Contributions (such as executable code versus
   descriptive text or references to third-party materials).  The IETF
   Trust's policies concerning the granting of sublicenses to make
   derivative works will be guided by RFC [RFC5377].

Footnotes: 
[1]  http://www.ietf.org/copyrights/ianamib.html

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 12 Feb 2009 13:19:44 -0800

>>>>> On Thu, 12 Feb 2009 22:03:39 +0100, Simon Josefsson <[email-masked]> said:

SJ> The IETF Trust sub-license third parties rights to code components in
SJ> (new) IETF documents under the BSD license, see section 4 of:

SJ> http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf

Thanks!

Does anyone else feel that the IETF likes to document things in ways
that reflect a maze of twisty passages?  We're very good at making many
rooms (all 5686 of them) but not so good at marking the passageways
between them.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Feb 2009 00:19:03 +0100

> and then there is a problem.
I consider the inability to include immutable text in software released 
under the GPL a bug in the GPL.

BTW, this means that at least one program I have released under the GPL 
is illegal; it includes the GPL as a part of the source code, and since 
the GPL text is immutable according to the GPL, it is illegal (by this 
logic) to include it in source code, since the source has to be free of 
restrictions upon its modification.

Not My Problem to solve.

                     Harald

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 12 Feb 2009 22:47:24 -0500

On Thu, 12 Feb 2009 21:38:44 +0100
Simon Josefsson <[email-masked]> wrote:

> The discussion started by Stephan suggesting that free software
> authors publish their work as free standards in the IETF.  My point
> was that since the IETF disallow publishing standards under a license
> that is compatible with free software licensing (e.g., allows
> modification), it is not possible for free software authors to do
> this.  Thus, to me, this discussion is not related to comments in
> source code at all.

My understanding of IETF policy is that the IETF will publish I-Ds that
are in the public domain.  Nothing is freer than that.  You're
perfectly free to put your text in the public domain before submitting
it for publication as an RFC.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Jukka Ruohonen <[email-masked]>
Date: Fri, 13 Feb 2009 09:34:18 +0200

> 3) Write only campaigns decrease sympathy for the position being promoted.

As someone who mainly acts in read-only mode on this list: regardless of
what one thinks about free software, I think what troubles me most in the
recent campaign is that it has already been partially successful. This
essentially political campaign has already disturbed the list. It has
already provoked a vivid discussion.

As has been pointed out, if campaigns like this are considered as qualified
input to IETF, also input from other political pressure groups or
professional lobby groups must be considered equally legitimate. This may
show bad taste, but does ISO's OOXML ring a bell?

- Jukka Ruohonen.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Feb 2009 11:34:10 +0100

Harald Alvestrand <[email-masked]> writes:

> I consider the inability to include immutable text in software
> released under the GPL a bug in the GPL.

Nobody forces you to use the GPL, so if you perceive a problem I suggest
to use another license for your program.  However, the IETF should not
prevent implementers from using the GPL, for the same reasons IETF
should not prevent Microsoft from using its EULA as the license.

> BTW, this means that at least one program I have released under the
> GPL is illegal; it includes the GPL as a part of the source code, and
> since the GPL text is immutable according to the GPL, it is illegal
> (by this logic) to include it in source code, since the source has to
> be free of restrictions upon its modification.

I don't see how that makes the program illegal.  It just makes it harder
for others to redistribute it safely because the licensing information
is unclear.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Feb 2009 11:41:08 +0100

Simon,

the example is at http://counter.li.org/scripts/machine-update. Take a look.

There is a single file that contains both the program source and the GPL.
I want to release this under the GPL.

Now, I have three possible interpretations:

1 - The words of the GPL that say "Everyone is permitted to copy and 
distribute verbatim copies of this license document, but changing it is 
not allowed." don't really apply in this case.
2 - The words of the GPL that say "You may modify your copy or copies of 
the Program or any portion of it, thus forming a work based on the 
Program, and copy and distribute such modifications or work under the 
terms of Section 1 above" don't apply to modifications of the portion of 
the Program that is the GPL
3 - I'm breaking the GPL

Now, with your extensive knowledge of what the GPL means for included 
text .... which is it?

                           Harald

---

From: Willie Gillespie <[email-masked]>
Date: Fri, 13 Feb 2009 03:47:32 -0700

Simon Josefsson wrote:
> to use another license for your program.

Unless your starting code is using the GPL, then you are forced to use 
the GPL and are not *free* to use any other license without permission 
from the copyright holder(s).  Ironic.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Feb 2009 11:48:08 +0100

> it for publication as an RFC.

Sure, but I can also put the text under the Microsoft EULA before
submitting it for publication as an RFC.  The IETF still requires some
assurances from me as contributor, and those assurances go beyond both
what the public domain and the Microsoft EULA implies.

A more interesting question is if you can submit somebody else's public
domain work to the IETF.  I don't know the answer to that.  It seems
clear that I can't take a work licensed under the Microsoft EULA and
submit it to the IETF though.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Feb 2009 12:17:58 +0100

This is getting off-topic, and seems like typical FAQ material, but I'll
reply briefly.  I suggest using, e.g., [email-masked] to get
other people's interpretations.  If you want a more authoritative
answer, talk to [email-masked].

> I want to release this under the GPL.

You can't release the text of the GPL under the GPL license, since you
are not the copyright holder of the text in the GPL license.  Further,
the license of the GPL text does not permit re-licensing, or even
modifications.

> distribute verbatim copies of this license document, but changing it
> is not allowed." don't really apply in this case.

That interpretation seems clearly bogus to me.

> 2 - The words of the GPL that say "You may modify your copy or copies
> of the Program or any portion of it, thus forming a work based on the
> terms of Section 1 above" don't apply to modifications of the portion
> of the Program that is the GPL

This seems more or less correct, even though it may sound surprising at
first.  More generally, and more clearly expressed, it can be stated as
this: The license for a piece of work applies to the piece of work, it
does not apply to the license itself.  The license of a work is not
normally not considered part of the work; it is metadata about the work.

> 3 - I'm breaking the GPL

That may hold as well, but without further elaboration I can't tell for
sure.

I compared the part of your work that consists of the GPL text with the
canonical version [1].  It seems that someone has modified the license
text: the section 'How to Apply These Terms to Your New Programs' is
missing.  If you had read that section, you would know of a better way
to explain the licensing conditions to users that would have avoided the
problem.  I believe this violate the license on the GPL itself, so you
may want to fix it.  However, I don't think the FSF will care
significantly about that problem.

For more information, see:

http://www.gnu.org/licenses/gpl-howto.html

> Now, with your extensive knowledge of what the GPL means for included

Your question comes up and is answered in Debian mailing lists from time
to time: some people claim that Debian cannot distribute the GPL license
text because it is not licensed under a free software license.

/Simon

[1] http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Feb 2009 12:25:03 +0100

> normally not considered part of the work; it is metadata about the work.
But (and the reason why this is important, and IETF-relevant) how is 
this case different from the case where you introduce pieces of an RFC 
(which also don't need to be considered part of the work) as comments 
into a work?

With the GPL text, you don't have the copyright, and you don't have a 
license that permits modified versions. But you do have the right to 
copy it.

With the excerpt from an RFC, you don't have the copyright, and you 
don't have a license that permits modified versions. But you do have the 
right to copy it - you even have the right to copy pieces of it.

Why are you insisting that the first is perfectly reasonable, and the 
second is a show-stopper?

               Harald

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Feb 2009 12:57:02 +0100

> (which also don't need to be considered part of the work) as comments

The only way I can see to avoid having the comment be part of the work
is to use different licenses for the code and the comment.  (Do you see
any other way?)

That is possible, but leads to problems.

The result is a complex license on the combined work.  The combined
license says essentially something like "License A applies to portion X
and the IETF Trust License applies to portion Y".  That combined license
may not be compatible with other licenses, both free and non-free
licenses.

For example, the combined license would not be compatible with the GPL
because modifications of the entire work is not permitted.

I believe it is possible to find proprietary licenses that have other
clauses that render the license incompatible with the IETF Trust
license.  So the problem is wider than just free software licenses.  I
believe the IETF needs to realize that GPL software runs part of the
Internet and that catering to these licensing needs is as important as
catering to the licensing needs of, say, Microsoft.

The license compatibility question is more relevant for free software
because people are more conservative in evaluating software licenses in
the free software community compared to the enterprise setting where
licenses are typically only ever evaluated when someone sues or is sued
by someone.

My point has been that triggering this situation works counter to the
goal of the IETF.  In a strict setting, it means implementers cannot use
verbatim text from RFCs, but needs to rewrite the text to avoid re-use
of material under the IETF Trust license.  I believe that opens up for
interoperability problems (when a re-written comment is subtly different
from the original meaning, and the comment influences code).  If people
decide that this rewriting needs to happen to avoid contamination from
the IETF Trust license, it would also delay getting IETF protocols
deployed.

This has been my rationale for suggesting that IETF documents should be
licensed under a free software compatible license.  I am aware that
battle is already lost, so I have mixed feelings about discussing this
further.  However if others bring up related topics I feel a need to
respond.  My hope is that it is possible to alter the policies in the
future.  Fortunately, I believe the new BCP 78 has created good ground
to make that possible.

Generally, however, I think this question is very different from where
this thread started.  It started, as far as I consider, with Stephan
suggesting that free software authors publish "free" (as in licensed
under a free software license) standards in the IETF.  That is not
possible, and is unrelated to the question we discuss here.  I'm happy
to discuss both questions, but I'm concerned that you and others may
believe that you dispute my first claim by discussing this separate
issue.

> don't have a license that permits modified versions. But you do have
> the right to copy it - you even have the right to copy pieces of it.
>

I'm not saying the second is a show stopper.  The Internet appears to
work relatively well on most days.  However, I insist that it is a
potential impediment and that it works counter to the goals of the IETF.

But to answer your question (heh!): I believe the situations are
different because the first is about meta-data of a work, and the second
results in a complex combined license.

/Simon

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 13 Feb 2009 07:59:05 -0500

> Now, with your extensive knowledge of what the GPL means for included 

4 - The contradiction in licensing terms turns the work licensed by its 
own terms, that are not exactly those of the GPL. Furthermore, the 
original copyright holder breached the GPL *text* copyright. He did not 
breached the GPL itself since he is the original author of the work. The 
intent of the original copyright holder is clear however, despite a 
minor glith in document distribution. Simon and I and anyone else who 
whish to create derivative works under the GPL can fix it, and not carry 
forward the contradiction in licensing terms (the Harald intent above is 
not clear, the referenced work is not his work, and it is already released).

Anyway, Harald highlighted a corner case in GPL licensing that creates 
some inconvenience (can't put GPL text in GPL'ed work, it must remain 
meta-data). IETF as a *document* editor is expected to use licensing 
terms that reasonably fits its purpose. The audience lobbyed by Simon 
should just live by inconvenience created by IETF licensing terms (no 
RFC text in GPL'ed software beyond fair use - it must remain as separate 
documentation). Routine open software distribution abide by these rules.

Please preserve the integrity of IETF rules addressing the needs of a 
broader and a more diversified audience than the one lobbied by Simon.

Regards,

-- 

- Thierry Moreau

---

From: <[email-masked]>
Date: Fri, 13 Feb 2009 14:06:09 +0100

Simon Josefsson wrote:

> possible, and is unrelated to the question we discuss here.

BTW, why cannot a free software author license some particular
standards text under both RFC 5378 terms, and some other license
(a free software license, or even GPL)?

Presumably, he/she owns the copyright, and 5378 terms are
non-exclusive.  Obviously, for collaborative efforts this may require
that all copyright holders agree, and that may make this unpractical.
But I wonder if there was some other reason?

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Feb 2009 14:11:44 +0100

> But I wonder if there was some other reason?

No, that approach works fine as far as I can see.  It has been used for
some documents, and parts of some documents, already.

That doesn't make the standard published by the IETF "free" as in free
software licensed though.  I admit this is a subtle distinction, and
given the discussion, I must have explained this poorly.

/Simon

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 13 Feb 2009 08:22:02 -0500

On Fri, 13 Feb 2009 11:48:08 +0100
Simon Josefsson <[email-masked]> wrote:

> >> was that since the IETF disallow publishing standards under a
> >> license that is compatible with free software licensing (e.g.,
> >> allows modification), it is not possible for free software authors
> >> to do this.  Thus, to me, this discussion is not related to
> >> comments in source code at all.
> >
> > My understanding of IETF policy is that the IETF will publish I-Ds
> > that are in the public domain.  Nothing is freer than that.  You're
> > perfectly free to put your text in the public domain before
> > submitting it for publication as an RFC.
> 
> A more interesting question is if you can submit somebody else's
> public domain work to the IETF.  I don't know the answer to that.

Legally, yes; it's public domain.  Academic honesty and common courtesy
would demand an acknowledgment.

> It
> seems clear that I can't take a work licensed under the Microsoft
> EULA and submit it to the IETF though.
> 
Right, which is why I suggested public domain and not the Microsoft
EULA....

More generally: if the goal is to have some text that can be freely
used in any software -- proprietary, open source, GPL -- there's
nothing more amenable to that than public domain.  That may not meet
all of the FSF's goals, but I don't really see that that's the IETF's
problem.

---

From: [email-masked] (Scott O. Bradner)
Date: Fri, 13 Feb 2009 08:27:44 -0500 (EST)

> would demand an acknowledgment.

more than that - the standards process requires an acknowledgment of all 
significant contributers so an acknowledgment is required

Scott

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 13 Feb 2009 9:16:00 -0500

>potential impediment and that it works counter to the goals of the IETF.

This kind of complexity will end up having all kinds of unfortunate 
consequences.  To give but one example ....

I do some development work for Debian and Ubuntu (a major derivative of 
Ubuntu).  Debian has a long standing policy on licensing requirements for 
inclusion of software in Debian (I'm not asking you to accept any value 
judgements about the goodness or badness of these requiements, they are 
what they are).

One requirement is that the work be freely modifiable.  As a result, RFCs 
and IETF drafts are not acceptable.  Any substantial quote that carried the 
same licensing requirements would have to be removed.

Another requirement is that software sources be shipped in their preferred 
form for modification.  Obfuscated code is not allowed.

Removing comments is a form of obfuscation.

As a result, the type of combined work envisioned here would likely be 
unacceptable.

If one wants to consider experiments, I do see a way out.  

The biggest concern I undertand the IETF having is that someone might 
modify RFC xyz and claim the modification is RFC xyz.  Debian (and Ubuntu) 
permit licenses that require the work to be renamed if they are modified.  
Thus Ubuntu ships Firefox (and coordinates its changes with Mozilla) and 
Debian ships Ice Weasel (and is not required to get Mozilla's permission to 
modify).

It might be useful to conduct an experiment with licensing some subset of 
RFCs with a modified license that allowed modification of RFC text as long 
as the modified work is renamed.  

I think this is a potential approach that supports the requirements of the 
IETF, proprietary software developers, and Free software developers.

Scott K

P. S. I'm not familiar with licensing policies of other 
distributions/operating systems, so this is admitedly focused on the 
requirements of the parts of the Free software ecosystem with which I am 
most familiar.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Feb 2009 06:36:07 -0800

>catering to the licensing needs of, say, Microsoft.

I have not seen the IETF spend much time trying to cater to the licensing needs of, say, Microsoft.

>licenses are typically only ever evaluated when someone sues or is sued

So, in essence, you are saying "because there is a community of developers who have a particular way of evaluating licenses, the IETF should spend a lot of time trying to cater to them".

>goal of the IETF. 

Please specifically state "the goal". I believe that you will find that it is, in fact, not a goal that is widely-held in the IETF.

>In a strict setting, it means implementers cannot use
>verbatim text from RFCs,

s/implementers/a subset of implementers who have a particular way of evaluating licenses/

> but needs to rewrite the text to avoid re-use

...by those developers.

>licensed under a free software compatible license. 

They are already licensed that way, for one common understanding of "free software compatible license". You have a different understanding for your purposes. You are (repeatedly) asking us to change our license for your understanding.

>I am aware that
>further. 

...so you launched dozens of people with much less understanding than you into sending one-way comments on the topic. In the future, please check your mix of feelings more carefully.

>possible

...by your interpretation, but clearly is possible by other people's interpretation...

>, and is unrelated to the question we discuss here.  I'm happy

Your recent actions make it sound like you feel that it is a better use of IETF time to do work to make a subset of developers who have one particular view of licensing happy than to develop the technology we are good at. I propose that the opposite is true.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 13 Feb 2009 16:05:42 +0100

Paul Hoffman <[email-masked]> writes:

>>I am aware that battle is already lost, so I have mixed feelings about
>>discussing this further.
>
> ...so you launched dozens of people with much less understanding than
> you into sending one-way comments on the topic. In the future, please
> check your mix of feelings more carefully.

Paul, I won't respond to the rest of your e-mail since I believe my
position is already clear, however blaming me for the FSF campaign is
unfair.  I am not responsible for that.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Feb 2009 09:12:16 +1300

> it for publication as an RFC.

Or afterwards, since the license a contributor grants to the
IETF Trust is non-exclusive. So contributing these words to the IETF
does not affect in any way my ability to do as I wish with them
after hitting the Send button.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Feb 2009 08:11:07 +1300

On 2009-02-15 03:44, Theodore Tso wrote:
> On Sat, Feb 14, 2009 at 09:12:16AM +1300, Brian E Carpenter wrote:
> This is true, although it may be non-obvious to the reader of an RFC
> that this is the case.  Is it really the case that current IETF
> polices and procedures do not allow the addition of a copyright
> statement saying that the code in question is also licensed under some
> other (preferably BSD-style) license?  If so, perhaps the reason for
> that restriction should be reconsidered?

I'll leave the legal answer to a legal person, but in my mind the current
rule doesn't forbid a factual statement in the document that a license
such as you suggest below has been issued for (part of) the text.

> 
> Or perhaps another way of solving this problem would be to allow the
> author of the code in question to file an IPR disclosure stating that
> "I, John Q. Smith, am the author of the code found in RFC XXX, and I
> hereby also make it available under the terms of the following
> (BSD-style) license...".  It extends the scope of IPR disclosures
> somewhat, but it would be a useful annotation.

I think this is fairly clearly excluded from the definition of
disclosures in RFC3979, but I can't see any reason why the IETF
(or the Trust) couldn't provide a repository for such licenses.

    Brian