Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

Thanks Ray, that is reassuring.

I don't think this decreases the need for the -outbound document to be
as clear as possible about what the IETF needs are, though.

/Simon

Ray Pelletier [EMAIL PROTECTED] writes:

 In their April 3, 2008 meeting, the IETF Trustees discussed the
 outbound-IPR document, and found no issues with the advice given in
 the document. 

 More specifically, the Trustees intend to invite comments
 from the community, via the ietf discussion list, prior to issuing any
 new licenses.  The comment period(s) will begin as soon as proposed text
 for licenses have been drafted or selected. 

 The Trustees will not make any final decisions on licenses stemming
 from the
 outbound-IPR document until after taking the communities' feedback
 into account.

 For the Trustees,
 Ray Pelletier
 Trustee

 Ted Hardie wrote:

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.
  

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,
  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
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


  

 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Ray Pelletier]

In their April 3, 2008 meeting, the IETF Trustees discussed the
outbound-IPR document, and found no issues with the advice given in
the document. 


More specifically, the Trustees intend to invite comments
from the community, via the ietf discussion list, prior to issuing any
new licenses.  The comment period(s) will begin as soon as proposed text
for licenses have been drafted or selected. 

The Trustees will not make any final decisions on licenses stemming from 
the
outbound-IPR document until after taking the communities' feedback into 
account.


For the Trustees,
Ray Pelletier
Trustee

Ted Hardie wrote:


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.
 


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,
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
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


 

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Olaf Kolkman]

Colleagues,

The IAB discussed the IPR documents during its most recent call. It  
unanimously decided that the IAB-stream is to be covered by the  
incoming IPR document.  It is our understanding that the iab-stream  
documents IPR are then automatically covered by the outbounds rights  
that the IETF trust will establish based on the advice in draft-ietf- 
ipr-outbound rights.


We also want to stress that for any change in the inbound rights for  
streams other than the ietf- and iab-stream there needs to be a stream  
dependent discussion and approval process as indicated in RFC 4844  
The RFC Series and RFC Editor  section 4.2.3.


To that extent section 4 of the draft should explicitly mention that  
the irtf-, the independent- and any possible future streams are not  
covered by the draft.


For the IAB,

Olaf Kolkman


PGP.sig
Description: This is a digitally signed message part
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Harald Tveit Alvestrand]

Olaf Kolkman skrev:


 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.
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.

 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.
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

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Harald Tveit Alvestrand]

Simon Josefsson skrev:
 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
   
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

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

Joel M. Halpern [EMAIL PROTECTED] writes:

 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.

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:

  To make sure the granted rights are usable in practice, they need to
  at least meet the requirements of the Open Source Definition [OSD],
  ^^

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.

 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.

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

/Simon

 Yours,
 Joel M. Halpern

 Simon Josefsson wrote:
 Paul Hoffman [EMAIL PROTECTED] writes:
 
 At 7:30 PM +0200 3/30/08, Simon Josefsson wrote:
 Paul Hoffman [EMAIL PROTECTED] writes:
   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.
 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.
 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.
 
 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
 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

Peter Saint-Andre [EMAIL PROTECTED] writes:

 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.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

Ted Hardie [EMAIL PROTECTED] writes:

 At 12:11 PM -0700 3/30/08, Joel M. Halpern wrote:
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

 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.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Ted Hardie]

  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.

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,
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
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

I'm cc'ing ietf@ietf.org since others may have the same question.

Joel M. Halpern [EMAIL PROTECTED] 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

 Yours,
 Joel

 Simon Josefsson wrote:
 Joel M. Halpern [EMAIL PROTECTED] writes:

 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.

 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.

 Simon Josefsson wrote:
 Regarding -outbound section 4.3:

 ...
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.
 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.

 Agreed.

 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.
 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?

 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.

 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 

Re: IETF Last Call for two IPR WG Dcouments

[Spencer Dawkins]

Hi, Simon,

 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.

OK so far...

 I would agree that the references should be for a specific version of
 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 PROTECTED] 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 


___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Paul Hoffman]

At 11:15 AM +0200 3/30/08, Simon Josefsson wrote:
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.

At 11:25 AM +0200 3/30/08, Simon Josefsson wrote:
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.

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).

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.

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

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.

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.

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.

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

--Paul Hoffman, Director
--VPN Consortium
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Paul Hoffman]

At 7:30 PM +0200 3/30/08, Simon Josefsson wrote:
Paul Hoffman [EMAIL PROTECTED] writes:
   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.

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.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Frank Ellermann]

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

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Joel M. Halpern]

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

Simon Josefsson wrote:
 Paul Hoffman [EMAIL PROTECTED] writes:
 
 At 7:30 PM +0200 3/30/08, Simon Josefsson wrote:
 Paul Hoffman [EMAIL PROTECTED] writes:
   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.
 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.
 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.
 
 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
 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Ted Hardie]

At 12:11 PM -0700 3/30/08, Joel M. Halpern wrote:
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

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Ted Hardie wrote:
 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.

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

Peter

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Randy Presuhn]

Hi -

 From: Peter Saint-Andre [EMAIL PROTECTED]
 To: Ted Hardie [EMAIL PROTECTED]
 Cc: ietf@ietf.org
 Sent: Sunday, March 30, 2008 6:03 PM
 Subject: Re: IETF Last Call for two IPR WG Dcouments
...
 And how do we provide suggestions to the Trustees in a formal manner?
...

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

Randy

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[David Morris]

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.



On Sun, 30 Mar 2008, Ted Hardie wrote:

 At 12:11 PM -0700 3/30/08, Joel M. Halpern wrote:
 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

 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.
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Randy Presuhn wrote:
 Hi -
 
 From: Peter Saint-Andre [EMAIL PROTECTED]
 To: Ted Hardie [EMAIL PROTECTED]
 Cc: ietf@ietf.org
 Sent: Sunday, March 30, 2008 6:03 PM
 Subject: Re: IETF Last Call for two IPR WG Dcouments
 ...
 And how do we provide suggestions to the Trustees in a formal manner?
 ...
 
 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 PROTECTED] 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/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

Wes Beebee (wbeebee) [EMAIL PROTECTED] writes:

 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).

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 
source product.

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?

 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.

Agreed.

/Simon

 - Wes

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


 Ray Pelletier wrote:
 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?


 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

 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Olaf Kolkman]

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

While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
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
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.



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:

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

On 2008-03-28 08:15, Leslie Daigle wrote:


--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman  
[EMAIL PROTECTED]

wrote:
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 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.



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)






___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf




PGP.sig
Description: This is a digitally signed message part
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

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

Russ Housley [EMAIL PROTECTED] writes:

 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 PROTECTED]
 From: The IESG [EMAIL PROTECTED]
 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 PROTECTED]

 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
 ietf@ietf.org mailing lists by 2008-04-02. Exceptionally,
 comments may be sent to [EMAIL PROTECTED] 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
 

RE: IETF Last Call for two IPR WG Dcouments

[Lawrence Rosen]

Simon Josefsson wrote:
 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].

+1

/Larry




 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
 Simon Josefsson
 Sent: Friday, March 28, 2008 3:02 AM
 To: Russ Housley
 Cc: ietf@ietf.org
 Subject: Re: IETF Last Call for two IPR WG Dcouments
 
 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
 
 Russ Housley [EMAIL PROTECTED] writes:
 
  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 PROTECTED]
  From: The IESG [EMAIL PROTECTED]
  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 PROTECTED]
 
  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

Re: IETF Last Call for two IPR WG Dcouments

[Scott O. Bradner]

 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.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Joel M. Halpern]

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.

Simon Josefsson wrote:
 Regarding -outbound section 4.3:
 
...
 
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.
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.

 ...
 
 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.
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?

 
 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.
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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

Joel M. Halpern [EMAIL PROTECTED] writes:

 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.

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.

 Simon Josefsson wrote:
 Regarding -outbound section 4.3:
 
 ...
 
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.
 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.

Agreed.

 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.
 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?

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.

 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.
 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.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Ted Hardie]

At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
Joel M. Halpern [EMAIL PROTECTED] writes:

 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.

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.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Joel M. Halpern wrote:
 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.

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

 Simon Josefsson wrote:
 Regarding -outbound section 4.3:

 ...
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.
 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.

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.).

 ...

 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.
 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?

Because it is not covered by a license.

 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.
 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.

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/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Ray Pelletier]

Peter Saint-Andre wrote:


Joel M. Halpern wrote:
 

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.
   



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
 

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

 


Simon Josefsson wrote:
   


Regarding -outbound section 4.3:

 


...
   


  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.
 

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.
   



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.).

 


...

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.
 

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?
   



Because it is not covered by a license.

 


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.
 

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.
   



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

Peter

 




___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
 

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Margaret Wasserman]

Ray Pelletier wrote:
 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?


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

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[SM]

At 03:01 28-03-2008, Simon Josefsson wrote:
Regarding -outbound section 4.3:


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.

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.

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].

These are not guidelines; they are requirements.

Regards,
-sm


___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Ray Pelletier wrote:
 
 Peter Saint-Andre wrote:
 
 Joel M. Halpern wrote:
  

 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.
   

 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
  

 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?

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/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

SM wrote:
 At 03:01 28-03-2008, Simon Josefsson wrote:

 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].
 
 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 PROTECTED].

Peter

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF Last Call for two IPR WG Dcouments

[Wes Beebee (wbeebee)]

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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Margaret Wasserman
Sent: Friday, March 28, 2008 2:30 PM
To: Ray Pelletier
Cc: Simon Josefsson; Joel M. Halpern; ietf@ietf.org
Subject: Re: IETF Last Call for two IPR WG Dcouments


Ray Pelletier wrote:
 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?


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

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Ray Pelletier wrote:

 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

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 

RE: IETF Last Call for two IPR WG Dcouments

[michael.dillon]

 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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

+1. I couldn't express it better.

   Brian

On 2008-03-29 04:54, Ted Hardie wrote:
 At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
 Joel M. Halpern [EMAIL PROTECTED] writes:

 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.
 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.
 
 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
 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

On 2008-03-28 20:14, Olaf Kolkman wrote:
 
 On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
 While not really disagreeing with Leslie and Olaf, I would
 point out that the IPR WG was chartered to look at
 IETF documents.
 
 Those being ietf-stream exclusively or implicitly also covering the
 iab-stream?

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.

 
 Personally, I think it makes sense that the iab-stream is covered, but
 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.

 
 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.
 
 
 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.

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
 irtf stream.

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

Brian
 
 no-hats,
 
 --Olaf
 
 
 no further comments below
 
 On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
 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

 On 2008-03-28 08:15, Leslie Daigle wrote:

 --On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman [EMAIL PROTECTED]
 wrote:
 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 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.


 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)





 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Henrik Levkowetz]

On 2008-03-28 18:49 Ray Pelletier said the following:

 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?

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Olaf Kolkman]

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)



PGP.sig
Description: This is a digitally signed message part
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Leslie Daigle]

--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman [EMAIL PROTECTED] 
wrote:
 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 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.



 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)





___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

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

On 2008-03-28 08:15, Leslie Daigle wrote:
 
 --On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman [EMAIL PROTECTED] 
 wrote:
 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 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.
 

 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)

 
 
 
 
 ___
 IETF mailing list
 IETF@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Harald Tveit Alvestrand]

--On Tuesday, March 25, 2008 21:30:54 -0600 Peter Saint-Andre 
[EMAIL PROTECTED] wrote:

 Russ Housley wrote:
 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.

 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?

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.

 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?).

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.

 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 

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Harald Tveit Alvestrand wrote:
 
 
 --On Tuesday, March 25, 2008 21:30:54 -0600 Peter Saint-Andre
 [EMAIL PROTECTED] wrote:
 
 Russ Housley wrote:
 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.

 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?
 
 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.
 
 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?).
 
 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.

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

 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 

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

On 2008-03-27 09:14, Peter Saint-Andre wrote:
 Harald Tveit Alvestrand wrote:

 --On Tuesday, March 25, 2008 21:30:54 -0600 Peter Saint-Andre
 [EMAIL PROTECTED] wrote:

snip

 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.
 No, it does not. I'd like someone from the Trust to speak up about their
 thoughts about suitable review processes.
 
 Yes, that would be appreciated.
 
 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.
 
 That seems sensible.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Sam Hartman]

 Brian == Brian E Carpenter [EMAIL PROTECTED] 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.

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Russ Housley wrote:
 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.

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/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

On 2008-03-25 08:52, Russ Housley wrote:
 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.

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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Joel M. Halpern]

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

Peter Saint-Andre wrote:
 Russ Housley wrote:
 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.
 
 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?

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.

 
 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.

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.

 
 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?).
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.

 
 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.

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