[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New version of my proposal posted
Black_David at emc.com writes:
> Simon,
>
>> > I talked to one of EMC's lawyers about this. The lawyer suggests that
>> > any automatic grant of copyright for anyone to make derivative works be
>> > limited [to] a specific field of use, namely implementation of the
> original
>> > unmodified RFC from which the text was derived.
>
>> However, I see two problems here. The first is philosophical, and the
>> second is practical.
>
> I disagree with an important aspect of the philosophy, and believe that
> the practical issue is actually not a problem in practice because it's
> based on the (IMHO incorrect) assumption that clarifications and
> corrections require a new RFC.
I have not assumed that.
Clarifications and corrections do, however, require contacting the
IETF and publishing the update.
If the matter is security sensitive, waiting weeks (not to speak of
the months that a RFC Errata take to publish) is not workable. While
you could solve that problem by speeding up the process, I think the
principle here is flawed. That's why I'm arguing for reverting to the
RFC 2026 copying conditions, or even improving them to be compatible
with free software licenses and policies, when we are re-visiting this
area anyway.
If the modifications are non-essential for the IETF -- i.e., removing
a column in a table with forward references -- then I believe it would
be flooding the I-D editor with work to publish every minor
modification I make to RFCs when I incorporate them into my manual.
>> Philosophical: I believe granting the right to modify RFCs lead to a
>> better working Internet, and better standards, in the long run.
>> The reason is that people can build on past protocols and make
>> minor changes to adapt it to their needs, and make a product. If
>> the implementation gain market shares, it may eventually be useful
>> to standardize the protocol in IETF, but standardizing shouldn't be
>> required before deploying a product that include a modified
>> protocol description. Historically, implementations preceded IETF
>> standardization, and from the protocols I'm involved in, this is
>> often the case.
>
> The place where I part company with this philosophy is the desire to
> make RFC modifications outside the IETF. IMHO, the right approach to
> doing the sort of thing described here is to make the modifications to
> the RFC and submit the result as an Internet-Draft, taking advantage of
> the fact that unlimited derivative works are allowed within IETF. As
> long as the new Internet-Draft uses the unrestricted boilerplate, the
> text should then be usable in the fashion desired, but must (correctly)
> be cited as coming from the Internet-Draft.
Please re-read my draft, and in particular the example usages. We are
talking about modifications that are done to adapt the RFC text into a
particular manual or (in the case of ASN.1 compilers or C header
files) a particular environment.
I can make a script that will send the I-D editor a copy of my GSS-API
header file whenever it is modified in my CVS repository. I doubt the
IETF would find any value in that. Yet, it appears to be the
consequence of what you propose.
> There are two crucial results from this that do not occur when the RFC
> is modified outside IETF:
> (1) The IETF then knows about the modification up front. The technical
> community involved might even be able to improve on the
> modification.
Again, the modifications I'm talking about include non-essential
modifications, to adapt the work for a particular environment. Why
are such modifications useful to publish in the IETF?
> (2) Users of the software is not misled into believing that the
> modified implementation conforms to/complies with the original RFC.
> The latter is fairly important, as engaging in that sort of misleading
> behavior (saying something is an implementation of the RFC when it is
> not) is usually called "fraud". It's certainly fine to describe the
> new Internet-Draft as (in the draft author's opinion) an improvement to
> the original RFC.
I strongly disagree that copying conditions should regulate this. I
think you are inventing arguments here. If somebody would imply their
modified work is a work of the IETF, that is fraud and should be dealt
with as such. Liberating copying conditions will not lead to a free
haven for fraudsters. These are two orthogonal issues.
We have already explained that copying conditions do not protect
against this scenario anyway. Anyone can write a specification and
claim it is the work of the IETF without basing their effort on an
existing RFC. I don't believe copying conditions are the legal
instrument you want to use here.
It is particularly bad to use restrictive copying conditions to
prevent frauds because of the consequences that has for free software
developers.
>> Practical: RFCs are frequently ambiguous and sometimes they even
>> contain errors or internally inconsistent descriptions. A recent
>> example is the Unicode 3.2 NFKC algorithm which IDN is using. When
>> implementing a RFC, it is sometimes necessary to make an
>> interpretation of the text, because it is not fully specified. I
>> believe implementers must have the right to make these
>> interpretations, without consulting a IETF consensus on what the
>> correct interpretation is, before deploying their product. Waiting
>> for the IETF to revise and update a RFC before they can finish
>> implementing their product is ridiculous.
>
> There are actually two different situations here:
> a) Interpretations, clarifications, etc. would be within the "field of use"
> of implementation of the original RFC, and hence would be covered
> under the proposed automatic grant of copyright.
Which grant are you talking about here? BCP 78 does not include
anything like that. RFC 2026 did.
> b) Actual errors need to be reported as errata, even though the RFC Editor
> has not been doing a good job on these lately. Once the RFC Editor
> publishes a correction as an errata, the correction then falls
> under the unlimited distribution of the unmodified RFC (i.e., it
> no longer counts as a "derived work").
Right.
You are forgetting about modifications that are not essential to the
protocol, and that are not interesting for the IETF. Such
modifications can be substantial, yet they are uninteresting to the
IETF. These modifications can be made because an ASN.1 schema had to
be rewritten to be compatible with a particular ASN.1 compiler. Etc.
> In neither case would a revised and/or updated RFC (and the time involved
> in getting it published) be required.
I don't believe I have claimed that it would be required.
Concluding, I don't think you have shown that restrictive copying
conditions further the goals of the IETF. I believe permitting
modifications of the RFCs, even beyond what RFC 2026 permit, would be
a good thing in the long run. The dangers that have been expressed --
that someone claim their modified RFC is the real thing -- can be
dealt with, and has been dealt with for decades within the software
industry. You can't take someone's software, modify and claim that it
is the original author's work.
Thanks,
Simon
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> black_david at emc.com Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>> -----Original Message-----
>> From: Simon Josefsson [mailto:jas at extundo.com]
>> Sent: Friday, November 04, 2005 9:22 AM
>> To: Black, David
>> Cc: ipr-wg at ietf.org
>> Subject: Re: New version of my proposal posted
>>
>> Black_David at emc.com writes:
>>
>> > Simon,
>> >
>> >> 2) Examples of problems has been listed for problem #1, i.e., that BCP
>> >> 78 disallow derivative works that were permitted under RFC 2026. I
>> >> also expanded slightly on the discussion regarding this problem.
>> >> Being able to take portions of RFCs, modify them and send to the
>> >> RFC errata appear to be another example, but I didn't have time to
>> >> add it.
>> >
>> > I talked to one of EMC's lawyers about this. The lawyer suggests that
>> > any automatic grant of copyright for anyone to make derivative works be
>> > limited a specific field of use, namely implementation of the original
>> > unmodified RFC from which the text was derived.
>>
>> David,
>> That appear to be what RFC 2026 said (in "and derivative works that
>> [...] assist in its implmentation [sic] may be prepared, copied [...]
>> without restriction of any kind"). RFC 3978 removed that right.
>>
>> > This addresses all five of the examples in your draft while clearly
>> > blocking someone who makes a minor incompatible change to the RFC,
>> > as the incompatibility places the result outside the field of use,
>> > hence blocking the automatic grant of copyright (which is the
>> > desired outcome).
>>
>> This argument sound compelling, and in a perfect world, it might work.
>>
>> However, I see two problems here. The first is philosophical, and the
>> second is practical.
>>
>> Philosophical: I believe granting the right to modify RFCs lead to a
>> better working Internet, and better standards, in the long run.
>> The reason is that people can build on past protocols and make
>> minor changes to adapt it to their needs, and make a product. If
>> the implementation gain market shares, it may eventually be useful
>> to standardize the protocol in IETF, but standardizing shouldn't be
>> required before deploying a product that include a modified
>> protocol description. Historically, implementations preceded IETF
>> standardization, and from the protocols I'm involved in, this is
>> often the case.
>>
>> Practical: RFCs are frequently ambiguous and sometimes they even
>> contain errors or internally inconsistent descriptions. A recent
>> example is the Unicode 3.2 NFKC algorithm which IDN is using. When
>> implementing a RFC, it is sometimes necessary to make an
>> interpretation of the text, because it is not fully specified. I
>> believe implementers must have the right to make these
>> interpretations, without consulting a IETF consensus on what the
>> correct interpretation is, before deploying their product. Waiting
>> for the IETF to revise and update a RFC before they can finish
>> implementing their product is ridiculous.
>>
>> I wouldn't agree that the RFC 2026 license fully solve the problems
>> listed in my draft. It may solve many practical instances of the
>> problems, but not all.
>>
>> > The right to reproduce and distribute an RFC without modification
>> > should remain unlimited.
>>
>> Right. I don't anyone dispute that.
>>
>> > Beyond this, for situations like the one I described in a previous
>> > message, I prefer Scott's approach of acquiring sufficient rights to
>> > enable the IESG to permit derivative works outside the IETF
>> when that
>> > is the proverbial "right thing to do".
>>
>> As far as I understand -- there is a lack of public information about
>> the relationship between the IETF and the IPR Trust -- the IESG
>> doesn't have that right either. Only the IAOC members will have that
>> right, because they control the IPR Trust. See
>> <http://www1.ietf.org/mail-archive/web/ietf-announce/current/m
>> sg01603.html>,
>> specifically:
>>
>> ,----
>> | The Trustees will be the members of the IAOC.
>> ...
>> | The Trust (acting through the Trustees) shall have the
>> right to grant
>> | licenses for the use of the Trust Assets on such terms, as
>> the Trustees
>> | deem appropriate; provided, however, that the Trust shall
>> not grant any
>> | license that would be deemed a transfer of ownership or
>> abandonment of any
>> | Trust Assets under applicable law.
>> |
>> | Initial contributed IPR shall be (as far as the parties'
>> rights extend):
>> |
>> | - Trademarks
>> | - Domain names
>> | - Current databases, mailing lists, web pages, working group
>> | and IESG materials
>> | - Current I-Ds and RFCs
>> | - Rights in extracted historical data (records of past meetings,
>> | past I-Ds and RFCs and their processing history)
>> `----
>>
>> I also note that this would include past I-Ds and RFCs, which if I
>> understood Jorge correctly, would be legally questionable. It doesn't
>> seem like the IPR Trust would have the rights to grant others rights
>> to past I-Ds or RFCs.
>>
>> Regards,
>> Simon
>>
_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg