headers
Frank Ellermann | 1 Dec 17:38
Picon
Picon

Re: Addition to "advice to trust" part of agenda: Submission procedures for IETF contributions

Brian E Carpenter wrote:

> You'll have to work hard to convince me that we need
> anything more than clicking through a page like these:

> http://www.ietf.org/maillist.html
> http://www3.ietf.org/meetings/70-notewell.html

> (Such a page should probably be inserted in the
> I-D submission tool.)

And in the challenge sent by mailing lists to new
subscribers (or similar confirmation procedures).
Or in welcome messages, whatever is available.

Ditto in the not yet existing challenge for errata
submitted with the new Web form, folks stumbling
over errors in RFCs might have no idea what the
IETF is, let alone how it defines "contribution".

What about submissions of interoperability reports,
IPR notes, and appeals ?  I've no idea how somebody
could manage to file an appeal without ever reading
"note well" before, and I've no idea how IPR notes
could be affected by a "note well" (but if they are
ever affected it's likely critical).

For "interoperabilty reports" it might be remotely 
relevant that they can be evaluated as contributions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 Dec 18:27
Picon
Picon

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

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
(Continue reading)

Permalink | Reply | 10 comments |
headers
Brian E Carpenter | 1 Dec 19:57
Picon

Re: Sample code

On 2007-12-02 06:27, Frank Ellermann wrote:
> 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, 

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
Permalink | Reply | 9 comments |
headers
TS Glassey | 1 Dec 21:19
Picon
Favicon

Re: Sample code

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
TS Glassey | 1 Dec 21:20
Picon
Favicon

Re: Sample code

Ooops...

----- Original Message ----- 
From: "TS Glassey" <tglassey <at> earthlink.net>
To: "Brian E Carpenter" <brian.e.carpenter <at> gmail.com>; "Frank Ellermann" 
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz <at> gmail.com>
Cc: <ipr-wg <at> ietf.org>
Sent: Saturday, December 01, 2007 12:19 PM
Subject: Re: Sample code

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 1 Dec 22:44
Picon
Picon

Re: Sample code

TS Glassey wrote:

> should have read "as" (my apology)...

...don't worry about it, apparently you
have a "thing" with this word.  I'd try
to remove it from my spell checker, but
my DEnglish typos are less predictable.

Ob on topic, I'm still not interested in
details of US law, the EU + DE madness
is fascinating enough for me.  

It could make sense to adopt rules by an
organization devoted to get such issues 
right worldwide (IOW "creative commons"),
but apparently the WG doesn't like this,
too bad :-(

 Frank
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 2 Dec 02:47
Picon
Picon

Re: Sample code

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 2 Dec 02:54
Picon
Picon

Re: Sample code

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred Baker | 2 Dec 20:12
Picon
Favicon

Re: Submission of XML sources


I'm going through some old mail and came across this note.

When the XML2RFC tool was built, the idea was to simplify the job of  
the document author, the job of the reviewers, and the job of the RFC  
Editor, and do so in a non-proprietary format. Many SDOs use  
Microsoft Word; this is considered somewhat anathema in the IETF  
because some common operating systems (Linux, BSD, Solaris) don't run  
the application, and because the document format changes in non- 
interoperable ways every few years. So Mrashall and company created a  
means to do so in an interoperable (any XML editor will do, or in a  
pinch any text editor).

Sending in the output of the tool makes something that folks can  
read; so does the Microsoft Word-based tool, nroff, and others.  
However, for the RFC Editor, the XML tool allows them to directly set  
a flag and convert to RFC format with the right relevant text (for  
example to describe a BCP as opposed to an informational document).  
It also allows people to build other XML-based tools for operating on  
the document. For example, I have wondered from time to time about  
building a technical grammar/spell checker that handles the language  
used in RFCs, which contains (as all technical document series do) a  
lot of jargon. Doing that would require scanning existing documents  
for text to build the database, and starting from the "text" output  
requires direct knowledge of page headers and footers and the  
placement of ASCII Art; doing so from the XML source is trivial.

One thing I would like the ID-submission tool to do is directly  
create the .txt file when given the .xml file, to guarantee that  
there is a direct correlation between them. There is supposed to be,
(Continue reading)

Permalink | Reply | 5 comments |
headers
todd glassey | 2 Dec 20:28
Picon
Favicon

OpenOffice makes it OK to submit .docs to the IETF - Was Re: Submission of XML sources

Fred
----- Original Message ----- 
From: "Fred Baker" <fred <at> cisco.com>
To: "Frank Ellermann" <hmdmhdfmhdjmzdtjmzdtzktdkztdjz <at> gmail.com>
Cc: <ipr-wg <at> ietf.org>; <i <at> cisco.com>
Sent: Sunday, December 02, 2007 11:12 AM
Subject: Re: Submission of XML sources

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm going through some old mail and came across this note.
>
> When the XML2RFC tool was built, the idea was to simplify the job of  the 
> document author, the job of the reviewers, and the job of the RFC  Editor, 
> and do so in a non-proprietary format.

I like the way you put that... politiclly correct BS - I thought the idea 
was to prevent Microsoft Word from becoming a next generation acceptable 
document submisson standard, and that the IESG members did this to prevent 
the expansion of the 'evil empire'... Or at least that was what numerous 
people said to me when I proposed amending the acceptable formats some 
number of years ago... The problem is that now that OpenOffice exists that 
claim is no longer viable, and the IETF should accept .DOC submissions IMHO.

> Many SDOs use  Microsoft Word; this is considered somewhat anathema in the 
> IETF  because some common operating systems (Linux, BSD, Solaris) don't 
> run  the application, and because the document format changes in non- 
> interoperable ways every few years.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane