Harald Alvestrand wrote:
>
> The working group's non-consensus on this point is documented in section
> 4.4 of RFC 5377:
>...
... of historical interest only, IMHO...
> The "RFC 5378" license to the trust allows, for instance, the Trust to
> grant the right of copying small snippets of co
Date:Wed, 22 Jul 2009 08:32:38 +0200
From:Harald Alvestrand
Message-ID: <4a66b286.9080...@alvestrand.no>
I don't want to say much more on this issue, I suspect enough has
been said now, but just one final (from me) point ...
| The working group's non-consensus on t
Robert Elz wrote:
Date:Tue, 21 Jul 2009 18:40:52 +0200
From:Harald Alvestrand
Message-ID: <4a65ef94.2050...@alvestrand.no>
| I'm afraid that your perception disagrees with the structure that RFC
| 5378 set up.
I was misunderstanding what's going on, Joel has
Date:Tue, 21 Jul 2009 18:40:52 +0200
From:Harald Alvestrand
Message-ID: <4a65ef94.2050...@alvestrand.no>
| I'm afraid that your perception disagrees with the structure that RFC
| 5378 set up.
I was misunderstanding what's going on, Joel has been educating me off
On Tue, Jul 21, 2009 at 03:35:31PM -0400, Joel M. Halpern wrote:
> Without creating needless FUD, let me say that someone did recently
> point out possible implications of the BSD license that we did not
> intend. Fairly awkward implications.
> 1) It may well be possible to fix that with a cl
No matter what, we have to be clear in our records about when things
change, and folks who extract things need to somehow record when they
did so. That is actually true no matter what, since once the code is
extracted, without some backtrace there is no way verify things. I
would expect folks
Yes, I believe that there is a real world example.
Without creating needless FUD, let me say that someone did recently
point out possible implications of the BSD license that we did not
intend. Fairly awkward implications.
1) It may well be possible to fix that with a clarification.
2) But sup
On Tue, 21 Jul 2009, Joel M. Halpern wrote:
The text we are discussing is only about what license we require other folks
to put on code they extract from an RFC.
And, even more specifically, it is only about how we describe that license in
the event that we want to change forward-going extr
On Tue, Jul 21, 2009 at 03:07:15PM -0400, Joel M. Halpern wrote:
> And, even more specifically, it is only about how we describe that
> license in the event that we want to change forward-going extractors.
I think it is exactly this premise that some are wondering about. Is
there any circums
The folks contributing the code have a different constraint. They ahve
agreed separately to let the IETF have all rights to do anything we want
with the source, including giving it to anyone else, and giving them any
rights we want.
(Note, this is copyright related rights only. This has nothin
What are we smoking? The license can't be changed after the RFC is
published. At least, it can't be made more restrictive. I can't imagine
the chaos if one must prove your right to follow a particular set of
license rules based on proving exactly when you extracted code from a
published RFC.
I think Andrew makes a lot of sense. I really can't envision a situation where
the IETF would want to change licence terms en masse, given the impact Andrew
demonstrates on deployed or ready-to-deploy product.
Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern wro
Robert Elz wrote:
Date:Tue, 21 Jul 2009 08:57:01 +0200
From:Harald Alvestrand
Message-ID: <4a6566bd.1080...@alvestrand.no>
| We have two possibilities:
|
| 1 - the update consists of revisions of *every single RFC* that
| references the BSD license
| 2 -
Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote:
We have two possibilities:
1 - the update consists of revisions of *every single RFC* that
references the BSD license
2 - some RFCs continue to carry the BSD license, even while the "real"
current l
On Tue, Jul 21, 2009 at 10:52:30AM -0400, Joel M. Halpern wrote:
> Clearly, any change in IETF policy can not change the text in an RFC.
Only if by "the text" you exclude all the implicitly included text
that is the resolution of a pointer in "the text" strictly construed.
If the actual text sa
On Jul 21, 2009, at 10:27 AM, Andrew Sullivan wrote:
On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote:
We have two possibilities:
1 - the update consists of revisions of *every single RFC* that
references the BSD license
2 - some RFCs continue to carry the BSD license, even w
NO, I believe he is suggesting something slightly different.
First, realize that the structure does not include any license statement
with the code in the RFC. That is covered by the boilerplate.
Second, the issue being addressed is the instruction to someone who
extracts the code from the R
On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote:
> We have two possibilities:
>
> 1 - the update consists of revisions of *every single RFC* that
> references the BSD license
> 2 - some RFCs continue to carry the BSD license, even while the "real"
> current license is differen
Date:Tue, 21 Jul 2009 08:57:01 +0200
From:Harald Alvestrand
Message-ID: <4a6566bd.1080...@alvestrand.no>
| We have two possibilities:
|
| 1 - the update consists of revisions of *every single RFC* that
| references the BSD license
| 2 - some RFCs continue
Andrew Sullivan wrote:
On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote:
Rather, what it does is the RfC says "the code must include whatever
license the trust document says.
When the code is produced, that link is dereferenced, the license is
determined, and the license is
On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote:
> Rather, what it does is the RfC says "the code must include whatever
> license the trust document says.
> When the code is produced, that link is dereferenced, the license is
> determined, and the license is inserted in the code
I don't think it means that.
Rather, what it does is the RfC says "the code must include whatever
license the trust document says.
When the code is produced, that link is dereferenced, the license is
determined, and the license is inserted in the code.
No, no one can reasonably produce code un
On Mon, Jul 20, 2009 at 02:19:24PM -0400, Contreras, Jorge wrote:
>
> I also think that Harald's alternate language would work.
Is it a problem that this means that shipping code's license could
change at some time in the future? Are there practical issues to that
if (for instance) the Trust d
ab.org; i...@ietf.org
> Subject: Re: [Trustees] Objection to reworked para 6.d (Re:
> Rationale for Proposed TLP Revisions)
>
> I think that the alternate text proposed by Harald meets the current
> need without constraining the future.
>
> Russ
I also think that Harald's
24 matches
Mail list logo