Re: Flawed license in document...

Ted Hardie <hardie@qualcomm.com> writes:

> At 1:16 AM +0100 2/7/06, Simon Josefsson wrote:
>>It seems draft-eastlake-sha2-02.txt is a document that would have
>>benefited from the ideas discussed in this WG.  The license text that
>>the draft-eastlake-sha2-02.txt authors picked seem to be incompatible
>>with some free software licenses and some proprietary license to me.
>>That is counter to the stated goal that the code should be easily
>>usable by the community.  See my post below.
>>
>>What may be relevant for this WG to consider is the license text used.
>>Reviewing actual wording of licenses used in RFCs helps understanding
>>what rights are missing from the IETF granted permissions.  I'm
>>quoting the license used in draft-eastlake-sha2-02.txt for easy
>>reference.  (The license in RFC 3492 is another example, however it
>>fortunately appear to be compatible with all relevant licenses.)
>
> Simon,
> 	The license given is, as you note below, similar to previous
> BSD licenses in that there is an advertisement clause.  The authors
> made the choice to put their work out in that form, and I think it
> is somewhat rude to assume that they didn't do the work of balancing
> their own interests in producing the document.   Yes, they clearly
> wanted to make this work available for review (and potentially incorporation)
> to the community.  This is also  an individual submission for informational--their
> work, done on their time, for the good of the community.  If they chose
> to require a reference to the work, it's their choice. 

Right, Ted, and I don't dispute that.  I don't intend to be rude, but
I doubted that the authors knew exactly what the license they had
chosen would imply in practice.  The authors are presumably not
lawyers.  The license text they had chosen was in direct conflict with
the explicit goal of providing "open source code".  That support my
doubt.  Their willingness to modify the license also support my doubt.

I believe this is a general problem.  I believe many IETF contributors
want their work to be widely used.  That's why they publish their work
through the IETF rather than on their own company webpage.  Many
working groups rely on free implementations of the protocol to drive
adoption.  Making it easy for free implementations of protocols
further the goals of several working groups.  I believe most authors
would be willing to chose a liberal license if they were aware that
choosing a liberal license will help the open source implementation.
Some areas of the IETF are driven primarily by open source
implementers (think DNS).

I'm not sure educating all IETF contributors, and ask them to include
a specific license, is the most appropriate path forward.  It will
lead to an multitude of licenses in documents.  We already have plenty
of weird licenses around.  Few use widely known licenses.  I guess
that is because people don't consider the license choice as an
important or difficult choice.

Adopting a liberal license for all documents by default would solve
the problem of having a wide range of weird licenses.  People who
don't consider the license issue important or difficult get one that
benefit the masses.

Some people will not like the license.  They would have to pick a more
restrictive license.  I believe the IETF could accept both.  The IETF
could even describe a more restrictive license.  The reasons for
choosing a more restrictive license could be scrutinized when deciding
to move the document forward.  This is the same as for the patent
situation.

> 	The IETF can, of course, choose not to accept the work for RFC
> publication on the grounds an author offers.  At the moment, that's a
> judgement call, based on the review it has received.    I personally hope
> it stays something that allows for variability in the licenses offered.

Same here.  Rejecting something because a liberal license cannot be
acquired seem wasteful.  Sometimes it is not necessary or even useful.

> Going to a one-size fits all system fundamentally ignores the rights
> of the authors, and it has the pretty idealistic presumption that
> people will continue doing the work if we dictate whatever terms we
> like.  To be honest, you seem to me to be in this message once again
> pushing GPL-compatibility as a litmus test for acceptable terms to
> offer to the IETF.  I personally don't think one size is going to
> fit all, and I'm strongly opposed to using the GPL as that size if
> the working group decides to go with baseline rights.  The sizing on
> that particular Procrustean bed will lop off things I think we need.

I understand that not all documents can be published under a license
that is compatible with a wide range licenses.

I'm thinking as much of Microsoft/Apple/Sun EULA's as the GPL here.
These companies appear to have the same problem as I do with license
compatibility.  Sun even incorporated part of an RFC despite the
license problem.

It is not GPL-compatibility that I believe should be a litmus test, it
is compatibility with a large set of licenses used to implement IETF
protocols.  If the IETF wishes to serve its community, I believe the
license chosen should make it easier for that community to implement
the documents.  The IETF license should not work against the goals of
the community.

If the IETF publishes reference code, API documentation, ASN.1
schemas, header files, etc, I strongly believe that material should be
compatible with a wide range of licenses.  Trying to separate code and
text is a distraction, and we have not made much progress on this
path.  The simplest seem to make all of the document available under
an all-compatible license.  This will also solve the problem that
Debian, FreeBSD and Sun had with regard to the license on the _text_
of RFCs.  Their concerns weren't with code-like portions.

Regards,
Simon

_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg