Robert Elz wrote:
Date:Tue, 21 Jul 2009 18:40:52 +0200
From:Harald Alvestrand har...@alvestrand.no
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
Harald Alvestrand har...@alvestrand.no 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
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
Date:Tue, 21 Jul 2009 08:57:01 +0200
From:Harald Alvestrand har...@alvestrand.no
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 -
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 different.
1
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
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
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 says,
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
Robert Elz wrote:
Date:Tue, 21 Jul 2009 08:57:01 +0200
From:Harald Alvestrand har...@alvestrand.no
Message-ID: 4a6566bd.1080...@alvestrand.no
| We have two possibilities:
|
| 1 - the update consists of revisions of *every single RFC* that
| references the
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
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.
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
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
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
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
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
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
Date:Tue, 21 Jul 2009 18:40:52 +0200
From:Harald Alvestrand har...@alvestrand.no
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
: [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 alternate language would work. The sentence
in question
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
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
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.
23 matches
Mail list logo