Subject: IETF Last Call for two IPR WG Dcouments

From: Russ Housley <[email-masked]>
Date: Mon, 24 Mar 2008 15:52:19 -0400

During the Wednesday Plenary at IETF 71, I gave the IETF community a 
"heads up" on two documents from the IPR WG that were nearing IETF 
Last Call.  Both of the documents have now reached IETF Last 
call.  The Last Call announcements are attached.  Please review and comment.

Russ

== == == == == == == == == ==

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-ipr-outbound-rights (Advice to the
         Trustees of the IETF Trust on Rights to be Granted in IETF
         Documents) to Informational RFC
Date: Wed, 19 Mar 2008 15:15:56 -0700 (PDT)
Cc: [email-masked]

The IESG has received a request from the Intellectual Property Rights WG
(ipr) to consider the following document:

- 'Advice to the Trustees of the IETF Trust on Rights to be Granted in
    IETF Documents '
    <draft-ietf-ipr-outbound-rights-06.txt> as an Informational RFC

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 2008-04-02. 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-ipr-outbound-rights-06.txt

This document is closely related to draft-ietf-ipr-3978-incoming.
The two documents should be considered as a set.  IETF Last Call for
draft-ietf-ipr-3978-incoming will begin as soon as the next update is
posted.

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14518&rfc_flag=0

== == == == == == == == == ==

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-ipr-3978-incoming (Rights Contributors
         provide to the IETF Trust) to BCP
Date: Mon, 24 Mar 2008 07:19:57 -0700 (PDT)
Cc: [email-masked]

The IESG has received a request from the Intellectual Property Rights WG
(ipr) to consider the following document:

- 'Rights Contributors provide to the IETF Trust '
    <draft-ietf-ipr-3978-incoming-08.txt> as a BCP

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 2008-04-07. 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-ipr-3978-incoming-08.txt

This document is closely related to draft-ietf-ipr-outbound-rights,
which is already in Last Call.  The two documents should be considered
as a set.

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15855&rfc_flag=0

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Mar 2008 21:30:54 -0600

> call.  The Last Call announcements are attached.  Please review and comment.

I've given these drafts a first reading. The following comments may
represent a misunderstanding on my part, but I provide them in the
interest of clarifying the meaning of these drafts.

One concern I have is the distinction between text and code. Where and
how is that line drawn? What about, for example, protocol examples (of
which there are many in most RFCs)? Are they text or code?

Another concern is the limitation on copying of text. It seems quite
reasonable for developers to include snippets of text in their programs
(think literate programming), and under many code licenses it is
difficult if not impossible to separately license the code and any
copied text when bundled together.

Regarding the copying of text, Section 4.4 of the outgoing draft says:

   There is no consensus at this time to permit the use of text from
   RFCs in contexts where the right to modify the text is required.  The
   authors of IETF contributions may be able and willing to grant such
   rights independently of the rights they have granted to the IETF by
   making the contribution.

But Section 6 of the incoming draft says:

   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 the document
   is a republication of the work of another standards development
   organization.  Such exceptions must be approved on an individual
   basis by the IAB.

So it's not clear to me how contributors could (easily) grant the right
to modify text that is copied from an RFC -- unless they do so outside
the Internet Standards Process (based, I suppose, on the rights retained
by the contributors). However, it seems that each implementor would need
to separately approach the contributors in order to do that (and how
would they know that the contributors are approachable in that way if
not through inclusion of some kind of notice in the relevant RFC -- and
would such a notice comprise an "additional copyright notice" as
described in Section 6 fo the incoming draft?).

Finally, the outbound draft merely provides recommendations regarding
license text and other materials, final definition of which seems to be
under the sole purview of the Trustees of the IETF Trust. However, the
outbound draft does not specify if the work of the Trustees shall be
subject to review by the IPR WG, the IESG, the IAB, or the IETF
community (e.g., in the form of an Internet-Draft) before it takes effect.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2008 16:57:45 +1300

> call.  The Last Call announcements are attached.  Please review and comment.

I'd like to express support for both drafts, and also to confirm
what's said about WG consensus in the writeup at
https://datatracker.ietf.org/idtracker/draft-ietf-ipr-3978-incoming/comment/77819/ .

I won't comment on Peter Saint-Andre's comments because the authors
or WG chair can do so more accurately than I could, but those points
were all discussed at some length iirc.

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Mar 2008 00:23:16 -0400

Comments in response to your comments on -outbound...
Firstly, thank you for reading these.
Second, what follows are my understandings of the reasons / contents.

> which there are many in most RFCs)? Are they text or code?

The document provides two ways to distinguish code from text.  It lists 
a set of constructs that are considered code.  Recognizing that things 
change, the draft indicates that the trustees shall maintain a list of 
such code.  The also says that the trustees shall come up with a marking 
mechanism so working groups can mark other things that need to be 
considered code, since there are often special cases.

This distinction was the working group rough consensus (as determined by 
the chairs), after MUCH discussion.

> copied text when bundled together.

The question of whether to allow arbitrary modifications of all text 
from RFCs was discussed.  While there are some drawbacks of the 
agreement that was reached, in terms of the ability to use text from the 
RFC as documentation in programs which by license are subject to 
arbitrary change, there are also serious concerns about allowing 
arbitrary changes of text.  The text of RFCs often represents careful 
work to get the right meaning.  Arbitrary, well intentioned changes, may 
often introduce unintended problems.  (The discussion covered many 
related aspects, many of which I can not recreate on the fly.)
Obviously, this is closely related to the decision to create the code / 
text distinction.

> described in Section 6 fo the incoming draft?).
Indeed, any such grant would have to be outside the IETF process.  A 
legal notice is not what is needed to let folks know there are other 
options.  An informational note is quite different from a legal notice.

> community (e.g., in the form of an Internet-Draft) before it takes effect.

The decision to exclude legal text from the outbound document was a 
deliberate working group decision.  Having working groups write legal 
text has produced problems repeatedly.  So we concluded that was a bad 
way to proceed.  The question of how the trust will proceed to do its 
job is outside of this working groups purview.  The trustees have said 
it will take direction from the IETF.  I presume they will come up with 
a reasonable strategy for verifying that what they produce does what the 
community has said it wants.
In the worst case, if the community concludes that the trustees actions 
aren't what we want, we can either replace the trustees or write another 
IETF RFC.  Trying to work that out in this draft did not seem productive.

> Peter

Yours,
Joel M. Halpern

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 26 Mar 2008 15:25:29 +0100

> which there are many in most RFCs)? Are they text or code?

the -outgoing draft contains this text:

   IETF contributions often include components intended to be directly
   processed by a computer.  Examples of these include ABNF definitions,
   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
   MIBs, ASN.1, or classical programming code.

And, recognizing that it's impossible to come up with a closed list of such
items that is valid for all time:

   While it is up to the Trustees of the IETF Trust to determine the
   best way of meeting this objective, two mechanisms are suggested here
   that are believed to be helpful in documenting the intended grant to
   readers and users of IETF contributions.

   Firstly, the Trustees of the IETF Trust should maintain, in a
   suitable, easily accessible fashion, a list of common RFC components
   which will be considered to be code.  To start, this list should
   include at least the items listed above.  The Trustees of the IETF
   Trust will add to this list as they deems suitable or as it is
   directed by the IETF.

   Additionally, the Trustees of the IETF Trust should define a textual
   representation to be included in an IETF contribution to indicate
   that a portion of the document is considered by the authors (and
   later the working group, and upon approval the IETF) to be code, and
   to be subject to the permissions granted to use code.

I don't think protocol examples are code - they're not written in a 
parseable language. OTOH, if someone were to write protocol examples using 
an ASCII representation of ITU-T's TTCN, that would probably be code, and 
the IETF Trust should update their list to include that format.

> described in Section 6 fo the incoming draft?).

Exactly; this is no change from the current copying conditions for RFCs. In 
fact, the code copying conditions are more permissive than the status quo 
ante.

A note claiming that "this text is also available from source X, check 
copying conditions there" would not be a copyright notice.
I don't think "this text is also available under GFDL from source X" is a 
copyright notice either; it's a license, not a copyright notice.

> community (e.g., in the form of an Internet-Draft) before it takes effect.

No, it does not. I'd like someone from the Trust to speak up about their 
thoughts about suitable review processes.

Note that the IPR WG can't do the review going forward; once these 
documents are approved (if they are), I intend to ask that the group is 
shut down.

                Harald

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Mar 2008 14:14:31 -0600

Harald Tveit Alvestrand wrote:
> parseable language. OTOH, if someone were to write protocol examples
> using an ASCII representation of ITU-T's TTCN, that would probably be
> code, and the IETF Trust should update their list to include that format.
> 
> Exactly; this is no change from the current copying conditions for RFCs.
> In fact, the code copying conditions are more permissive than the status
> quo ante.
> 
> I don't think "this text is also available under GFDL from source X" is
> a copyright notice either; it's a license, not a copyright notice.

OK, thanks for the clarification. I just wanted to be sure.

> thoughts about suitable review processes.

Yes, that would be appreciated.

> documents are approved (if they are), I intend to ask that the group is

That seems sensible.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Mar 2008 10:06:20 +1300

>> <[email-masked]> wrote:

<snip>

>> documents are approved (if they are), I intend to ask that the group is

Also note that appeal and recall procedures for the IAOC are
defined in RFC 4071, and that clearly includes Trust actions,
since the Trustees are by definition the IAOC members. So if
the IETF doesn't like the final result, there is recourse.

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 Mar 2008 00:08:24 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Also note that appeal and recall procedures for the IAOC
    Brian> are defined in RFC 4071, and that clearly includes Trust
    Brian> actions, since the Trustees are by definition the IAOC
    Brian> members. So if the IETF doesn't like the final result,
    Brian> there is recourse.

However much less recourse than normal.  The appeal of the IAOC
decisions is intentionally fairly limited.  Honestly, I think our real
recourse if the IETF didn't agree with the trust's general policy is
to hit them over the head with a BCP.

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 27 Mar 2008 10:33:24 +0100

While reviewing the documents I tried to determine how the 4 streams  
currently defined in RFC4844 fit into the framework.

Although the stream is not specifically mentioned it is clear that the  
incoming rights document applies to the IETF Stream.

To me it is clear that a contribution to the IAB is explicitly bound  
by the rules (including the No Duty to Publish rule, that allows for  
confidential information to be supplied to the IAB), so are  
contributions from the IAB, i.e. IAB stream document. I conclude this  
from the fact that "IAB" is part of the IETF under the definition in  
1.e. However, I may be over-interpreting, and the status of the  
incoming rights for the IAB stream is also not captured.

The independent stream document are clearly excluded by section 4 of  
the document.

It is not quite clear where the IRTF stream document live. This could  
be fixed in a document which defines the IRTF stream.

I would think that the document would gain in clarity if it explicitly  
ties the incoming rights to the streams as defined in RFC4844 and also  
explicitly calls out that if new streams would be defined those should  
specifically define if and how rights are transfered to the IETF Trust.

--Olaf (no hats)

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 27 Mar 2008 15:15:48 -0400

--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman <[email-masked]> 
wrote:
> specifically define if and how rights are transferred to the IETF Trust.

I would have to agree with the above, and say further that the
the IAB should make sure that the entities responsible for
the non-IETF streams are okay with the result.

When writing the streams definitions, it was clear that there was a
lot of material that was spread across existing documents without
clear delineation between "IETF" or "non-IETF" documents, let
alone further refinement into what has become "streams".  THat's
understandable, historically, but we should be clearer going
forward.  Breaking it out, as you suggest, would be consistent
with that goal.

Leslie.

> To me it is clear that a contribution to the IAB is explicitly bound by
> the rules (including the No Duty to Publish rule, that allows for
> confidential information to be supplied to the IAB), so are contributions
> from the IAB, i.e. IAB stream document. I conclude this from the fact
> that "IAB" is part of the IETF under the definition in 1.e. However, I
> may be over-interpreting, and the status of the incoming rights for the
> IAB stream is also not captured.
>
> The independent stream document are clearly excluded by section 4 of the
> document.
>
> It is not quite clear where the IRTF stream document live. This could be
> fixed in a document which defines the IRTF stream.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Mar 2008 10:28:45 +1300

While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents. We can have a meta-discussion about
where the clarifications belong, but it seems to me
that the WG consensus definitely assumed that scope
and no wider scope. I'd be happy if that was made
clear in the drafts, rather than trying to cover
the other documents streams by some kind of awkward
retro-fit.

   Brian

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 28 Mar 2008 08:14:01 +0100

On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
> IETF documents.

Those being ietf-stream exclusively or implicitly also covering the  
iab-stream?

Personally, I think it makes sense that the iab-stream is covered, but  
let me put that in front of the IAB too.

> We can have a meta-discussion about

My suggestion is to rewrite  section 4 a bit to call out that this  
document does not cover the incoming rights for the independent and  
irtf stream and to use the terms "ietf-stream" and possibly "iab- 
stream" in the definitions.

Such a rewrite would preserve the status quo for the independent and  
irtf stream.

no-hats,

--Olaf

<no further comments below>

On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
>>> contributions

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Mar 2008 11:01:46 +0100

Regarding -outbound section 4.3:

   IETF contributions often include components intended to be directly
   processed by a computer.  Examples of these include ABNF definitions,
   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
   MIBs, ASN.1, or classical programming code.  These are included in
   IETF contributions for clarity and precision in specification.  It is
   clearly beneficial, when such items are included in IETF
   contributions, to permit the inclusion of such code components in
   products which implement the contribution.  It has been pointed out
   that in several important contexts use of such code requires the
   ability to modify the code.  One common example of this is simply the
   need to adapt code for use in specific contexts (languages,
   compilers, tool systems, etc.)  Such use frequently requires some
   changes to the text of the code from the IETF contribution.  Another
   example is that code included in open source products is frequently
   licensed to permit any and all of the code to be modified.  Since we
   want this code included in such products, it follows that we need to
   permit such modification.  While there has been discussion of
   restricting the rights to make such modifications in some way, the
   rough consensus of the IETF is that such restrictions are likely a
   bad idea, and are certainly very complex to define.

   As such, the rough consensus is that the IETF Trust is to grant
   rights such that code components of IETF contributions can be
   extracted, modified, and used by anyone in any way desired.  To
   enable the broadest possible extraction, modification and usage, the
   IETF Trust should avoid adding software license obligations beyond
   those already present in a contribution.  The granted rights to
   extract, modify and use code should allow creation of derived works
   outside the IETF that may carry additional license obligations.
...

I believe the intention here is good, but it leaves the IETF Trust with
no guidelines on how to write the license declaration that is likely to
work well in practice with actual products.  There are no reference to
what "open source" means in this context, and references to "free
software" is missing.

I believe it would be a complete failure if code-like portions of RFCs
cannot be included into open source and free software products such as
the Debian project.

To give the Trust something concrete to work with I propose to add the
following:

  To make sure the granted rights are usable in practice, they need to
  at least meet the requirements of the Open Source Definition [OSD],
  the Free Software Definition [FSD], and the Debian Free Software
  Guidelines [DFSG].

For those who fear that this will lead to complexity: releasing
something that is compatible with those requirements is simple.  The
modified BSD license meets those requirements, as does a number of other
methods, including releasing the work into the public domain.

The references being:

[OSD] "The Open Source Definition",
      http://opensource.org/docs/osd

[FSD] "The Free Software Definition",
      http://www.fsf.org/licensing/essays/free-sw.html

[DFSG] "The Debian Free Software Guidelines",
      http://www.debian.org/social_contract#guidelines

Thanks,
Simon

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 28 Mar 2008 06:56:29 -0700

>   the Free Software Definition [FSD], and the Debian Free Software

+1

/Larry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Josefsson
> Sent: Friday, March 28, 2008 3:02 AM
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: IETF Last Call for two IPR WG Dcouments
>

---

From: [email-masked] (Scott O. Bradner)
Date: Fri, 28 Mar 2008 10:09:16 -0400 (EDT)

> stream" in the definitions.

thats all well & good for the independent stream since they have 
their own ruleset but gets tricky for irtf unless they do and
splitting off iert & iab from teh rest of the ietf seems a bit
funky

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Mar 2008 10:21:44 -0400

I do not understand the problem you want addressed.  The way this is 
worded, it doesn't matter what "open source" or "free software" is or 
becomes.  The intention is to grant anyone to do anything with the code 
segments.  That's what we ask the trust to do. Further in line.

...
>    outside the IETF that may carry additional license obligations.
This says that the trust is to grant rights so that code can be 
extracted, modified, and used by ANYONE.  I.e. our grant will not place 
restrictions on people.

> cannot be included into open source and free software products such as
If we grant anyone the right to use the code any way they want, which 
means that we specifically can not require preservation of notices or 
anything else, how could it fail to meet the requirements of the 
specific cases you list?

> methods, including releasing the work into the public domain.
My concern is not complexity.  Referencing the specific documents is 
more restrictive than what the working group recommended.  I don't see 
why that would help anything.

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Mar 2008 16:16:51 +0100

> segments.  That's what we ask the trust to do. Further in line.

The problem is that without proper guidelines on how to make a software
license compatible with free software licenses, it is possible to end up
with something that won't be compatible, and thus wouldn't meet the
intended goals.

Given that the IETF Trust doesn't publish drafts or have a history of
asking for community review on the legal license they chose, I believe
it is important that the IETF articulate its wishes in ways that reduce
chances of misunderstandings or are open for interpretation.

> extracted, modified, and used by ANYONE.  I.e. our grant will not place 

Agreed.

> anything else, how could it fail to meet the requirements of the 

If you show me the software license that is going to be used, the
community will be able to tell you.

Writing software licenses that are compatible with free software
licenses is a complicated area, and there are many ways to fail.  If you
haven't evaluated licenses for compatibility before, I suggest to look
at what the debian-legal list has been doing.  There are subtle issues
that can prevent a license from giving the necessary rights.  As far as
I know the IETF Trust does not have extensive knowledge of free software
licensing and license compatibility considerations.  Helping them to get
this right by providing some sanity tests (the OSD, FSD and DFSG) to run
their drafts against will help them.

> why that would help anything.

Please read again what I proposed, in particular "at least meet the
requirements".  If the Trust's software license do not meet those
requirements, then it clearly will not meet the intended IETF goals that
we agree on.

/Simon

---

From: Ted Hardie <[email-masked]>
Date: Fri, 28 Mar 2008 08:54:18 -0700

>chances of misunderstandings or are open for interpretation.

I disagree with Simon's addition.  The intent of the document is to
give the Trust instructions from the community that we want
the code in RFCs to be available to anyone to do anything.
As Joel put it:

"The intention is to grant anyone to do anything with the code
segments.  That's what we ask the trust to do. "

That was the consensus of the working group, and I believe it
should remain the consensus of the IETF as a whole--it gives
the widest possible reach to the standard.  Crafting the legal
language to make that work is a task best left to lawyers;
adding specific compatibility requirements that appear
to privilege one set of follow-on outputs is both confusing and ultimately
pointless.  The language in the draft is clear that we want
the code to be usable by *anyone*.  It wouldn't add anything
to that mandate to list specific individuals, and it doesn't
add anything to list specific licenses that will only apply
after an individual has already used the code.

			regards,
					Ted

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Mar 2008 11:19:19 -0600

> segments.  That's what we ask the trust to do. Further in line.

I think Simon is suggesting that we provide some guidance to the Trust
in choosing a license. IANAL, however the phrase "grant anyone to do
anything" sounds nice in theory but needs to be translated into a
functioning license. As far as I can see there are three licenses that
would fit the bill:

1. The MIT license
2. A BSD-style license
3. A designation that the code is in the public domain

Some people allege that it is not possible to put a work directly into
the public domain (although I disagree), which is why they prefer to use
a license.

As a point of comparison, the XMPP Standards Foundation recently worked
to make sure that its specifications are safe for inclusion in free
sofware, and decided upon a slightly-modified MIT license (modified in
order to make clear that we were publishing specifications, not code).
The resulting license is here:

http://www.xmpp.org/extensions/ipr-policy.shtml

> extracted, modified, and used by ANYONE.  I.e. our grant will not place 

Correct. But we need to have a license over the code, not just say that
anyone can use it, which legally is void for vagueness (IMO IANAL etc.).

> anything else, how could it fail to meet the requirements of the 

Because it is not covered by a license.

> why that would help anything.

See above. Perhaps it would be more helpful to reference some specific
licenses that would realize the stated intent?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 28 Mar 2008 13:49:46 -0400

>http://www.xmpp.org/extensions/ipr-policy.shtml
The Trustees adopted the Non-Profit Open Software License 3.0 in 
September 2007 as the license it would use for open sourcing software 
done as work-for-hire and that contributed to it, at that time thinking 
of code contributed by IETF volunteers.  See:  
http://trustee.ietf.org/licenses.html 

Is it clear that the contributions contemplated by these documents would 
require a different treatment?

Ray
Trustee
IAD

>------------------------------------------------------------------------
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Mar 2008 12:15:53 -0600

Ray Pelletier wrote:
>>> becomes.  The intention is to grant anyone to do anything with the
>>> code segments.  That's what we ask the trust to do. Further in line.
>>>   
>>

Thanks for the link. I had not been aware of this license, so I'll take
some time to read it before commenting. I've also sent the text of the
license to the debian-legal list for discussion among that community.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: SM <[email-masked]>
Date: Fri, 28 Mar 2008 11:25:26 -0700

>what "open source" means in this context, and references to "free

The above are guidelines.  You'll get a different definition of what 
"open source" or "free software" is depending on whom you ask.  The 
words "enable the broadest possible extraction, modification and 
usage" provides more scope.

>   the Free Software Definition [FSD], and the Debian Free Software

These are not guidelines; they are requirements.

Regards,
-sm

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 28 Mar 2008 14:30:06 -0400

Ray Pelletier wrote:
> September 2007 as the license it would use for open sourcing  
> software done as work-for-hire and that contributed to it, at that  
> time thinking of code contributed by IETF volunteers.  See:  http:// 
> trustee.ietf.org/licenses.html
>
> Is it clear that the contributions contemplated by these documents  
> would require a different treatment?

Disclaimer:  IANAL, and I apologize if I am misunderstanding  
something about the license you referenced, but...

It seems to me that the "Non-Profit Open Software License 3.0", while  
fine for the source code to IETF tools, places more restrictions and  
more burden on someone who uses the code than we would want to place  
on someone who uses a MIB, XML schema or other "code" from our RFCs.

For example, the license places an obligation on someone using the  
source code to distribute copies of the original source code with any  
products they distribute.  Effectively, this means that anyone who  
distributes products based on MIBs, XML schemas or other "code" from  
RFCs would need to put up a partial RFC repository.  Why would we  
want that?

Margaret

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Mar 2008 12:39:43 -0600

> These are not guidelines; they are requirements.

This is true.

Rather than wrangling over text that might be added to -outbound,
perhaps it would be more productive to describe how members of the
Internet community can provide input to the Trust regarding this issue
(or any other, for that matter). It seems to me that the information at
http://trustee.ietf.org/ does not describe the relevant processes, other
than mentioning <mailto:[email-masked]>.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 28 Mar 2008 14:44:17 -0400

I would think that any license for RFC code should meet two
requirements:
1) It should be usable by anyone in the open source community
(compatible 
   with any open source/free software license).
2) It should be usable by anyone in any corporation who sells a closed 
   source product.

That way, we can ensure interoperability between open source and closed
source 
implementations.  Note that these requirements greatly constrain the
form that the
license should take.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Margaret Wasserman
Sent: Friday, March 28, 2008 2:30 PM
To: Ray Pelletier
Cc: Simon Josefsson; Joel M. Halpern; [email-masked]
Subject: Re: IETF Last Call for two IPR WG Dcouments

Ray Pelletier wrote:
> done as work-for-hire and that contributed to it, at that time 
> thinking of code contributed by IETF volunteers.  See:  http:// 

Margaret

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Mar 2008 12:57:20 -0600

> http://trustee.ietf.org/licenses.html

Because the license is provided in a PDF file, I have pasted the text
below for ease of discussion.

****** BEGIN LICENSE ******

Non-Profit Open Software License ("Non-Profit OSL") 3.0

This Non-Profit Open Software License ("Non-Profit OSL") version 3.0
(the "License") applies to any original work of authorship (the
"Original Work") whose owner (the "Licensor") has placed the following
licensing notice adjacent to the copyright notice for the Original Work:

Licensed under the Non-Profit Open Software License version 3.0

1) Grant of Copyright License. Licensor grants You a worldwide,
royalty-free, non-exclusive, sublicensable license, for the duration of
the copyright, to do the following:

a) to reproduce the Original Work in copies, either alone or as part of
a collective work;

b) to translate, adapt, alter, transform, modify, or arrange the
Original Work, thereby creating derivative works ("Derivative Works")
based upon the Original Work;

c) to distribute or communicate copies of the Original Work and
Derivative Works to the public, with the proviso that copies of Original
Work or Derivative Works that You distribute or communicate shall be
licensed under this Non-Profit Open Software License or as provided in
section 17(d);

d) to perform the Original Work publicly; and

e) to display the Original Work publicly.

2) Grant of Patent License. Licensor grants You a worldwide,
royalty-free, non-exclusive, sublicensable license, under patent claims
owned or controlled by the Licensor that are embodied in the Original
Work as furnished by the Licensor, for the duration of the patents, to
make, use, sell, offer for sale, have made, and import the Original Work
and Derivative Works.

3) Grant of Source Code License. The term "Source Code" means the
preferred form of the Original Work for making modifications to it and
all available documentation describing how to modify the Original Work.
Licensor agrees to provide a machine-readable copy of the Source Code of
the Original Work along with each copy of the Original Work that
Licensor distributes. Licensor reserves the right to satisfy this
obligation by placing a machine-readable copy of the Source Code in an
information repository reasonably calculated to permit inexpensive and
convenient access by You for as long as Licensor continues to distribute
the Original Work.

4) Exclusions From License Grant. Neither the names of Licensor, nor the
names of any contributors to the Original Work, nor any of their
trademarks or service marks, may be used to endorse or promote products
derived from this Original Work without express prior permission of the
Licensor. Except as expressly stated herein, nothing in this License
grants any license to Licensor‚Äôs trademarks, copyrights, patents,
trade secrets or any other intellectual property. No patent license is
granted to make, use, sell, offer for sale, have made, or import
embodiments of any patent claims other than the licensed claims defined
in Section 2. No license is granted to the trademarks of Licensor even
if such marks are included in the Original Work. Nothing in this License
shall be interpreted to prohibit Licensor from licensing under terms
different from this License any Original Work that Licensor otherwise
would have a right to license.

5) External Deployment. The term "External Deployment" means the use,
distribution, or communication of the Original Work or Derivative Works
in any way such that the Original Work or Derivative Works may be used
by anyone other than You, whether those works are distributed or
communicated to those persons or made available as an application
intended for use over a network. As an express condition for the grants
of license hereunder, You must treat any External Deployment by You of
the Original Work or a Derivative Work as a distribution under section
1(c).

6) Attribution Rights. You must retain, in the Source Code of any
Derivative Works that You create, all copyright, patent, or trademark
notices from the Source Code of the Original Work, as well as any
notices of licensing and any descriptive text identified therein as an
"Attribution Notice." You must cause the Source Code for any Derivative
Works that You create to carry a prominent Attribution Notice reasonably
calculated to inform recipients that You have modified the Original Work.

7) Warranty of Provenance and Disclaimer of Warranty. The Original Work
is provided under this License on an "AS IS" BASIS and WITHOUT WARRANTY,
either express or implied, including, without limitation, the warranties
of non-infringement, merchantability or fitness for a particular
purpose. THE ENTIRE RISK AS TO THE QUALITY OF THE ORIGINAL WORK IS WITH
YOU. This DISCLAIMER OF WARRANTY constitutes an essential part of this
License. No license to the Original Work is granted by this License
except under this disclaimer.

8) Limitation of Liability. Under no circumstances and under no legal
theory, whether in tort (including negligence), contract, or otherwise,
shall the Licensor be liable to anyone for any direct, indirect,
special, incidental, or consequential damages of any character arising
as a result of this License or the use of the Original Work including,
without limitation, damages for loss of goodwill, work stoppage,
computer failure or malfunction, or any and all other commercial damages
or losses. This limitation of liability shall not apply to the extent
applicable law prohibits such limitation.

9) Acceptance and Termination. If, at any time, You expressly assented
to this License, that assent indicates your clear and irrevocable
acceptance of this License and all of its terms and conditions. If You
distribute or communicate copies of the Original Work or a Derivative
Work, You must make a reasonable effort under the circumstances to
obtain the express assent of recipients to the terms of this License.
This License conditions your rights to undertake the activities listed
in Section 1, including your right to create Derivative Works based upon
the Original Work, and doing so without honoring these terms and
conditions is prohibited by copyright law and international treaty.
Nothing in this License is intended to affect copyright exceptions and
limitations (including "fair use" or "fair dealing"). This License shall
terminate immediately and You may no longer exercise any of the rights
granted to You by this License upon your failure to honor the conditions
in Section 1(c).

10) Termination for Patent Action. This License shall terminate
automatically and You may no longer exercise any of the rights granted
to You by this License as of the date You commence an action, including
a cross-claim or counterclaim, against Licensor or any licensee alleging
that the Original Work infringes a patent. This termination provision
shall not apply for an action alleging patent infringement by
combinations of the Original Work with other software or hardware.

11) Jurisdiction, Venue and Governing Law. Any action or suit relating
to this License may be brought only in the courts of a jurisdiction
wherein the Licensor resides or in which Licensor conducts its primary
business, and under the laws of that jurisdiction excluding its
conflict-of-law provisions. The application of the United Nations
Convention on Contracts for the International Sale of Goods is expressly
excluded. Any use of the Original Work outside the scope of this License
or after its termination shall be subject to the requirements and
penalties of copyright or patent law in the appropriate jurisdiction.
This section shall survive the termination of this License.

12) Attorneys‚Äô Fees. In any action to enforce the terms of this
License or seeking damages relating thereto, the prevailing party shall
be entitled to recover its costs and expenses, including, without
limitation, reasonable attorneys' fees and costs incurred in connection
with such action, including any appeal of such action. This section
shall survive the termination of this License.

13) Miscellaneous. If any provision of this License is held to be
unenforceable, such provision shall be reformed only to the extent
necessary to make it enforceable.

14) Definition of "You" in This License. "You" throughout this License,
whether in upper or lower case, means an individual or a legal entity
exercising rights under, and complying with all of the terms of, this
License. For legal entities, "You" includes any entity that controls, is
controlled by, or is under common control with you. For purposes of this
definition, "control" means (i) the power, direct or indirect, to cause
the direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.

15) Right to Use. You may use the Original Work in all ways not
otherwise restricted or conditioned by this License or by law, and
Licensor promises not to interfere with or be responsible for such uses
by You.

16) Modification of This License. This License is Copyright ¬© 2005
Lawrence Rosen.  Permission is granted to copy, distribute, or
communicate this License without modification. Nothing in this License
permits You to modify this License as applied to the Original Work or to
Derivative Works. However, You may modify the text of this License and
copy, distribute or communicate your modified version (the "Modified
License") and apply it to other original works of authorship subject to
the following conditions: (i) You may not indicate in any way that your
Modified License is the "Open Software License" or "OSL" and you may not
use those names in the name of your Modified License; (ii) You must
replace the notice specified in the first paragraph above with the
notice "Licensed under <insert your license name here>" or with a notice
of your own that is not confusingly similar to the notice in this
License; and (iii) You may not claim that your original works are open
source software unless your Modified License has been approved by Open
Source Initiative (OSI) and You comply with its license review and
certification process.

17) Non-Profit Amendment. The name of this amended version of the Open
Software License ("OSL 3.0") is "Non-Profit Open Software License 3.0".
The original OSL 3.0 license has been amended as follows:

(a) Licensor represents and declares that it is a not-for-profit
organization that derives no revenue whatsoever from the distribution of
the Original Work or Derivative Works thereof, or from support or
services relating thereto.

(b) The first sentence of Section 7 ["Warranty of Provenance"] of OSL
3.0 has been stricken. For Original Works licensed under this Non-Profit
OSL 3.0, LICENSOR OFFERS NO WARRANTIES WHATSOEVER.

(c) In the first sentence of Section 8 ["Limitation of Liability"] of
this Non-Profit OSL 3.0, the list of damages for which LIABILITY IS
LIMITED now includes "direct" damages.

(d) The proviso in Section 1(c) of this License now refers to this
"Non-Profit Open Software License" rather than the "Open Software
License". You may distribute or communicate the Original Work or
Derivative Works thereof under this Non-Profit OSL 3.0 license only if
You make the representation and declaration in paragraph (a) of this
Section 17. Otherwise, You shall distribute or communicate the Original
Work or Derivative Works thereof only under the OSL 3.0 license and You
shall publish clear licensing notices so stating. Also by way of
clarification, this License does not authorize You to distribute or
communicate works under this Non-Profit OSL 3.0 if You received them
under the original OSL 3.0 license.

(e) Original Works licensed under this license shall reference
"Non-Profit OSL 3.0" in licensing notices to distinguish them from works
licensed under the original OSL 3.0 license.

****** END LICENSE ******

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 28 Mar 2008 12:21:02 -0700

> RFCs would need to put up a partial RFC repository.  Why would we

As the author of the Non-Profit Open Software License 3.0 (NOSL 3.0),
perhaps I can clear up some misconceptions about it.

* NOSL 3.0 is for software tools; it is not a standards license. It is not
used as the outbound license for any code in RFCs, and thus there is no
obligation that I'm aware of to put up a "partial RFC repository" anywhere. 

* NOSL 3.0 does not obligate someone merely "using" the source code or the
software to distribute anything at all. 

* Source code must be made available by anyone who actually distributes the
software or derivative works thereof to third parties. (The definition in
NOSL 3.0 of "distribution" is important but not relevant to this thread.)

* Source code need not be distributed "with" products containing that
software. Typically, distribution of source code is handled through separate
links on websites, just as most open source software companies now
distribute software and source code.

* Products that incorporate unmodified copies of NOSL 3.0 software tools
rather than derivative works thereof can just inform customers to link to
the IETF website itself for source code. That also serves as a way for IETF
and its contributors to receive credit for writing that free and open source
software in the first place.

* The reciprocity obligation for derivative works and patents in NOSL 3.0 is
on purpose. Everyone is free to use those software tools for any purpose
whatsoever, but improvements to them *that are distributed to third parties*
must be returned to IETF for the potential benefit of other members of the
IETF community. 

* As you may have seen in recent discussions about the proposed IETF IPR
policies, one goal is to allow anyone to create and distribute products that
embody IETF standards under any license whatsoever. Whatever the outbound
license turns out to be for RFCs, it will presumably not dictate or limit
the license terms for products embodying those RFCs. For that reason alone,
NOSL 3.0 is not appropriate for RFC outbound licensing.

Further information about NOSL 3.0 and related licenses, is at
www.rosenlaw.com/OSL3.0-explained.pdf.  

For various reasons, AFL 3.0, also described in that paper, would perhaps be
a more appropriate outbound license for code in RFCs, but that too is a
topic for a potential separate thread.

Best regards,

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen
Author of "Open Source Licensing: Software Freedom and 
                Intellectual Property Law" (Prentice Hall 2004)

> Sent: Friday, March 28, 2008 11:30 AM
> To: Ray Pelletier

---

From: <[email-masked]>
Date: Fri, 28 Mar 2008 19:42:24 -0000

> c) to distribute or communicate copies of the Original Work 
> and Derivative Works to the public, with the proviso that 
> copies of Original Work or Derivative Works that You 
> distribute or communicate shall be licensed under this 
> Non-Profit Open Software License or as provided in section 17(d);

Is this a viral clause similar to that found in the GPL which
makes numerous commercial developers purposely avoid incorporating
such code into theirs? And in the IETF context, wouldn't this
clause encourage developers to create implementations that
ARE NOT COMPATIBLE WITH IETF STANDARDS?

Of course, IANAL but I really don't see why the IETF couldn't use
a licence which is basically the MIT or BSD licence possibly along
with some language about granting a patent license.

Is there a reason why the IETF does not submit its prospective license
to the OSI for approval? They know more about Open Source licences 
than anyone. There is more information here
<http://www.opensource.org/approval>

--Michael Dillon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Mar 2008 15:51:23 -0400

The agreement was to let the trust work out the legal details.  This 
document is intended to tell the trust what we want, clearly and 
unambiguously.  The current text is unambiguous.  If we start trying to 
say that this or that specific license is a good starting point, then 
they have to figure out what aspects of that license we mean.
I certainly would not want to try to tell the lawyers what possible 
models there are to do their job.

Collapsing several other related notes:
No, I don't think that the agreement used for the code being written for 
the IETF will work (NOSL 3.0), since it is not as broad as described in 
this document.  (I do sometimes agree with Mr. Rosen.)
But I don't have any trouble allowing the trustees to do their job, 
which will include determining what license is appropriate.

Also, I don't see any need to point to specific examples to get at 
issues like "royalty free."  It is true that to meet the constraints, 
and the reality of RFC publication, the IETF license grant will be 
royalty free.  It's pretty hard to see how a license to permit anyone to 
do anything they want with the source code can be restricted by payments 
etc.

Remember, the state approach is for this document to state our goal, and 
for the trust to achieve what we ask.  The goal is not for us to 
shoehorn legal text into the outbound document.

Yours,
Joel

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Mar 2008 13:53:19 -0600

Lawrence Rosen wrote:
> used as the outbound license for any code in RFCs, 

I understood Ray Pelletier to be suggesting that as a possibility, since
he said: "Is it clear that the contributions contemplated by these
documents would require a different treatment?" Which I took to mean
that NOSL 3.0 might be applied to the code snippets contained in RFCs.

> and thus there is no

Not yet. :)

> software to distribute anything at all. 

However, the same does not apply to Derivative Works.

> must be returned to IETF for the potential benefit of other members of the

That all makes perfect sense for the code produced by the Tools Team.

Agreed.

> www.rosenlaw.com/OSL3.0-explained.pdf.  

Reading.

> topic for a potential separate thread.

Thanks for the clarifications.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Mar 2008 10:57:58 +1300

+1. I couldn't express it better.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Mar 2008 11:21:12 +1300

> Those being ietf-stream exclusively or implicitly also covering the

I think the clear separation defined in RFC 4844 was not so clear
at the time the WG took its major decisions. However, my personal
assumption was that we were only talking about the IETF stream.

> let me put that in front of the IAB too.

It makes sense to me that the IPR conditions for IAB documents
should be identical to those for IETF documents.

> document does not cover the incoming rights for the independent and irtf
> stream and to use the terms "ietf-stream" and possibly "iab-stream" in
> the definitions.

As the responsibilities are defined in sections 5.1.1 and 5.1.2
of RFC 4844, it seems to me that an IETF-stream BCP can only
define the rules for IETF-stream RFCs. So I think the IAB would
need to issue its own IPR addendum to RFC 4845.

> Such a rewrite would preserve the status quo for the independent and

If you're sure what the status quo actually is...

    Brian
>>>> the

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 29 Mar 2008 00:36:21 +0100

> require a different treatment?

My view on this:  Yes, definitely.  The two cases are very different,
and the kind of license which is needed and wanted is also very different.

In the case of work-for-hire for the IASA, we're talking about IETF-specific
code used to run the services needed by the IETF, such as for instance the
datatracker; and the purpose of using the OSL 3.0 license is that it is more
acceptable to commercial entities providing the services than GPL, while still
being clear on requiring derivative code used to provide services to be
contributed back as open source.

In the case of code embedded in standards documents, we want it to be as widely
used as possible, which as far as I'm concerned means limiting the requirements
on the users of the code as much as legally possible.  I'd love to have that
code put in the public domain, but as IANAL I have no idea whether that's
possible.

	Henrik

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 29 Mar 2008 10:10:54 +0100

>    with any open source/free software license).

Exactly.  The text I proposed provides three ways to test whether a
proposed license would satisfy those requirements.

> 2) It should be usable by anyone in any corporation who sells a closed 

Agreed.  Is there any license requirements we can link to regarding
this?  However, if a license meet the requirements of OSD/FSD/DFSG, as
long as it is not copyleft, I believe it will meet the requirements of
all proprietary solutions as well.  Would you agree with that?

Agreed.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Mar 2008 08:01:47 +1300

Simon,

On 2008-03-29 22:10, Simon Josefsson wrote:
...
> this?  However, if a license meet the requirements of OSD/FSD/DFSG, 

I don't believe it is appropriate for an IETF BCP to contain
an open-ended dependency on whatever future requirements three
other organizations might publish. That's why it seems
necessary and sufficient that the BCP sets out the goals.

   Brian

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Mar 2008 11:15:37 +0200

> necessary and sufficient that the BCP sets out the goals.

If the trust uses a software license for code that doesn't meet the
requirements in, say, the DFSG, would you consider that a failure?  If
that happens, Debian cannot include such code.

Using the NPOSL3.0 as the software license, which I read Ray's message
to imply was being considered, would be one way to prevent Debian from
using the code.

I would agree that the references should be for a specific version of
the documents, if that is your point.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Mar 2008 11:25:20 +0200

I'm cc'ing [email-masked] since others may have the same question.

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

> I'll leave it up to others to comment on list, but you did not
> actually answer the question.
> How is it possible to write a license that lets anyone use the code
> any way they want, and modify it any way they want, but not have that
> license permit use in the open source projects you list.

The problem is that the wishes as expressed right now are too sketchy to
provide sufficient information for the trust to produce a good license.

There are examples of projects with good intentions that want to give
everyone the right to use code they publish in any way to end up with
copying conditions that prevent some subset of the community from using
the software.

Look at the mailing list archive of debian-legal.  Most of the software
licenses that are reviewed there have been written by organizations that
wants open source-friendly distribution of their code, but happens to
make one mistake or the other.

If people involved in free software licensing have trouble getting this
right, I have little confidence that people not involved in the free
software licensing will get the right.  Providing them with some
mechanism to test their proposed license against (i.e., the
OSD/FSD/DFSG) will help to avoid at least the most basic mistakes.

Ray asked if there were some reason to not use the NPOSL for this.  I
read that to imply that he thought the license would be a candidate.  If
my proposed text has been part of the documents, we could easily explain
how and why that license doesn't meet a needed criteria.

Thanks,
Simon

>>> I do not understand the problem you want addressed.  The way this
>>> is worded, it doesn't matter what "open source" or "free software"
>>> is or becomes.  The intention is to grant anyone to do anything
>>> with the code segments.  That's what we ask the trust to
>>> do. Further in line.
>>
>>> extracted, modified, and used by ANYONE.  I.e. our grant will not
>>> place restrictions on people.
>>
>> Agreed.
>>
>>> If we grant anyone the right to use the code any way they want,
>>> which means that we specifically can not require preservation of
>>> notices or anything else, how could it fail to meet the
>>> requirements of the specific cases you list?
>>
>>> My concern is not complexity.  Referencing the specific documents
>>> is more restrictive than what the working group recommended.  I
>>> don't see why that would help anything.
>>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 30 Mar 2008 07:21:18 -0500

Hi, Simon,

> to imply was being considered, would be one way to prevent Debian from

OK so far...

> the documents, if that is your point.

OK, I unsubscribed to IPR two or three years ago (or maybe it was two or 
three PR-actions ago, I can't remember which), so maybe I'm really confused, 
but

- I would disagree with referring to a specific version of these documents, 
because tellng the trust "it has to be X-1.0-compatible" will just frustrate 
all of us when there's an X-1.1 version, so then we get to have this 
conversation all over again - or else, we just trust the trust to do the 
right thing (which is what we're discussing now) - or am I misunderstanding?

- please, please, please do not try to craft precise guidance on 
[email-masked]. We can't even get our own process BCPs right. If there is a 
new uber-software license developed thirty minutes after this draft is 
published as an RFC, I bet we would want the trust to look seriously at it, 
and maybe even do the right thing ("and please ignore our guidance if that 
helps you do the right thing").

I don't understand how we can have a trust that we can't trust to do the 
right thing at some level. The draft is pretty clear about our intentions.

Simon has said "there are land mines all over the place". I don't disagree. 
If it helps to add text that says "it's easy to make mistakes; if you make 
mistakes, please fix them as we find them", fine, but if we have to tell the 
trust that, we probably need a smarter trust more than we need specific 
guidance.

IMO.

Spencer

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Mar 2008 08:41:21 -0700

>make one mistake or the other.

These are interesting points, but maybe not interesting in the way 
you intended. If some large group (in this example, the Debian folks) 
want to have some restriction on what they can use in their software, 
that's fine. But that doesn't mean that the IETF needs to do anything 
beyond what it wants to do in order to cater to that group's current 
desires. Every such group could act just like the IETF does: look 
around at what the problems it is facing and change the way it acts 
based on an analysis of the problems.

It is the responsibility of the IETF Trust to consider what its 
actions would be for the whole world. These distributions are 
important. So is CiscoIBMMicrosoftEtc. So is 
TeenyStartupNascentISPEtc.

There will *always* be FOSS groups with different ideas of what their 
requirements are. You listed three in the Linux world. Those of us 
who swim in the BSD world have our own. Every well-intentioned 
organization has their gourd vs. shoe decisions (apologies for the 
Life of Brian reference, but is sure seems appropriate here).

>software licensing will get the right.

Fully agree. And this is an indication that the FOSS folks have equal 
responsibility for the problem you describe.

>Providing them with some

Fully agree. Offer to help the IETF Trust with this; I suspect that 
CiscoIBMMicrosoftEtc will. That's different that forcing a 
requirement into the spec.

>how and why that license doesn't meet a needed criteria.

So could an email to him and the rest of the Trust. Note the difference.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Mar 2008 19:04:40 +0200

> right thing (which is what we're discussing now) - or am I misunderstanding?

Somewhat; the point of referencing these documents, even if the
reference is versioned, is to provide a good sanity test of the license
which is needed.  If the license doesn't meet these requirements, it
won't fulfil what's described in the document already.  Yes, these
references may be revised and be more refined, but the current one would
still be helpful when evaluating potential licenses.

> helps you do the right thing").

Sure, this will be a moving target.  That's why the document doesn't
contain legal text, but just advice on what the legal text should say.

> right thing at some level. The draft is pretty clear about our intentions.

My point is that I don't think the draft is clear.  There is ample
wiggle room and opportunity to go wrong with the current text, and
people have gone wrong before in this area.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Mar 2008 19:30:22 +0200

> based on an analysis of the problems.

We disagree here.  I believe the IETF has a responsibility to chose a
license that works well for a large majority of Internet users.  To some
extents, the IETF needs to cater for organizations that make up parts of
the Internet.

> TeenyStartupNascentISPEtc.

We agree here, but if you believe this, I don't follow your first
paragraph.

> responsibility for the problem you describe.

Definitely.  But that doesn't make the problem smaller.

> CiscoIBMMicrosoftEtc will.

I have sent a note to Ray and Kurtis about offering to help the Trust
chose a suitable software license.

> That's different that forcing a requirement into the spec.

I disagree completely with the notion that the spec doesn't have to be
sufficiently clear to allow the Trust to work out a license on its own.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Mar 2008 11:08:25 -0700

>extents, the IETF needs to cater for organizations that make up parts of

So, then we clearly agree. Where we seem to disagree is whether it is 
possible to demand that the IETF cater to all the organizations that 
you want, or that I want, or <*> wants, or whatever.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 30 Mar 2008 20:20:01 +0200

> you want, or that I want, or <*> wants, or whatever.

Right.  Further, I believe the intention with the documents is to cater
to everyone:

  "grant rights such that code components of IETF contributions can be
  extracted, modified, and used by anyone in any way desired"

The complicated part is HOW that goal is achieved.  It is easy to go
wrong even with the best intentions.

/Simon

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 30 Mar 2008 21:00:11 +0200

Simon Josefsson wrote:
 
> We disagree here.  I believe the IETF has a responsibility to
> chose a license that works well for a large majority of 
> Internet users.  To some extents, the IETF needs to cater for
> organizations that make up parts of the Internet.

Users include authors of RFCs as well as readers.  From the POV 
of somebody who'd wish to contribute to the tools the proposed
NPOSL 3.0 <http://trustee.ietf.org/licenses.html> appears to be
close to CC-BY-SA, therefore I like it (IANAL).

The discussed drafts won't let me put "NPOSL 3.0 code" into an
Internet-Draft, they won't let me put sample code with a "some
rights reserved" proviso into an Internet-Draft.  The rules in
the drafts boil down to CC-BY (= credits required), and making
this worse for the benefit of a debian list would make these
new rules even more harmful for many readers.

RFCs without sample code, if that happens to be "beerware" or
similar, are IMO not "better" just because debian folks can use
the sample code in RFCs as they see fit.  It simply means that
there will be no sample code (e.g. in your B64 standard) at all
in some RFCs under the new rules.

The old rules allowed me to look at say sample code in RFC 4122,
much better than to track it down elsewhere.  The old rules also
allowed me to submit an erratum for one example in this code, 
arguably a wrong example is still better than no example at all.

The freedom to do anything with code in new RFCs somewhat misses
the point, if the price for this freedom is no code in some RFCs
to start with.

 Frank

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 30 Mar 2008 15:11:57 -0400

I am still left with the impression that adding references to specific 
licenses to the draft is going to be confusing, not helpful.
If we started saying "needs to be compatible with license X, Y, and Z" 
then we have at least two problems.  We would have to confirm that X, Y, 
and Z all met our goals.  And we would have to figure out why we should 
point to X, Y, and Z but not Q, W, or any other licenses that may be 
suitable as models.

I have no problem with any individual suggesting to the Trustees that 
specific existing models may be a good way to achieve the stated goal. 
But adding references to example licenses, even if we were sure they 
matched our goals, will not help anyone understand the agreed goals. 
The existing statement is quite clear English.

Yours,
Joel M. Halpern

---

From: Ted Hardie <[email-masked]>
Date: Sun, 30 Mar 2008 17:07:46 -0700

>The existing statement is quite clear English.

I agree with Joel.  We're trying to give instructions to the Trust that
cover the broadest possible user base; calling out specific licenses
or user bases either appears to privilege them or adds no value at
all.  Suggesting to the Trustees that they consider specific licenses
or, even better, pointing their lawyers at the potholes others have
hit would be very useful.  But this draft is not the place to do it.

				Ted

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 30 Mar 2008 20:03:31 -0600

Ted Hardie wrote:
> We're trying to give instructions to the Trust that

And how do we provide suggestions to the Trustees in a formal manner?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 30 Mar 2008 19:11:33 -0800

Hi -

> From: "Peter Saint-Andre" <[email-masked]>
> To: "Ted Hardie" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, March 30, 2008 6:03 PM
...
...

If it's only a suggestion, what's the point of making it formal?

Randy

---

From: David Morris <[email-masked]>
Date: Sun, 30 Mar 2008 18:11:32 -0800 (PST)

I think more important is that the cited intent when this thread was
warming up was that we were asking the Trust to NOT IMPOSE any
restrictions on code examples WHICH WEREN'T already present from
the contributor of the example. ANY license imposed by the Trust
would likley conflict with that intent.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 30 Mar 2008 20:27:33 -0600

> If it's only a suggestion, what's the point of making it formal?

By providing suggestions in a formal way, I mean that I have questions
such as the following...

1. The website http://trustee.ietf.org/ provides no information about
how to communicate with the Trustees, other than listing the email
address [email-masked]. Is that email address intended for communication
with all the Trustees?

2. Are email messages sent to that address acknowledged?

3. How can one be sure that suggestions provided via that email address
are in fact considered by the Trustees?

4. Are the agendas of Trust meetings posted in advance? If so, where,
and how far in advance?

5. How can members of the Internet community provide input regarding
agenda items, in advance of Trust meetings?

Given the fact that the Trust is supposed to meet on the 3rd Wednesday
of each month but that as of today the most recent minutes posted at
http://trustee.ietf.org/minutes.html are from 2007-06-21, I cannot say
that I have much confidence regarding the Trust's commitment to open
communication regarding its activities.

But if answers to the foregoing questions are posted somewhere and I
have missed them, please do point me in the right direction.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 31 Mar 2008 08:14:31 +0200

> incoming rights document applies to the IETF Stream.
That was my interpretation too. I (wearing my WG chair hat) take under 
advisement that this needs to be made clear, possibly with a 4844 reference.

In the terms of pre-4844 terminology, I (wearing my contributor hat) 
always thought of IRTF and IAB streams as subsets of the "non-IETF" stream.
> incoming rights for the IAB stream is also not captured.
I think the IAB will have to make the rules for the IAB stream; a rule 
that says "-incoming and -outgoing applies as appropriate" would be nice 
and short - but it's not within the scope of an IETF WG to make that 
determination.

                        Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 31 Mar 2008 08:16:59 +0200

>       http://www.debian.org/social_contract#guidelines
This has been considered in the WG and rejected, I believe - it was felt 
inappropriate to tie the IETF definitions to other organizations' 
definitions. In particular, it was felt inappropriate to do anything 
that might be interpreted as permitting copyleft requirements to be 
placed on source code from IETF documents.

If the Trust is able to achieve compatibility, I'm all for it.

                    Harlad

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Mar 2008 11:48:24 +0200

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

> and Z all met our goals.

No, that is a misunderstanding.  The IPR documents says that anyone
should be able to use the code.  If the license on code doesn't meet the
requirements in OSD, FSD or DFSG, it fails to comply with that goal.

Please read my original proposed wording again:

  ^^^^^^^^^^^^^^

If the software license used fails to meet those requirements, it will
fail to meet others too, and fail to meet the intended goal.

> And we would have to figure out why we should point to X, Y, and Z but
> not Q, W, or any other licenses that may be suitable as models.

I don't see that.  Note that the references I mentioned aren't licenses
in the first place.  Secondly, I don't see anything exclusive about
listing these.  We can list others as well, if you want.

> The existing statement is quite clear English.

Please read what I proposed, those references aren't licenses.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Mar 2008 11:52:43 +0200

> communication regarding its activities.

I share that concern.  I have requested that minutes should be posted a
couple of times.  There were no minutes posted since December 2005 just
a few weeks ago.  See:

http://thread.gmane.org/gmane.ietf.general/29158

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 31 Mar 2008 11:56:10 +0200

> hit would be very useful.  But this draft is not the place to do it.

I believe the document is the place to do it.  This is the only document
were the IETF explains how the Trust should write its outgoing software
license for code in RFCs.  Useful considerations for that process should
go into the document.

My proposed text does not suggest specific licenses.  That is a
misunderstanding.

/Simon

---

From: Ted Hardie <[email-masked]>
Date: Mon, 31 Mar 2008 08:22:47 -0700

>My proposed text does not suggest specific licenses.  That is a

Simon,
	The list of potentially useful considerations in this arena is both long
and ever-changing.  Imagine, for a moment, that I suggested that the Trust
survey the legal departments of every organization which had sponsored
a nomcom-eligible participant in the IETF over the past 3 years asking, if the proposed
license was usable by their organization.  In some lights, this is a pretty reasonable
suggestion.   These are organizations with a demonstrated interest in our
output, and surveys can be a useful tool even when response rates are low.
Why not confirm that we are meeting the needs of core participants?
	The answer, basically, is that we want the output to be usable by
anyone, and privileging the people who pay kind of misses the point.  We
are giving instructions to the Trust to do the best job they can in making
sure that the output is usable by anyone for any purpose, no matter whether
they belong to group A, group B, or won't know for many years that they'll
have an interest at all.
	As for how to get in touch with them, trustees of the trust are the
IAOC.  The IAOC's membership is listed here:

http://iaoc.ietf.org/members_detail.html

I am sure they will listen carefully to your concerns and will consider the
issues you raise.
			regards,
				Ted
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf