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
Harald Alvestrand wrote:
...
Hi,
I'm trying to understand whether this change affects me.
So...
1) Many specs I'm editor of contain ABNF. Does it need to be labeled as
code component (I believe not).
2) These specs also collect all ABNF fragments into an appendix,
containing the
Apologies for this being a month late.
From the rationale:
4.e -- this new section clarifies the legend requirements for Code
Components that are used in software under the BSD License.
In short, the user must include the full BSD License text or a shorter
pointer to it (which is set forth
Julian Reschke wrote:
...
3) If I *extract* ABNF from these documents (such as for the purpose of
generating an input file for an ABNF parser), do I need to include the
BSD license text? If so, can somebody explain how to do that given the
constraints of the ABNF syntax?
...
Explanation:
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
julian.resc...@gmx.de wrote:
Julian Reschke wrote:
...
3) If I *extract* ABNF from these documents (such as for the
purpose of generating an input file for an ABNF parser), do
I need to include the BSD license text? If so, can
I think that the alternate text proposed by Harald meets the current
need without constraining the future.
Russ
Apologies for this being a month late.
From the rationale:
4.e -- this new section clarifies the legend requirements for Code
Components that are used in software under the BSD
At 08:25 AM 7/20/2009, John C Klensin wrote:
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
julian.resc...@gmx.de wrote:
Julian Reschke wrote:
...
3) If I *extract* ABNF from these documents (such as for the
purpose of generating an input file for an ABNF parser), do
I need to
You are correct. I remembered the text differently, but should
have checked. I apologize.
john
--On Monday, July 20, 2009 12:23 -0400 Russ Housley
hous...@vigilsec.com wrote:
At 08:25 AM 7/20/2009, John C Klensin wrote:
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
Julian Reschke wrote:
Harald Alvestrand wrote:
...
Hi,
I'm trying to understand whether this change affects me.
So...
1) Many specs I'm editor of contain ABNF. Does it need to be labeled
as code component (I believe not).
In my understanding, all ABNF is code by definition (included in
John C Klensin wrote:
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
julian.resc...@gmx.de wrote:
Julian Reschke wrote:
...
3) If I *extract* ABNF from these documents (such as for the
purpose of generating an input file for an ABNF parser), do
I need to include the BSD
: [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.
32 matches
Mail list logo
