Re: IETF Last Call for two IPR WG Dcouments

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