Subject: Flawed license in document...

From: Simon Josefsson <[email-masked]>
Date: Tue, 07 Feb 2006 01:16:20 +0100

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

Btw, any progress on the IPR WG charter update?

1.1 License

   Royalty free license to copy and use this software is granted
   provided that this document is identified in all material mentioning
   or referencing this software. Royalty free license is also granted to
   make and use derivative works provided that such works are identified
   as derived from this work.

   The authors make no representations concerning either the
   merchantability of this software or the suitability of this software
   for any particular purpose. It is provided "as is" without express or
   implied warranty of any kind.

Regards,
Simon

From: Simon Josefsson <[email-masked]>
Subject: Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)'
	to Informational RFC
Newsgroups: gmane.ietf.general
Date: Tue, 07 Feb 2006 00:11:33 +0100

The IESG <[email-masked]> writes:

> Note to the RFC Editor
>
>   To resolve the concerns with the term "open source", please make the
>   following changes:
>
>   In the Abstract:
>
>     OLD:
>
>       The purpose of this document is to make open source code
>       performing these hash functions conveniently available to
>       the Internet community.
>
>     NEW:
>
>       The purpose of this document is to make source code
>       performing these hash functions conveniently available to
>       the Internet community.
>
>   In Section 10:
>
>     OLD:
>
>       This document is intended to provide convenient open source
>       access by the Internet community to the United States of
>       America Federal Information Processing Standard Secure Hash
>       Algorithms (SHAs) [FIPS 180-2] and HMACs based thereon.
>
>     NEW:
>
>       This document provides the Internet community convenient
>       access to source code that implements the United States of
>       America Federal Information Processing Standard Secure Hash
>       Algorithms (SHAs) [FIPS 180-2] and HMACs based upon these
>       one-way hash functions.  See license in Section 1.1.

The license in section 1.1 reads:

   Royalty free license to copy and use this software is granted
   provided that this document is identified in all material
   mentioning or referencing this software.

I believe this part of the license is incompatible with some licenses
used to implement IETF protocols.  It has the same problem as the
advertisement clause in the old BSD license.  It is thus questionable
whether the document achieve its stated goal.

Btw:

> The IESG has approved the following document:
>
> - 'US Secure Hash Algorithms (SHA and HMAC-SHA) '
>    <draft-eastlake-sha2-02.txt> as an Informational RFC
>
> This document has been reviewed in the IETF but is not the product of an
> IETF Working Group.

Was there a last call for this document?  I do not recall seeing it.

Thanks,
Simon

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

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Feb 2006 17:10:17 -0800

>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. 
	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. 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 am not speaking for my employer or the IESG.
			regards,
				Ted Hardie

---

From: Don Armstrong <[email-masked]>
Date: Mon, 6 Feb 2006 17:47:23 -0800

On Mon, 06 Feb 2006, Ted Hardie wrote:
> pushing GPL-compatibility as a litmus test for acceptable terms to
> offer to the IETF.

The issue really isn't just GPL compatibility, it's compatibility with
the largest range of licenses possible to promote the reuse of
standardized implementations wherever possible. The GPL is merely one
of a range of licenses which cover works in which IETF standards are
implemented.

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

A maximally permissive license will clearly fit all usage cases; the
only issue is whether such a license will be something that people
contributing to an IETF standards process will accept.

If it's not, then we have to step back and balance the need for
contributors with the need for standards that can be widely deployed.

[There seems to be some confusion here about the GPL: we're (or at
least I am) not asking for IETF standards to be licensed under the
GPL, merely for it to be licensed in a manner which enables it to be
used in the widest range of works, of which a GPLed work is one part
of that set.]

Don Armstrong

-- 
Debian's not really about the users or the software at all. It's a
large flame-generating engine that the cabal uses to heat their coffee
 -- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500)

http://www.donarmstrong.com              http://rzlab.ucr.edu
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Feb 2006 03:07:55 +0100

Simon Josefsson wrote:

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

Maybe they couldn't copy the license for the same "software" in
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

| Exports of cryptographic modules implementing this standard
| and technical data regarding them must comply with these
| Federal regulations and be licensed by the Bureau of Export
| Administration of the U.S. Department of Commerce.

In other words RfCs mandating SHA are dubious, no big surprise.

| Implementations of the secure hash standard is this standard
| may be covered by U.S. or foreign patents.

Let's hope that they'll find the IETF page for IPR submissions.

| Only algorithm implementations that are validated by NIST
| will be considered as complying with this standard.
| Information about the planned validation program can be
| obtained at http://csrc.nist.gov/cryptval/
[...]

Several accredited labs for conformance testing.  Cost recovery
fee for NIST to check the conformance test results, and then to
publish the validated algorithm.

It's only an informational RfC, and it's nice to have this info
in plain text format.  Maybe the authors should have copied the
"legalese" from their source instead of using another text (?)

                             Bye, Frank

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Feb 2006 21:00:06 -0800

>contributing to an IETF standards process will accept.

A maximally permissive license would not be viral; it would allow
someone to do whatever they wanted without reference to the onward
license they grant on their work.    I'm not, personally, convinced
that there is anyway to pre-judge a "maximally permissive license"
without at least some statement about what axes will be used for
measurement.

But the main point is that the authors have a role in deciding what they
contribute, and if we don't give them reasonable choices in the matter,
they will decide not to contribute at all.    Section 5.2 of 3978 already
covers some aspect of this ground, and I hope that we continue
to recognize that author's rights that affect the fit of  declarations
they make to the IETF and the readers of their contributions.
			regards,
				Ted Hardie.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 08 Feb 2006 11:28:30 +0100

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

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Feb 2006 11:33:42 -0800

At 11:28 AM +0100 2/8/06, Simon Josefsson wrote:
>lawyers. 

I know them both, and I am happy to report that they are very productive
engineers.  They presumably have access to lawyers, should
they feel they need them.

>The license text they had chosen was in direct conflict with

It is not in direct conflict with the explicit goal of providing open
source code.  The document provides example source code for examination and
potentially for incorporation under a license that many, many
people and organizations would find appropriate.  It does not do
so for all licenses.

I am not a lawyer either, but I don't believe Tony's proposed change:

   Royalty free license to copy and use this software is granted,
   provided that redistributed derivative works do not contain
   misleading author or version information.

carries the same meaning as the original, as it does not require the
derivative works to carry the same restriction.  Since a copy-of-a-copy
is pretty easy to arrange, without that you are at full freedom
to remove this restriction in one generation.  And it is the imposition
of this restriction which would run you into problems with the advertisment
clause's conflict with the GPL.

Whether Tony and Don choose to lose that in a single generation or not,
we have to expect that some contributors to the IETF would want the
restriction to be inherited.  Otherwise we are back at the "fork" problem
very, very quickly.
			Ted

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 08 Feb 2006 21:10:52 +0100

> people and organizations would find appropriate.  It does not do

Given that the original license in the document is a new license, that
has never been used before -- please correct me if I'm wrong on this,
I simply did not recognize it -- I don't think it is possible to claim
that many organizations would have found it acceptable.

It takes time to vet a license for these purposes.  Even a slight
change in wording may change the meaning of the license significantly.

It is close to impossible to have companies make official statements
on which licenses they find appropriate or not.

To me, few companies seem to make informed legal decisions on these
matters.  Rather they seem to follow what others are doing, and what
appear to be acceptable behavior.  This is how I believe RFC material
ended up in Sun Solaris, FreeBSD, Debian, and numerous other open
source products, despite the IETF license forbidding that.  It is
simply what everyone does, and has been considered accepted behavior.
If everyone does something, reading the license to see if it is
permitted isn't the first thing that comes to mind.

(Don't get me wrong, I'm not rationalizing the act of ignoring
licenses.  Licenses are important and must be followed.  I'm merely
trying to explain how I think things have happened.)

> to remove this restriction in one generation.

The difference is significant, and I believe it was intentional, to
avoid using an "advertisement clause".

> restriction to be inherited.

Sorry to keep harping on this, but their reasons being?  Do we believe
the reasons are valid?

I have see two reasons presented so far.

The first, that opening up derivative works lead to fake RFCs.  That
can be mitigated, I believe to the point where this is no longer a
serious issue.

The second was John Klensin who considered the documents he wrote his
property, and that the IETF should get as few rights as possible,
IIRC.  I cannot reconcile his view with the need for the IETF and the
community at large to make useful use of a document.  It is not useful
to publish ASN.1 schemas if third parties are not granted rights to
them.

One analogy on losing contributors.  I'm pretty sure some past members
of the IETF has tried to make the IETF standardize patented
technology.  Often patents that the company, incidentally, owned.
(Sometimes they have even succeeded.)  While the IETF still can chose
to publish patent encumbered technology, the IETF is no longer a
useful venue to push patented technology.  The barriers on what you
need to do to convince IETF to publish patented technology are too
high in most cases.  I believe this was for the greater good of the
Internet.  An Internet with too much patented technology ceases to be
open for everyone.  This is one lesson the IETF has learned over the
past ten years.

I believe a similar situation may arise for copyrights too.  We see
relatively few documents published with the restrictive license
described in RFC 3978 section 5.2.  I'm not certain of the reasons,
but my guess is that documents published with those restrictions are
less useful to the IETF community.  Authors will likely have to
carefully explain why they need such restrictive language before their
documents is published.

I believe we should have a liberal license for documents by default,
but still accept documents with other licenses.  Over time we will
recognize valid reasons for picking a more restrictive license.

Regards,
Simon

---

From: "todd glassey" <[email-masked]>
Date: Wed, 8 Feb 2006 12:49:53 -0800

Ted
please dont take this retort personally - I respect your work and that of
the IETF as a whole but you in a single phrase has illuminated the entire
problem with the IPR-WG - that being "should they feel they feel they need
them" - which underlines the pure arrogance of this management team. It has
decided that it and it alone will make decisions of law and process and that
is ridiculous.

This WG needs real professional legal help that is paid specifically to
develop a set of licenses to accomplish this need and to do so within the
framework that the IETF operates by, or to formally tell this IETF WG and
its chair that the type of thing it wants to accomplish, is not possible
with the current framework which is more the reality that no one wants to
face I bet...

If you doubt me Ted, call the GC's office at QualComm and ask them what they
do in for form of IP releases and diligence on acquiring a new technology.
If your paying sponsor wont use the system the IETF's erecting then what do
you think this says?

Simple key questions -

    0) What does your sponsor do when they acquire IP? - and if it is
OpenSource'd are there other things they do like buy paid copies? - the
problem between real-world IP transfers and those that happen through the
anonymous posting instance of the IETF is that all the parties know each
other or the matter is handled through some formal intermediary that IS
ACCOUNTABLE for all the issues of the IP RIGHTS and that.

Hell Real-Estate has been sold like this for hundreds of years - ever hear
of a title search? Nothing the IETF does is like any other IP process, and
unlike the OpenSource community there is not the ongoing relationship
between the developers and the users of the technology here, so the IETF
cannot claim to be anything like an OpenSource distributor of commercial
technologies. It is a 'dealer in IP from unknown origins and of unknown
rights' no matter what some stupid Email Form says.

    1) Would ANY of the lawyers who populate this list EVER write a IP
transfer contract like the IETF's - My bet is professionally speaking that
while Larry, Mssr Barr, and Counsel Jorge have specific goals here, and that
through those goals, not one of them is silly enough to risk their
credential or their firms name on a 'commercial-IP assignment or conveyance'
process that is as flimsy as this one - or as poorly put together...

    2) If those lawyers wont formally come out and state for the record that
the IETF's processes are stable and legally defensible if there is an IP
issue, then why are we continuing to proceed down this rathole? Again this
feeds back to the commentary "if they feel they need them"...

This previous question's answer alone should have stopped this process dead
in its tracks... but since we as Engineer's know better - lets continue
asking the simple questions as to how our sponsor's do business today.

------------

    3) In any process or reasonable use license, there is a damages or
liquidated damages clause, and no such clause appears in any IETF document -
they all claim Use At Your Own Risk, but I got news for this group, the
failure of the IETF to properly identify a submitter is likely 'really going
to annoy' the property's real owner and as such, there may be a tie-in now
in the US to the Bush Amendment's to the Violence Against Women/DOJ
recharging act that went into US law - this is why an IP attorney needs to
look at the entire process now.

    4) In ALL instances the IETF MUST maintain control on the IP submitted
to it, so that getting a court order prohibiting the use of the materials is
not necessary against the Officers and Operating Management of the IETF
itself. This is a purely stupid and arrogant oversight that the IETF has
been hiding behind  for years - but its time it came out of the closet and
claimed to be what it is, the Publisher's of the IP submitted through the
IETF's Editors... Either way if there is a problem with a proper conveyance
IT MUST be capable of being recalled or terminated. Otherwise the ONLY
POSSIBLE SOLUTION is litigation for injunctive relief and the associated
damages against the IETF and its officers -

Todd Glassey, Frustrated participant.