Re: -Incoming issues in need of resolution

[Simon Josefsson <simon at josefsson.org>]

Harald Alvestrand <harald at alvestrand.no> writes:

> 1) Insert a "read-only" license into -incoming, granting essentially the
> same rights as is granted to any other reader, but linking them to the
> submission agreement rather than to an IETF Trust grant decision:

That seems to be an OK approach.  I support that it should be very clear
for IETF contributors that they retain the copyright of their
submission.  To make that as clear as possible, making that explicit in
-incoming seems like a good idea.

Although the devil is in the details, specifically:

>
>> 5.10. Contributors retention of rights
>> .br
>> Notwithstanding any terms in this document to the contrary, in addition
>> to any rights under copyright retained by Contributor and in addition to
>> any rights generally granted by the TETF trust, Contributor retains, and
>> grants to each Co-Contributor to an RFC in which such Contributor's
>> Contribution, or a derivative work thereof may appear, the right:

Ouch!  This goes way beyond "author retains their rights", it grants
co-authors some rights to other co-authors' contributions.

More importantly, the text does not explain that authors retains the
copyright in their contribution.  That is the most important thing to
describe in -incoming.

The text would introduces a further legal class of parties with
copyright claims on documents: authors, co-authors, and those parties
given rights via -outbound.

Given that the IETF have policies to reduce the number of co-authors,
this text seems problematic.  It may be that a contributor wrote a large
portion of a document without being listed as an author.  This can
happen when an RFC is revised.  For example, RFC 4398 contains text
mostly written by others, still I'm the author of the RFC.

Is this complexity required to solve whatever is the perceived problem
here?  Generally, I think it is better to first agree on the problem
before proposing and discussing solutions.

I think we should try to reduce legal complexity, not increase
complexity.  In my opinion, the simplest way to reduce legal complexity
would be if authors granted everyone full rights to the document.

>> Notwithstanding the above rights, the Contributor does not have the right
>> to represent any document as an RFC, or equivalent to an RFC, if it is
>> not a full and complete copy or translation of the published RFC.

This seems like a frivolously added restriction, and not an added right.
What is this intended to protect against?

> 2) Granting a special license to produce derivative works from the text
> of the finished RFC, subject only to the limitation that the result
> can't be presented as if it was an RFC.

If that license is granted to everyone, I would strongly support that
idea.

Otherwise, it seems to add legal complexity, and as far as I can see,
granting these rights is not consistent with any earlier IETF policies.
I don't see anything in RFC 2026, RFC 3978 or -incoming/-outgoing that
supports this idea.

Note that if the RFC editor's modifications to the document where
minimal, the original authors do retain the copyright on the significant
parts of published work (i.e., except the boiler plates) since he is the
copyright owner of it.

> The argument has been presented (in private) that the following
> principles were "always implied" wrt RFCs:
>
> 	(1) The author(s) or editor(s) of an RFC were the
> 	authors/ editors.  The RFC Editor wasn't the author, an
> 	editor, or the owner of the document.  The RFC Editor
> 	acted as the agent of the author in adding any
> 	boilerplate and licenses, whether it was the early "...
> 	distribution unlimited..." or the current pages of ISOC/
> 	IETF Trust boilerplate.
> 	
> 	(2) If there was more than one author, they were the
> 	compilers of the document as a group and their joint
> 	efforts produced the document from their work and any
> 	other work that they incorporated and took
> 	responsibility for having the rights to use.
> 	
> 	(3) The author(s) granted the community the right to
> 	reproduce and use, but retained, as a group if there was
> 	more than one, "all rights" from a legal sense.

This is not my understanding of the IETF policies.  I wish that any
claims that something has been "always implied" is backed up with
references to some earlier legal text that the IETF has used.

> The other issue, raised by Jorge Contreras, concerns the split of the
> work of this WG into two documents (-incoming and -outgoing); if we
> start having language in the -incoming document granting some outgoing
> rights, the separation becomes rather blurred from his perspective.
>
> The opposite viewpoint is that the two documents have distinct audiences
> and distinct status in the IETF process, and that it therefore makes no
> sense to merge them; such a merge would also be inconsistent with the
> charter of the WG.

I disagree with the WG charter here.  I think there should be only
document that explains that when you submit a document to the IETF, you
permit others to produce derivative works of it.  Today authors grant
that right to everyone who works with the document within the IETF.  But
that causes problems for free software that wish to include RFCs in
documentation or packages.

/Simon

_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg