At Mon, 12 Jan 2009 19:27:02 -0500,
Ed Juskevicius wrote:
Eric, Thank You for your comments and for your suggestions (below)
I like your proposal for how to clarify and improve the wording of the draft
legend text.
Thanks.
Can you advise as to when the community can expect to see a
Eric,
Thank you for the careful reading and constructive suggestions.
This document contains material from IETF Documents or IETF
Contributions published before November 10, 2008 and, to the
Contributor?s knowledge, the person(s) controlling the
copyright in
such material
So what I hear (and for the benefit of others, let me note that you
and I have ha a fairly detailed discussion privately that I think I am
summarizing the result of) is that you want a short term solution and
a long term solution. The short term solution would be adequately
solved by using
Eric, Thank You for your comments and for your suggestions (below)
I like your proposal for how to clarify and improve the wording of the draft
legend text.
Best Regards,
Ed J.
-Original Message-
From: trustees-boun...@ietf.org [mailto:trustees-boun...@ietf.org] On Behalf
Of Eric
Theodore Tso ty...@mit.edu writes:
On Sat, Jan 10, 2009 at 02:37:50PM +0100, Simon Josefsson wrote:
We do have precedent for include code that has explicit open source
licensing rights. For example, the MD5 implementation in RFC 1321 has
an explicit BSD-style license.
Sure, but under
Let's be quite clear here.
Your stated requirement for doing this was that authors had to be able
to take and modify any text from anywhere in an RFC.
The Working Group concluded that while that was reasonable relative to
code (and we tried to give the open source community that ability
--On Sunday, January 11, 2009 10:28 -0500 Joel M. Halpern
j...@joelhalpern.com wrote:
Also, it should be understood that this issue is largely
orthogonal to the topic under discussion. The working group
could have included what Simon asked for in 5377. The rough
consensus of the WG was
On Sun, Jan 11, 2009 at 04:09:54PM +0100, Simon Josefsson wrote:
I would agree with you for the 2-3 sentences scenario, but that's
missing my point. I would fully disagree when it comes to 2-3
paragraphs, 2-3 pages, or entire I-D's. I believe the latter is the
reality with several free
Lawrence Rosen wrote:
John Leslie wrote:
I may not be the one to explain, but I _don't_ think that's what
the proposal calls for. I think it calls for inclusion of the
boilerplate I listed above, which simply disclaims knowledge of
_whether_ all the rights of 5378 are granted (and thus
Joel M. Halpern j...@joelhalpern.com writes:
Let's be quite clear here.
Your stated requirement for doing this was that authors had to be able
to take and modify any text from anywhere in an RFC.
No, that's a different issue. Being able (as RFC author) to include
code not written by IETF
Theodore Tso ty...@mit.edu writes:
On Sun, Jan 11, 2009 at 04:09:54PM +0100, Simon Josefsson wrote:
I would agree with you for the 2-3 sentences scenario, but that's
missing my point. I would fully disagree when it comes to 2-3
paragraphs, 2-3 pages, or entire I-D's. I believe the latter is
On Fri, Jan 09, 2009 at 02:16:43PM -0800, Lawrence Rosen wrote:
That's why I challenged Ted Hardie directly. Please don't take it personally
or as flaming, but anyone who wants to assert a private ownership right in
any copyright in any IETF RFC ought to do so now or forever hold your peace.
Joel M. Halpern j...@joelhalpern.com writes:
My own take has been that the code reuse problem is the dominant
problem.
My interpretation has been that the problem has been (and remain) that
the license on IETF documents is incompatible with free software
licensing, which is counter-productive
On Sat, Jan 10, 2009 at 02:37:50PM +0100, Simon Josefsson wrote:
We do have precedent for include code that has explicit open source
licensing rights. For example, the MD5 implementation in RFC 1321 has
an explicit BSD-style license.
Sure, but under the post-RFC 2026 rules that would not
Bill Manning wrote:
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026 except that the right to produce derivative works
is not granted.
- and -
So for some IETF work product, there are/were people who assert a
private ownership right in the
+1
It seems to me that we are spending a great deal of energy on
non-problems (including the one Ted discusses below) and too
little time on real issues... like how to encourage people to do
real work around here (where requiring authors try to figure out
who might have contributed parts of a
Ted,
On 2009-01-11 08:10, Theodore Tso wrote:
...
If the
goal is to allow code to be allowed in Open Source Software, then
requiring a maximally compatible OSS license for code makes sense.
But requiring for random protocol text, especially if this is going to
make reuse of older RFC's
--On Saturday, January 10, 2009 11:17 -0800 Lawrence Rosen
lro...@rosenlaw.com wrote:
...
For the lawyers on here, I'm hoping that silence now,
particularly by the major IETF contributors on this list, will
be interpreted as laches or waiver if one of them later claims
an exclusive
On Sat, Jan 10, 2009 at 11:17:47AM -0800, Lawrence Rosen wrote:
Bill Manning wrote:
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026 except that the right to produce derivative works
is not granted.
- and -
So for some IETF work product,
At 13:13 09/01/09, Brian E Carpenter wrote:
On 2009-01-09 13:59, Stephen Farrell wrote:
+1 to fred's proposal, let the exceptions be just that and don't bother
most I-D authors,
Stephen.
On 8 Jan 2009, at 22:49, Fred Baker f...@cisco.com wrote:
You asked me to make this comment publicly,
On Jan 9, 2009, at 5:42 AM, Martin Duerst wrote:
At 13:13 09/01/09, Brian E Carpenter wrote:
On 2009-01-09 13:59, Stephen Farrell wrote:
+1 to fred's proposal, let the exceptions be just that and don't
bother
most I-D authors,
Stephen.
On 8 Jan 2009, at 22:49, Fred Baker f...@cisco.com
Martin Duerst due...@it.aoyama.ac.jp writes:
WHO exactly are we supposed to get permissions from.
The situation of a deceased author is a tought one, but it's an
obvious one. But I haven't seen any clear answer to whether
permission from all the authors/editors (the people listed in
the
On Jan 9, 2009, at 10:16 AM, Thomas Narten wrote:
Martin Duerst due...@it.aoyama.ac.jp writes:
WHO exactly are we supposed to get permissions from.
The situation of a deceased author is a tought one, but it's an
obvious one. But I haven't seen any clear answer to whether
permission from
--On Friday, January 09, 2009 10:16 -0500 Thomas Narten
nar...@us.ibm.com wrote:
Martin Duerst due...@it.aoyama.ac.jp writes:
WHO exactly are we supposed to get permissions from.
The situation of a deceased author is a tought one, but it's
an obvious one. But I haven't seen any clear
John Leslie wrote:
I may not be the one to explain, but I _don't_ think that's what
the proposal calls for. I think it calls for inclusion of the
boilerplate I listed above, which simply disclaims knowledge of
_whether_ all the rights of 5378 are granted (and thus derivative
works outside
At 11:09 AM -0800 1/9/09, Lawrence Rosen wrote:
We should accept the notion that IETF, and
now the IETF Trust, as a public interest corporation that manages the
expressive creative activities through which these joint works are written,
is the joint owner of copyright in every RFC. As such, a
Ted Hardie asked me:
Are you willing to personally indemnify the individuals who are later
sued by those who don't hold this view or are you willing to pay for
the appropriate insurance cover?
Of course not. Are you (or your company) warning me that *you* might sue me
for infringement of
At 12:34 PM -0800 1/9/09, Lawrence Rosen wrote:
Ted Hardie asked me:
Are you willing to personally indemnify the individuals who are later
sued by those who don't hold this view or are you willing to pay for
the appropriate insurance cover?
Of course not. Are you (or your company) warning me
--On Friday, January 09, 2009 11:42 -0800 Ted Hardie
har...@qualcomm.com wrote:
...
My reading of John's point is that this creates either a
coordination burden or a legal risk for the authors re-using
text created prior to the new rules. He doesn't want to bear
that burden/risk, and I
John,
On 2009-01-10 10:32, John C Klensin wrote:
...
And note that makes a clear and plausible transition model:
(1) Pre-5378 documents exist under pre-5378 rules, so
any potential user for non-traditional purposes needs to
either figure out who the relevant authors are
John Klensin wrote:
Note 2: Larry, I'm not competent to debate your joint
authorship theory and hope that no one else, at least no one
who is not an attorney admitted to practice in some relevant
jurisdiction, will engage you on it. However, it appears to me
as a non-lawyer that, if you are
ned+i...@mauve.mrochek.com wrote:
This is EXACTLY the approach we should be using: Formulate a set of goals, get
agreement on them, and only then ask the laywers to turn that informal
specification into competent legalese.
...
The difference was like night and day.
+1
That matches my
--On Saturday, January 10, 2009 11:07 +1300 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
Thanks John, I believe that is an excellent summary of the
viable options. My draft implicitly adds
(2.5) Post-5378 documents that incorporate pre-5378
materials whose original
My own take has been that the code reuse problem is the dominant
problem. Document transfer outside the IETF is sufficiently rare that I
would agree with Fred that not solving that is fine.
This also means that from my personal perspective, a solution that says
(loosely based on a suggestion
--On Friday, January 09, 2009 15:25 -0800 Dave CROCKER
d...@dcrocker.net wrote:
ned+i...@mauve.mrochek.com wrote:
This is EXACTLY the approach we should be using: Formulate a
set of goals, get agreement on them, and only then ask the
laywers to turn that informal specification into
On Fri, Jan 09, 2009 at 06:52:40PM -0500, Joel M. Halpern wrote:
My own take has been that the code reuse problem is the dominant
problem. Document transfer outside the IETF is sufficiently rare that I
would agree with Fred that not solving that is fine.
If it really is the case that the
36 matches
Mail list logo
