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 i
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 Li
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
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
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: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
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
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
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
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 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
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
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
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 -
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
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 nothin
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
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
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
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
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
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
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: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
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
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 collecte
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: fo
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
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 somebody
>> explain
At 08:25 AM 7/20/2009, John C Klensin wrote:
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
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 BS
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
wrote:
> At 08:25 AM 7/20/2009, John C Klensin wrote:
>
>
>> --On Monday, July 20, 2009 14:20 +0200 Julian Reschke
>> wrote:
>>
>> > Julia
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 the
John C Klensin wrote:
--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
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 so
33 matches
Mail list logo
