headers
Elwyn Davies | 3 Jul 14:54

Comments on draft-josefsson-ipr-notices-00

Hi, Simon.

The four examples of recent RFCs with 'extra' copyright statemsnts which you
quote are actually three separate classes of 'copright' statement.  I think you
will need two different clauses (and maybe an extra 'stub' as well) to cover the
different cases.

- RFC4501 (and the rfc3584bis draft) contain a notice which you as
author include regarding your retained rights in the whole document.  As
such that doesn't really affect the copyright notices of the draft/rfc
regarding the IETF/ISOC rights.  I guess there should be no difficulty
in drafting some suitable boilerplate to cover this case and I see no
reason why the IETF should stop authors making this sort of statement
(although doubtless those with corporate employers and IPR lawyers will
find it difficult to persuade them that the statement should appear :-)
).  This has nothing specific to do with embedded code fragments or
other pieces that might be extracted.

- RFC4287 is just an example and I don't think it need concern us here
as it doesn't actually affect anything (or shouldn't).  The stub
mentioned above might be useful for specifying the form of a suitable
example copyright statement where such is needed.

- The interesting cases are RFC4122 and RFC4226.  Looking at these I
believe that they are different from your proposal to use the GNU Lesser
GPL in the rfc3584bis draft because they essentially grant free licence
to modify the code without publishing the mods which is nearly in line
with RFC3978, s3.3 a(E) which covers extractable code fragments and the
like.  The Lesser GPL is different in that it requires publication of
modified source code which is not in line with the general principles of
(Continue reading)

Permalink | Reply | 10 comments |
headers
Simon Josefsson | 3 Jul 16:10

Re: Comments on draft-josefsson-ipr-notices-00

Elwyn Davies <elwynd <at> dial.pipex.com> writes:

> Hi, Simon.
>
> The four examples of recent RFCs with 'extra' copyright statemsnts
> which you quote are actually three separate classes of 'copright'
> statement.  I think you will need two different clauses (and maybe
> an extra 'stub' as well) to cover the different cases.

Hi Elwyn!

> - RFC4501 (and the rfc3584bis draft) contain a notice which you as
> author include regarding your retained rights in the whole document.  As
> such that doesn't really affect the copyright notices of the draft/rfc
> regarding the IETF/ISOC rights.  I guess there should be no difficulty
> in drafting some suitable boilerplate to cover this case and I see no
> reason why the IETF should stop authors making this sort of statement
> (although doubtless those with corporate employers and IPR lawyers will
> find it difficult to persuade them that the statement should appear :-)
> ).  This has nothing specific to do with embedded code fragments or
> other pieces that might be extracted.

Right, agreed.

> - RFC4287 is just an example and I don't think it need concern us here
> as it doesn't actually affect anything (or shouldn't).  The stub
> mentioned above might be useful for specifying the form of a suitable
> example copyright statement where such is needed.

Right.  It's only relevance here is that, technically, it does contain
(Continue reading)

Permalink | Reply | 9 comments |
headers
Bill Fenner | 3 Jul 18:39
Picon

NEW ITEM: Notices and Rights Required in RFC Editor Contributions

When I was revising 1id-guidelines, I engaged the RFC Editor in trying
to help me express the rules wrt RFC 3978 6.b.  The response was that:

6.b.A) didn't make sense since it was asking to agree to the rights
for IETF contributions;
6.b.B) was possibly dangerous to the IETF, since e.g., it doesn't
require the copyright notice from section 5.4 or the disclaimer from
section 5.5

and that the 6.b.C) seemed the closest to the truth except for the
additional copyright URL in an RFC Editor Contribution.

If RFC 3978 is going to be updated, I'd like to see section 6 revised
to actually address what the RFC Editor requires/desires.  Having
unused options just makes life confusing.

  Bill
Permalink | Reply | 2 comments |
headers
todd glassey | 3 Jul 18:48
Picon

Re: NEW ITEM: Notices and Rights Required in RFC Editor Contributions

Bill - this is exactly the problem with having a contract for services and
performance spread out across a bunch of different and somewhat unconnected
documents.

I would like to propose that there be one "Participation Contract" and that
its sections if necessary can be broken out into other documents but that
these documents should be exempted from the traditional IETF Formula and be
implemented in the more traditional document/contract forms.

Where the rubber meets the road should be a single document specifying which
other documents and how they leverage or mitigate each other and one where
there is a simple and unified reliance process.

Todd Glassey

----- Original Message ----- 
From: "Bill Fenner" <fenner <at> gmail.com>
To: "IPR WG" <ipr-wg <at> ietf.org>
Sent: Monday, July 03, 2006 9:39 AM
Subject: NEW ITEM: Notices and Rights Required in RFC Editor Contributions

> When I was revising 1id-guidelines, I engaged the RFC Editor in trying
> to help me express the rules wrt RFC 3978 6.b.  The response was that:
>
> 6.b.A) didn't make sense since it was asking to agree to the rights
> for IETF contributions;
> 6.b.B) was possibly dangerous to the IETF, since e.g., it doesn't
> require the copyright notice from section 5.4 or the disclaimer from
> section 5.5
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Fenner | 3 Jul 23:15
Picon

NEW ITEM: "Normally placed at the end"

RFC 3978 says:

5.4.  Copyright Notice (required for all IETF Documents)

   (Normally placed at the end of the IETF Document.)

5.5.  Disclaimer (required in all IETF Documents)

   (Normally placed at the end of the IETF Document after the copyright
   notice.)

Are these location statements normative?  That is, is there a
requirement for these parts to be at the end of the document, or do
they have the same meaning in the middle of the document?

The question arises because "the end" is not particularly well
specified - can it be before appendices?  Can it be the last main
section of the document before Authors' Addresses?  Does it have to be
the last page?

Thanks,
  Bill
Permalink | Reply | 10 comments |
headers
Brian E Carpenter | 4 Jul 11:29
Picon
Favicon

Re: NEW ITEM: "Normally placed at the end"

Personal opinion:

Bill Fenner wrote:
> RFC 3978 says:
> 
> 5.4.  Copyright Notice (required for all IETF Documents)
> 
>   (Normally placed at the end of the IETF Document.)
> 
> 5.5.  Disclaimer (required in all IETF Documents)
> 
>   (Normally placed at the end of the IETF Document after the copyright
>   notice.)
> 
> 
> Are these location statements normative?  That is, is there a
> requirement for these parts to be at the end of the document, or do
> they have the same meaning in the middle of the document?
> 
> The question arises because "the end" is not particularly well
> specified - can it be before appendices?  Can it be the last main
> section of the document before Authors' Addresses?  Does it have to be
> the last page?

Why leave it ambiguous? That only results in rather futile arguments
about when "normally" applies.

Why not just say:

Placed at the end of the document, after all other content except the
(Continue reading)

Permalink | Reply | 8 comments |
headers
Pekka Savola | 4 Jul 13:57
Picon

Re: NEW ITEM: "Normally placed at the end"

On Tue, 4 Jul 2006, Brian E Carpenter wrote:
> Why leave it ambiguous? That only results in rather futile arguments
> about when "normally" applies.
>
> Why not just say:
>
> Placed at the end of the document, after all other content except the
> disclaimer mentioned below.
>
>  and
>
> Placed at the end of the document, after all other content.

It isn't quite that simple -- xml2rfc generated docs have this as the 
last thing on the document:

Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Permalink | Reply | 2 comments |
headers
Brian E Carpenter | 4 Jul 14:17
Picon
Favicon

Re: NEW ITEM: "Normally placed at the end"

Pekka Savola wrote:
> On Tue, 4 Jul 2006, Brian E Carpenter wrote:
> 
>> Why leave it ambiguous? That only results in rather futile arguments
>> about when "normally" applies.
>>
>> Why not just say:
>>
>> Placed at the end of the document, after all other content except the
>> disclaimer mentioned below.
>>
>>  and
>>
>> Placed at the end of the document, after all other content.
> 
> 
> It isn't quite that simple -- xml2rfc generated docs have this as the 
> last thing on the document:
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).

Sure. Well we can either have words to allow that or move it...

The point is that any words like "normally" create a headache for
automated checking tools, and boilerplate is above all something
that we should be able to check for automatically.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Fenner | 4 Jul 14:51
Picon

Re: NEW ITEM: "Normally placed at the end"

Let me try again, since I wasn't clear enough the first time.

Is there a legal reason that these statements must be the last things
in the document, or would they have the same force appearing elsewhere
in the document?  Please try to avoid expressing a cosmetic
preference, that's not the issue.

Thanks,
  Bill
Permalink | Reply | 3 comments |
headers
Simon Josefsson | 4 Jul 14:52

NEW ITEM: Does RFC 3978 3.3.a.(E) grant third parties rights to modify source

I believe this is worth a separate issue in the tracker.  The question
is technically limited, has input from Jorge, so I hope it can be
closed fast.

The only reason I wish to bring this up as a formal item is that we
haven't heard about this interpretation before, and it is a rather
surprising one (to me).

A first attempt at defining the issues:

1) Do RFC 3978 already permit modification of code extracts from RFCs
   by third parties, through the "(and not limited ...)" phrase?

If the consensus is affirmative, I believe RFC 3978bis, or the
document that deals with the outbound rights from the IETF to third
parties should be clarified to make this point more explicitly.  Hence
a second part of this issue:

2) Should we clarify the license to make this clear?

I'm quoting the relevant part from Elwyn's e-mail below.

Thanks,
Simon

Simon Josefsson <jas <at> extundo.com> writes:

> Elwyn Davies <elwynd <at> dial.pipex.com> writes:
>
>> [Note: Brian Carpenter has recently obtained an opinion from our
(Continue reading)

Permalink | Reply | 8 comments |

Gmane