Re: legal consultation (was List moderator action)

Simon Josefsson <[email protected]> Thu, 07 May 2026 09:16:38 +0200
Newsgroups gmane.ietf.general
Message-ID <[email protected]>
Brian E Carpenter <[email protected]> writes:

> Simon,
>
>> Thus, let me propose something stronger: forbid the no-derivative rights
>> clause completely, for all Contributions.
>
> Thr original intention was explicitly to allow the RFC series to
> re-publish 3rd party specifications (whether proprietary, or controlled
> by another SDO).
>
> That might still be useful, but IMHO could, and probably should, be
> done in the Independent Submission stream of RFCs. The Independent
> stream can already permit "no derivative rights" under RFC 5744.
>
> Therefore, IMHO it would be perfectly reasonable to disallow "no
> derivative rights" for all IETF stream contributions. I really
> don't think it will have a chilling effect on new work. (If someone
> is planning a patent, they will not submit a draft anyway.)

I don't have an opinion on that, but that doesn't reduce complexity.

My proposal is to get rid of the complexity stemming from the
no-derivative clause by removing it as an option.

With your proposal, the complexity is increased, and coupling different
streams to different set of legal terms.  It also begs the question how
to deal with a single document switches back and forth between streams,
or handling contributions received for each situation.  If we really
don't want to go down into that complexity rabbit hole, I suggest to
avoid it.

/Simon

> Incidentally, I cannot be certain of this without a lot of work, but
> I strongly suspect that the number of IETF stream documents with a
> "no derivative works" clause published since RFC 5378 is approximately
> zero. (There are many with the "pre5378Trust200902" boilerplate, but there
> is nothing to be done about that and it will remain necessary for some
> "bis" documents.) So I believe that Simon's proposal would have no effect
> whatever on the IETF's output, and would ease our discussions.
>
> Regards/Ngā mihi
>    Brian Carpenter
>
> On 07-May-26 08:40, Simon Josefsson wrote:
>> Rob Sayre <[email protected]> writes:
>> 
>>> Hi, I wrote it up:
>>>
>>> https://datatracker.ietf.org/doc/draft-sayre-gendispatch-derivative/
>> Thanks for writing that.
>> I don't think it make sense to permit I-D's to prohibit derivative
>> works
>> and at the same time forbid presentation or e-mail posts about the I-D
>> to use the same clause.  It seems hard to discuss or present a
>> no-derivative I-D in a presentation that can be derived by others and
>> re-used in other's Contributions.  The policy should be consistent
>> regardless of the form of contribution, which I believe it currently is.
>> Thus, let me propose something stronger: forbid the no-derivative
>> rights
>> clause completely, for all Contributions.
>> I wonder what people think about that?
>> Has it been a net-win for the IETF to permit Contributions under the
>> no-derivative rights clause?  The approach was designed in a different
>> era, where (IIRC) external SDOs/people could gauge IETF-interest for
>> some piece of work without giving up rights.
>> I still think no-derivative rights contributions may be useful, so
>> I'm
>> not sure it is possible to reach consensus to kill the concept.  Scott
>> Bradner has explained earlier some of the original rationale, and I
>> think that had a point.
>> /Simon
>> 
>>> I'm happy for anyone to take that off my hands and create a derivative work.
>>>
>>> In off-list discussion, it was clarified that Section 3 and Section 4 are
>>> non-normative.
>>>
>>> thanks,
>>> Rob
>
signature.asc (application/pgp-signature, 1.2 KB)
-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmn8PFYUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4fWRBQkOa+rdAAoJENc89jjFPAa+hWIA
/1lQvrJeGlQq50lP6tm99D1zDy7J1tQ3ha4x0Jx7rkFTAP9hpUKuTvm6m1fXyiZV
YZlu2+Id/Dq3CIAZvNF+XEr2BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCaeCW1wUJDmqLVgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+s7AA+gIIHpBApDpcDj1sKhzDngmpvwQf0VkHme6s+EG7qSgpAQDe
/XMrU0c0Pa3ji85cMqZhvzJOFI/soe662lzL0QY3Bbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4JbXBQkOaottAAoJENc89jjF
PAa+RNUA/2faQO/nFT06E+MlhlQdo/0chlQXC5TZMPTVvVBFwoLOAP9xLJK0ow5E
jTzYJB4K810AL/Iv6PEOAEgA4cPTHVlbCQAKCRBRcisI/kdFovhSAP9DC77Lh1Fw
qpnzoNkj11nQEja8eyWSAxW/b0yIpTHDgAEA2t7bVPDVb5C+L+lffqACTS8+mUSb
9ifl87KC3DLR6gY=
=+SIs
-----END PGP SIGNATURE-----