(Re: IETF and open source license compatibility)

[Scott Kitterman <[e-mail]>]

On Fri, 13 Feb 2009 12:57:02 +0100 Simon Josefsson <[e-mail]> 
wrote:
>Harald Alvestrand <[e-mail]> writes:
>
>>> This seems more or less correct, even though it may sound surprising at
>>> first.  More generally, and more clearly expressed, it can be stated as
>>> this: The license for a piece of work applies to the piece of work, it
>>> does not apply to the license itself.  The license of a work is not
>>> normally not considered part of the work; it is metadata about the work.
>>>   
>> But (and the reason why this is important, and IETF-relevant) how is
>> this case different from the case where you introduce pieces of an RFC
>> (which also don't need to be considered part of the work) as comments
>> into a work?
>
>The only way I can see to avoid having the comment be part of the work
>is to use different licenses for the code and the comment.  (Do you see
>any other way?)
>
>That is possible, but leads to problems.
>
>The result is a complex license on the combined work.  The combined
>license says essentially something like "License A applies to portion X
>and the IETF Trust License applies to portion Y".  That combined license
>may not be compatible with other licenses, both free and non-free
>licenses.
>
>For example, the combined license would not be compatible with the GPL
>because modifications of the entire work is not permitted.
>
>I believe it is possible to find proprietary licenses that have other
>clauses that render the license incompatible with the IETF Trust
>license.  So the problem is wider than just free software licenses.  I
>believe the IETF needs to realize that GPL software runs part of the
>Internet and that catering to these licensing needs is as important as
>catering to the licensing needs of, say, Microsoft.
>
>The license compatibility question is more relevant for free software
>because people are more conservative in evaluating software licenses in
>the free software community compared to the enterprise setting where
>licenses are typically only ever evaluated when someone sues or is sued
>by someone.
>
>My point has been that triggering this situation works counter to the
>goal of the IETF.  In a strict setting, it means implementers cannot use
>verbatim text from RFCs, but needs to rewrite the text to avoid re-use
>of material under the IETF Trust license.  I believe that opens up for
>interoperability problems (when a re-written comment is subtly different
>from the original meaning, and the comment influences code).  If people
>decide that this rewriting needs to happen to avoid contamination from
>the IETF Trust license, it would also delay getting IETF protocols
>deployed.
>
>This has been my rationale for suggesting that IETF documents should be
>licensed under a free software compatible license.  I am aware that
>battle is already lost, so I have mixed feelings about discussing this
>further.  However if others bring up related topics I feel a need to
>respond.  My hope is that it is possible to alter the policies in the
>future.  Fortunately, I believe the new BCP 78 has created good ground
>to make that possible.
>
>Generally, however, I think this question is very different from where
>this thread started.  It started, as far as I consider, with Stephan
>suggesting that free software authors publish "free" (as in licensed
>under a free software license) standards in the IETF.  That is not
>possible, and is unrelated to the question we discuss here.  I'm happy
>to discuss both questions, but I'm concerned that you and others may
>believe that you dispute my first claim by discussing this separate
>issue.
>
>> With the GPL text, you don't have the copyright, and you don't have a
>> license that permits modified versions. But you do have the right to
>> copy it.
>>
>> With the excerpt from an RFC, you don't have the copyright, and you
>> don't have a license that permits modified versions. But you do have
>> the right to copy it - you even have the right to copy pieces of it.
>>
>> Why are you insisting that the first is perfectly reasonable, and the
>> second is a show-stopper?
>
>I'm not saying the second is a show stopper.  The Internet appears to
>work relatively well on most days.  However, I insist that it is a
>potential impediment and that it works counter to the goals of the IETF.
>

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

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

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

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

Removing comments is a form of obfuscation.

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

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

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

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

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

Scott K

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