![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Dec 15, 2008, at 5:14 AM, Simon Josefsson wrote:
"AJ Jaghori" <ciscoworkz at gmail.com> writes:Modifying an author's original work without specified permission; regardless of new findings, constitutes a copyright infringement.Sure, but the old RFC copyright license (e.g., RFC 2026 and RFC 3978) gave IETF participants the necessary rights to allow modifications of earlier IETF work within the IETF standard process. The new one doesn't, and the consequences of that situation is what's discussed.
My understanding (IANAL and other warning apply) is that the newlicense does do this, inside the IETF. It's grants to other organizations which is the issue.
Regards Marshall
/SimonOn 12/13/08, Christian Huitema <huitema at windows.microsoft.com> wrote:You can improve any technology you want, modulo IPR -- that's not the point here. The problem is taking existing copyrighted text and usingit as a base for describing your technology.That's indeed the problem we stumbled upon years ago. Suppose that acontributor has written a complete description of technology X, getting it published as a 100 pages RFC. A remarkable feat, and a great contribution to the community. A few years letter, the working group realizes that they like the technology, but would like to change a couple options. That normally translates into changing a paragraph or two, resulting in a new RFC, morethan 90% identical to the previous one.Suppose now that for whatever reasons, the original author disagrees with the changes, or with the new management of the working group, or with thenew editor. People are human, these things do happen. IANAL, but myunderstanding at the time was that the original copyright still applied to the original text, and that the working group would be left with only bad options. They could issue a delta RFC that only contained the modifications, but that is somewhat confusing for the readers. Or they could undertake a complete rewriting of the standard, but that takes a long time and is alsoprone to errors and confusion.This is very much why we got the statement on copyrights in RFC 1602, in 1996. You will notice that copyrights were only mentioned as something we might need to worry about later in the appendix of the previous rules, RFC1310 published in 1992. -- Christian Huitema _______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf_______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.