headers
Harald Alvestrand | 4 Jun 00:38
Picon

Rights that expire in 6 months (Re: #1175 Code vs text)

John C Klensin wrote:
> The other issue, which ought to be orthogonal to this but
> impacts it, is that I-Ds are different from published, archival,
> RFCs.  Formally, I-Ds expire after six months and all rights,
> except those covered by the Note Well, revert to the author.
> Formally, we don't encourage production implementations from
> I-Ds, so whether anyone needs lasting rights to "code" embedded
> in I-Ds to fulfill any IETF purpose is an open question.  The
> practices are a little different, but I hope we can get those
> issues under control long before we have to sort them out of a
> document at Last Call.
after considering this for a while.... yes, I think it's orthogonal to 
#1175, but I have an opinon (as participant):

if a company copies code from draft -23 of a specification into its 
product, the IETF chooses to remove that example code from draft -48, 
and the company later makes the code work consistently with draft -53 
which is finally published as an RFC (with no code in it), I think that 
the company will be very unhappy if the draft -23 author comes along and 
demands royalties for the use of his code 6 months after its publication.

The company has acted in good faith to implement the IETF's standards, 
including gathering early experience ("rough consensus and running 
code"), and the threat of landing in a copyright no-man's land because 
of this is not a Good Thing for the Internet.

This is kind of a "reductio ad absurdum" way of working out my opinion 
on the matter, but I think I've convinced myself:
The right to use code extracted from I-Ds needs to be permanent.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Harald Alvestrand | 4 Jun 00:43
Picon

#1175 Code vs text - second attempt at resolution

In our list of open issues, we have this issue:

> If there are different rights granted to participants for working with 
> code than with non-code, it
> has to be possible for users to tell which is which. Suggestions include:
> - Defining it by type (C code, ABNF, MIBs...)
> - Defining it by marker (<code>/</code>)
> - Defining it by separate submission (file alongside draft)
> If there are no such differences, the point is moot.

The discussion from my previous attempt at a resolution had 4 
participants, which is a bit too few for comfort. Mainly, it seems to 
have indicated that the resolution should say less - and clearly 
illustrates that defining "pseudocode" is even harder than defining "code".

Second attempt:
--------------------------------------------------------------------
If a distinction needs to be drawn between code and non-code in IETF
documents, the community desires that:

- Specifications in formal languages, including C code, ABNF, MIBs,
ASN.1 and so on, are clearly "code".
- Tables such as the character lists in IDNA are to be regarded as
"code" too.
- Prose, including "pseudocode" that does not claim any level of
formality, is not "code" for the purposes of this resolution. This 
resolution does not say anything about the IETF's desires regarding 
"pseudocode", one way or another.
- The IETF Trust should maintain specific guidance on what will be
regarded as "code", including guidance on how to mark "code" in
(Continue reading)

Permalink | Reply | 526 comments |
headers
todd glassey | 4 Jun 16:22
Picon

Re: #1175 Code vs text - second attempt at resolution

Harald - this code thing and identifying it are pretty simple - 'CODE is
anything that represents an Algorithm or Formulae or any identifiable
sub-component thereof" - which makes the constraints of what is and isn't
code really easy to define.

CODE includes, but is not limited to:
------------------------------------
Any Algorithm (or Formulae) or components thereof,  represented in ANY form,
including written descriptions of the work-flow or process steps.
Particularly:
            a)    anything written in any of the formally standardized
"PROGRAMMING LANGUAGES" including any and all High-Level Programming
Languages - C, Fortran, Pascal, Lisp, Java, Cobol/Snobol/Fastbol/RPG/RPGII,
or Native Assembler's and the like;

This of course also includes any data objectes from the above whether in
Machine Code/Binary,  Source,  or Intermediary-PCode;  Other programming
languages covered in this description include BASIC and the other
interpreted languages like FORTH for instance

            b)    Configuration Files content for any and all components
which would qualify under a) as a program or program-fragment (here is where
your MIB's and other Configuration Tables get covered...)

            c)    Any recognized Pseudo-coding model or standard including
the any and all frameworks defined as a part of another process. ABNF and
the other flowcharting process including but not limited to:

    ci)    State Diagrams, Mind Mapping Diagrams, Cause and Effect Diagrams,
SDL, TQM Diagrams
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel M. Halpern | 4 Jun 17:09

Re: #1175 Code vs text - second attempt at resolution

I disagree.  I think Harald's formulation works for what we need.  I 
think your proposed formulation would essentially remove all 
ptentially useful distinction between code and text.

Yours,
Joel M. Halpern

At 10:22 AM 6/4/2006, todd glassey wrote:
>Harald - this code thing and identifying it are pretty simple - 'CODE is
>anything that represents an Algorithm or Formulae or any identifiable
>sub-component thereof" - which makes the constraints of what is and isn't
>code really easy to define.
Permalink | Reply | 1 comment |
headers
todd glassey | 4 Jun 17:52
Picon

Re: #1175 Code vs text - second attempt at resolution

Joel - What would a court say? Hmmmm - Lets see what the EU says?
http://dataright.haifa.ac.il/db-definition.htm

"Firstly, the materials incorporated into the database have to be
'independent'. This presumably means that each of the items included in the
database should be known and recognised. Secondly, the materials have to be
arranged in a systematic or methodical way. Thirdly, the materials are
individually accessible by electronic and other means. This last attribute
is closely related to the 'independent' attribute."

OK - #1 - each entry into the DB is published as a stand-alone work and then
included into the data base itself. #2 is addressed by the content ownership
rights to the IP submitted, and thirdly that the list is sortable - thanks
to Google and others this also is met... So the IETF's collection of
documents as would any stand-alone subset in a WG Archive under Note-Well
would meet the definitions of the EU's directive.

So then the collection of RFC's and I-D's are DB's under the EU's
definition... and also controlled separately from the content rights
therein. Anyone take this into account? How about when a WG Mailing List is
also reduced to being defined as a DB...

Todd Glassey

----- Original Message ----- 
From: "Joel M. Halpern" <joel <at> stevecrocker.com>
To: <ipr-wg <at> ietf.org>
Sent: Sunday, June 04, 2006 8:09 AM
Subject: Re: #1175 Code vs text - second attempt at resolution
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 4 Jun 23:45

Re: Rights that expire in 6 months (Re: #1175 Code vs text)


--On Sunday, June 04, 2006 00:38 +0200 Harald Alvestrand 
<harald <at> alvestrand.no> wrote:

> John C Klensin wrote:
>> The other issue, which ought to be orthogonal to this but
>> impacts it, is that I-Ds are different from published,
>> archival, RFCs.  Formally, I-Ds expire after six months and
>> all rights, except those covered by the Note Well, revert to
>> the author. Formally, we don't encourage production
>> implementations from I-Ds, so whether anyone needs lasting
>> rights to "code" embedded in I-Ds to fulfill any IETF purpose
>> is an open question.  The practices are a little different,
>> but I hope we can get those issues under control long before
>> we have to sort them out of a document at Last Call.

> after considering this for a while.... yes, I think it's
> orthogonal to #1175, but I have an opinon (as participant):
>
> if a company copies code from draft -23 of a specification
> into its product, the IETF chooses to remove that example code
> from draft -48, and the company later makes the code work
> consistently with draft -53 which is finally published as an
> RFC (with no code in it), I think that the company will be
> very unhappy if the draft -23 author comes along and demands
> royalties for the use of his code 6 months after its
> publication.

And more unhappy if the author of -23 simply refuses to let them 
use the code at all.
(Continue reading)

Permalink | Reply | 3 comments |
headers
todd glassey | 5 Jun 02:00
Picon

Re: Rights that expire in 6 months (Re: #1175 Code vs text)

John -
----- Original Message ----- 
From: "John C Klensin" <john-ietf <at> jck.com>
To: "Harald Alvestrand" <harald <at> alvestrand.no>
Cc: <ipr-wg <at> ietf.org>
Sent: Sunday, June 04, 2006 2:45 PM
Subject: Re: Rights that expire in 6 months (Re: #1175 Code vs text)

>
>
> --On Sunday, June 04, 2006 00:38 +0200 Harald Alvestrand
> <harald <at> alvestrand.no> wrote:
>
> > John C Klensin wrote:
> >> The other issue, which ought to be orthogonal to this but
> >> impacts it, is that I-Ds are different from published,
> >> archival, RFCs.

I didnt see anything that would limit the use of the IP in a ID based on the
license in its boiler plat - once its published its out there. The IETF has
no retraction process or terminus-of-licensing process such that any license
expires on any IETF wares as it is today... This is one of the problems -
the IETF loses control of all its IP the instant its published by its Any
and All Uses language.

> >> Formally, I-Ds expire after six months and
> >> all rights, except those covered by the Note Well, revert to
> >> the author. Formally, we don't encourage production
> >> implementations from I-Ds, so whether anyone needs lasting
> >> rights to "code" embedded in I-Ds to fulfill any IETF purpose
(Continue reading)

Permalink | Reply | 0 comments |
headers
David B Harrington | 5 Jun 14:45
Picon

RE: #1175 Code vs text - second attempt at resolution

Hi,

I suggest that a contributor that wishes to ensure that their
"pseudocode" can be copied with the same constraints as code would be
could explicitly mark the section with <code></code> markers.
Pseudocode that is not explicitly surrounded by <code> markers could
be declared (by IPR-WG document) to be non-code for purposes of
copyright.

David Harrington
dharrington <at> huawei.com 
dbharrington <at> comcast.net
ietfdbh <at> comcast.net

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald <at> alvestrand.no] 
> Sent: Saturday, June 03, 2006 6:44 PM
> To: ipr-wg <at> ietf.org
> Subject: #1175 Code vs text - second attempt at resolution
> 
> In our list of open issues, we have this issue:
> 
> > If there are different rights granted to participants for 
> working with 
> > code than with non-code, it
> > has to be possible for users to tell which is which. 
> Suggestions include:
> > - Defining it by type (C code, ABNF, MIBs...)
> > - Defining it by marker (<code>/</code>)
> > - Defining it by separate submission (file alongside draft)
(Continue reading)

Permalink | Reply | 1 comment |
headers
todd glassey | 5 Jun 15:11
Picon

Re: #1175 Code vs text - second attempt at resolution

Why? For what purpose? To make the IETF's definitions more out of alignment
with the rest of the IPR world??? - As to Code - all that matters is the
patent protection capabilities - and to not destroy people's patent
capabilities by participating with the IETF - unless that is the goal here.

That said - then the real diagramming - whether specific to CODE or DRAWINGS
should conform to US and Euro Patent Documentation/Diagramming Standards,
the IETF's publishing rights are orthogonal & of little impact to all other
concerns.

The reasoning is that if someone cannot protect the uniqueness of their
invention without destroying those rights within the IETF, then there is no
reason to deal with the IETF and in fact the IETF becomes a threat to many
corporate entities IMHO.

Todd Glassey

----- Original Message ----- 
From: "David B Harrington" <dbharrington <at> comcast.net>
To: "'Harald Alvestrand'" <harald <at> alvestrand.no>; <ipr-wg <at> ietf.org>
Sent: Monday, June 05, 2006 5:45 AM
Subject: RE: #1175 Code vs text - second attempt at resolution

> Hi,
>
> I suggest that a contributor that wishes to ensure that their
> "pseudocode" can be copied with the same constraints as code would be
> could explicitly mark the section with <code></code> markers.
> Pseudocode that is not explicitly surrounded by <code> markers could
> be declared (by IPR-WG document) to be non-code for purposes of
(Continue reading)

Permalink | Reply | 0 comments |
headers
todd glassey | 5 Jun 17:17
Picon

Possible NEW item - Additional IPR Timing Boilerplate.

Harald - I want to propose that we should add something like a statement
that the IETF acknowledges that the publication of any of its documents may
start IP timers running, and that in these instances, the Submitter of the
IP to the IETF accepts any and all responsibilities for that submission.
That as a SDO, the IETF's responsibilities are for the processes it uses to
create and honor IP controls.  These processes, which are stated in numerous
other IETF process documents, document that all responsibilities for the use
or reliance on these IP's rest with the adopter.

The same statement should document that the IETF makes no warranties as to
the license or its fitness, or that rescission will never happen... And that
any final provisions, contracts, or licenses for use must be managed between
the IP Owners and the Relying Parties.

...Or something like it.

This statement addresses/or should address:

    1)    Acknowledgement that there may be other un-named IPR at play here.
Especially those including multiple jurisdictions.

    2)     That the IPR publication is the responsibility of the submitter,
and the IETF is only acting as a mechanical agent in furtherance of their
will and action.

    3)    That the publication of this draft or RFC may start International
Patent Control Timers running but that this is the responsibility of the
Submitter/and not the IETF

And yes I know that there are scattered statements in a number of documents
(Continue reading)

Permalink | Reply | 0 comments |

Gmane