Subject: Sample code (was: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc)

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 1 Dec 2007 18:27:48 +0100

Harald Alvestrand wrote:

> I think the WG has concluded that it's unacceptable to publish source 
> code in an RFC that, if copied from the RFC and modified by a reader, 
> would place a GPL (or any other copyright-based) requirement on that
> reader.

Sounds familiar...
 
> And I think that's a sensible conclusion to come to.

...but the outcome is horrible, as explained by Simon.  It's possible
to use sample code for educational purposes, and then create your own
version, if that's an issue.  In the case of APR1 (some MD5 password
madness) the "beerware" license is actually live-threatening for the
original author, therefore I didn't copy it to a REXX MD5 test suite.

And I checked it with three other implementations (because I couldn't
believe it).  I'd add credits in an Internet Draft, but I'd likely
add my own code as sample, without mentioning the "beerware" license.

[ Don't panic, the SASL WG is supposed to propose a better mechanism,
 if they end up with documenting APR1 something went seriously wrong ]

Likewise the sample code in the lottery RFC (NOMCOM) is essential to
"deploy" it at all.  Simon's B64 RFC really needed sample code, the
valid test vectors are nice, but sometimes folks create "truncated"
(at first glance ambiguous) B64 encodings, and implementors might
have a hard time to reverse engineer a better fallback than "throw
error and give up".  IIRC two of three serious bugs in the mentioned
MD5 test suite were B64 issues :-(  

 Frank

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Dec 2007 07:57:47 +1300

On 2007-12-02 06:27, Frank Ellermann wrote:
> ...but the outcome is horrible, 

It doesn't have to be. If the author of the code contributes
it directly to the IETF process, quite independently of any
contribution of the same code made under any other license,
the IETF's needs are met. The outcome is horrible if someone
who is not the original author lifts code from (e.g.) a GPL
source and embeds it in an IETF document.

     Brian

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 1 Dec 2007 12:19:17 -0800

Come on guys  - this seems like it is real simple... and unpleasant. You 
want inclusions to be controlled under the same copyright that the 
submitters assert to, and
there is NO way to do that without a separate set of releases against that 
code...  http://www.copyright.gov/circs/circ1.html

There are both 107 and 108 problems with the IETF's submission and 
conveyance process with regard to 'controlled IP's being included in IETF 
works' under the 107 Exemption. This by the way also blows NoteWell out of 
the water since NO POSSIBLE conveyance to Joe Blow's IP can be had by the 
IETF by my posting a note to a list talking about it or describing the 
technological details of Joe Blow's system.

That said... the section 107 and 108 copyright exemptions/controls are 
pretty clear and research exemptions are limited to entities who are formal 
research institutions. Entities' which are commercial in nature would not 
qualify if they were performing efforts to further the sales of their own 
products too one would think. More inline...

Section 107 stuff
-------------------
Section 107 of the Copyright code allows a Researcher actively "involved in 
Research" to produce a work which may include other previously copyrighted 
works about patent protected technologies (or technologies for which a 
patent could be filed against owned by another party). The problem is that 
this Researcher CANNOT convey any further or other rights including the 
ability to republish that IP ass far ass I can tell without specific and 
particular releases. What this means is that without a formal IP 
republication release from the ***original IP owners*** the IP embedded in 
the submission controlled under the original IP controls cannot be released 
for either further research publication or for any derivative purposes 
either.  http://www.copyright.gov/title17/92chap1.html#107

And of course, the problem is with NO DERIVATIVE works release the Research 
exemption little more than the discussion about an IP could occur.  There is 
another issue in that many of the people producing these works do so for 
commercial entities as their sponsors and so that is in fact an effort to 
commercially sidestep US Copyright law IMHO. 
http://www.copyright.gov/fls/fl102.html

Especially this is true here in the IETF since it is designed to enable
global commerce on the Internet. That makes the republication of these works
an issue too. This is a SDO for people to build protocols so that global
commerce and communication can occur so that means that ANY derivatives of
this work product are tainted by the fact that the 107 Exemption doesn't
grant any derivative rights against that IP.

Section 107 and the Trust
-----------------------------
The next step is more painful, in that when the IETF transfers the IP to any 
other entity, it loses that exemption and in as much companies like Debian, 
Sun and others may in fact owe a whole lot of money to the original IP 
Owners. The key issue is that any Section 107 exemptions covering the 
republication for research purposes would probably also terminate the 
instant that the IETF transfers the IP to home other entity, like the Trust 
for instance.

Section 108
-------------
Irrelevant of the IETF's statements on Copyrights moving forward it is also
important to review the rights granted for research publications under the
Libraries and Archives rights section of the US Copyright act since I think
it means that the IETF needs to formally control the number of copies of its 
work's in print per archive under section 108 of the copyright code. 
http://www.copyright.gov/title17/92chap1.html#108

Since this law also requires that there be no more than three copies 
floating around, the IETF's process must also somehow address that copies of 
IETF documents, once downloaded cannot ever be recovered.

That probably means that an Archive gets shut down after is provides its 
third copy of a document to ANYONE... which would be a real problem since it 
doesn't happen. I mean of course only if its true, but if it is it creates a 
severe liability for a number of very large companies for their actions in 
copyright violations.

The only fix I can see for this is a formal release process that allows the 
IETF to get formal releases against included IP as well as the rest of the 
submission.

Todd Glassey

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 01, 2007 10:57 AM
Subject: Re: Sample code

> the IETF's needs are met.

Todd

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 2 Dec 2007 02:47:35 +0100

Brian E Carpenter wrote:
  
> The outcome is horrible if someone who is not the original
> author lifts code from (e.g.) a GPL source and embeds it
> in an IETF document.

Okay, since I read a GCC manual (about 15 years ago (?)) and
found that it's excessively different from any C compiler
I ever used, and also from my nice K&R 2nd ed. ANSI C I was
not only a bit annoyed, the worst case of "embrace, extend,
and extinguish" I've ever seen long before the usual suspects
who invent everything invented EEE.

I even had a script removing those [censored] GNU licenses
from all archives on my local hard disks at this time, minus
a few directories mentioned in a BBS configuration file.

On the other hand, what could happen if somebody really does
this.  He's supposed to add credits in an RFC, let's assume
he got that right.  A draft incorporating the complete text
of those licenses wouldn't pass a giggle test, let's assume
it contains the following text (in a comment section of some
kind of "code"): 

| Copyright (c) 1998-2002 W3C (MIT, INRIA, Keio) for the original DTD.
|
| Compare http://www.w3.org/Consortium/Legal/IPR-FAQ-20000620#DTD and
| http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
| for the W3C Software License. This DTD is a "derivative work" for
| experimental and educational purposes.

Nothing critical anymore, ICANN fixed their IDN Wiki already.  But
it's only lack of time that I didn't post it in a draft before the
deadline (and before the IDN Wiki was fixed), likely as independent
experiment, if the DTD registration rules allow this, but if not it 
would need to be an individual experiment.  Maybe still necessary,
IMO the IRIbis author can't base his "interoperability report" on
formally invalid Web pages, it's odd enough when the W3C does this.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 2 Dec 2007 02:54:53 +0100

Nothing critical anymore, ICANN fixed their IDN Wiki already.
But it's only lack of time that I didn't post it in a draft
before the deadline (and before the IDN Wiki was fixed),
likely as independent experiment, if the DTD registration
rules allow this, but if not it would be an "individual
experiment.  Maybe still necessary, IMHO the IRIbis author
can't base any "interoperability report" on formally invalid
Web pages, it's odd enough when the W3C does this.

Any rules designed here must make sense for authors (first
priority), readers / users / implementors (second priority),
and the IETF Trust (third priority).  Sometimes I think your
(Harald and you) priorities are exactly the opposite, Trust
first, authors third.

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 15 Dec 2007 11:34:42 +0100

Brian E Carpenter <[email-masked]> writes:

>>> I think the WG has concluded that it's unacceptable to publish
>>> source code in an RFC that, if copied from the RFC and modified by
>>> a reader, would place a GPL (or any other copyright-based)
>>> requirement on that
>>> reader.
>>
>> Sounds familiar...
>>  

I don't understand the focus on GPL here, any license that restricts the
recipient from doing certain things would have the same issue.  The
current IETF license is an example of such a license (fixed by
incoming+outgoing though).  There has been source code examples in RFCs
with nasty licenses; if I recall correctly, some does not even permit
redistribution.

Further, I think the point is that it happens often that the copyright
holder on some code haven't released code under IETF's licenses, and it
is useful to include the code in an RFC.  The current situation works
against the IETF's goal of facilitating wide implementations of
standards.  This situation is bad, and your suggested solution isn't
realistic.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Dec 2007 15:02:22 +0100

I've taken the liberty of including this comment in #1539, since it 
seems that the two issues-as-stated will be solved by the same careful 
crafting of language.

                   Harald

[email-masked] wrote:
> Someone (Jorge?) should double-check that -incoming
> is consistent with the operation of the "work for hire"
> principle of copyright law, which essentially assigns
> copyright in anything created by an employee as part
> of his/her job responsibilities to his/her employer.
>
> This is mentioned in Section 2 and there is enough
> usage of "sponsored by", "organization the Contributor
> represents" and the like in Section 5 to indicate
> that "work for hire" has been considered and -incoming
> is probably ok, but an opinion from an actual lawyer
> would be helpful.
>
> There may be a need for the submission tool to give
> enough notice of "work for hire" in plain language
> (i.e., not legalese) to a submitter in order to ensure
> that section 5.6.c of -incoming applies to someone who
> doesn't have their employer's permission to submit,
> but submits anyway.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>

---

From: [email-masked]
Date: Mon, 17 Dec 2007 09:53:49 -0500

Harald,

Please ensure that the words "work for hire" appear in the
tracker entry.  In my view, this issue will not be closed
until counsel (Jorge) is satisfied that the carefully
crafted language is sufficient to deal with the operation
of "work for hire".

Thanks,
--David

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: Monday, December 17, 2007 9:02 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: ISSUE: incoming 5: work for hire
>

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 17 Dec 2007 07:19:45 -0800

The problem David isn't whether Jorge likes it or not but whether our
Sponsor's Counsel's like this language and for them to not be involved in
codifying this as a contract makes us their 'counsel' in that process which
again most all of are neither credentialed to do or authorized in any form
for.

Todd Glassey

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 17, 2007 6:53 AM
Subject: RE: ISSUE: incoming 5: work for hire

Harald,

Thanks,
--David

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Dec 2007 16:29:32 +0100

> crafted language is sufficient to deal with the operation
The text of your message appears in the tracker entry.

           Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2007 15:51:21 +1300

On 2007-12-15 23:34, Simon Josefsson wrote:
> recipient from doing certain things would have the same issue. 

I agree. GPL is an example.

> The

Why not? We've just done it (twice) for a draft I reviewed. It would only
fail in the case of an uncooperative author, and in that case we're
stuck anyway.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Dec 2007 11:47:23 +0100

Brian E Carpenter <[email-masked]> writes:

> Why not? We've just done it (twice) for a draft I reviewed.

Which drafts was that?  In the latest example that Russ asked the IPR WG
about, draft-ietf-rmt-bb-fec-ldpc, after discussions, I was told the
solution will be to remove code from the document.

> It would only fail in the case of an uncooperative author, and in that
> case we're stuck anyway.

No, that's missing the point.  In draft-ietf-rmt-bb-fec-ldpc and the
base64 draft, external copyright owners own the copyright on code that
is useful to include in the document.  To be over-precise: it is useful
for the _IETF_, it is not necessarily useful for the copyright owner.

In the cases where the copyright owner(s)

  1) can't be identified or reached,
  2) is unwilling to re-license the work,
  3) is never approached to resolve the issue

it can still happen that it is useful for the IETF to be able to include
code.  The code may be licensed under a widely permissible license.
Still, given how the IETF rules work now (and in the future too), this
is impossible.

The requirement to not include external copyright notice has been
violated several times in RFCs, and I haven't seen an argument that the
requirement is more important than allowing the IETF to work better.  It
makes it impossible to include freely licensed code that would help
documents.  I think the policy should be modified here.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Dec 2007 12:34:17 +0100

Simon,

you have raised your argument. The WG has declared consensus otherwise.

Please stop wasting the bandwidth on the list; save your breath for IETF 
Last Call
(if you REALLY want to have all the arguments repeated once more).

                    Harald