Suggested text for text vs code

"Lawrence Rosen" <lrosenrosenlaw.com> writes:

>> This sounds similar to the reasoning I have for
opposing
>> author-specific, and especially viral, licensing in
IETF documents.
>
> I don't know what you mean by
"author-specific" licensing. 
>
> So-called "viral" licenses (I prefer the term
"reciprocal" as being less
> associated with disease states), even though they are
wonderful for
> encouraging free software and discouraging free riders,
are also
> incompatible with open standards. That is because open
standards must be
> available for implementation in proprietary software
also.
>
> If someone here is proposing allowing reciprocal
licenses for either IETF
> contributions or IETF out-licensing, I vote -1 on that
too.

The point is, as far as I understand, that the IETF rules
should
_permit_ authors to use code licensed under a share-alike
license as
examples in documents.

Of course, having code available under a more liberal
license,
e.g. the BSD license, is preferable.  Several code examples
in RFCs
use similar licenses, and I expect that to be the norm.

However, I believe it doesn't make sense to decrease the
quality of a
specification by removing code that is only available under,
say, the
GPL.  That works against the goals of the IETF of having
specifications implemented widely and quickly.  Some code is
better
than no code in a document.

Code in older RFCs, licensed under a license that nobody can
use
legally, is still helpful when developing a new
implementation.  The
license is unfortunate, and I don't believe we should permit
it in
future RFCs, but not being able to use widely available
GPL'ed code as
examples seems like a mistake to me.

I'll vote to permit reciprocal licenses, but will suggest
that when
there is a choice, a BSD-licensed implementation should be
preferred.
It is for the cases where there isn't a choice a GPL
implementation
would be useful to be able to include.

/Simon

> /Larry
>
>
>> -----Original Message-----
>> From: David B Harrington [mailto:dbharringtoncomcast.net]
>> Sent: Wednesday, December 06, 2006 3:37 PM
>> To: lrosenrosenlaw.com; ipr-wgietf.org
>> Subject: RE: Suggested text for text vs code
>> 
>> Hi Larry,
>> 
>> This sounds similar to the reasoning I have for
opposing
>> author-specific, and especially viral, licensing in
IETF documents.
>> 
>> I don't want WGs and companies trying to implement
standards to be
>> forced to waste time trying to divine which piece
of a document has a
>> author-specific (possibly viral) license associated
with it, and I
>> certainly do not want contribution of a code
snippet to allow the
>> author of that snippet to impose viral licensing
for the whole IETF
>> document.
>> 
>> dbh
>> 
>> > -----Original Message-----
>> > From: Lawrence Rosen [mailto:lrosenrosenlaw.com]
>> > Sent: Wednesday, December 06, 2006 4:33 PM
>> > To: ipr-wgietf.org
>> > Subject: RE: Suggested text for text vs code
>> >
>> > > That wouldn't result in a document that
explains that we've made a
>> > > decision about separating licenses for
text and code.  If I
>> > understand
>> > > correctly, Harald said there was
consensus that there needs to be
>> > > different licenses for text and code. 
(And I'm not disputing that
>> > > consensus...)  Explicitly reflecting that
decision in the document
>> > > would be useful as a trail of what the WG
has discussed and
>> decided.
>> >
>> > This confusion is why I keep insisting people
should license
>> > "original works
>> > of authorship" to IETF for open standards
rather than some
>> > imprecise IETF
>> > invention purporting to distinguish between
text and code.
>> > (See [1] and
>> > [2].)
>> >
>> > It is a waste of time to change code (for
whatever open source or
>> > proprietary reason!) embodying an IETF
standard and then not
>> > be able to
>> > change the IETF-published text that explains
that code. Placing this
>> > unnecessary burden on recipients of IETF's
open standards
>> > documentation is a
>> > penalty that serves no valid purpose yet
identified and
>> > endorsed by this WG.
>> >
>> >
>> > When any of us give our copyrighted (and
perhaps patented)
>> > works to IETF in
>> > collaboration with others for the creation of
industry standards, we
>> > shouldn't want people sitting around in
working groups trying
>> > to divine what
>> > the difference is between code and text in
IETF draft
>> > specifications, and
>> > then waste more time documenting such
hair-splitting in the
>> published
>> > official IETF specifications themselves, and
even more time within
>> the
>> > companies that implement those specifications
trying to
>> > decide what they can
>> > use and what they can't.
>> >
>> > To the extent that this suggestion to
distinguish code from
>> > text came up for
>> > a vote before, but is still pending, I vote
-1.
>> >
>> > /Larry Rosen
>> >
>> > [1] 17 USC 102, first sentence, at
>> > http://www.law.cornell.edu/uscode/html/uscode17/us
c_sec_17_000
>> > 00102----000-.
>> > html.
>> >
>> > [2] AFL 3.0, first sentence, at
www.rosenlaw.com/AFL3.0.htm.
>> >
>> >
>> > > -----Original Message-----
>> > > From: Simon Josefsson [mailto:simonjosefsson.org]
>> > > Sent: Wednesday, December 06, 2006 8:53
AM
>> > > To: Joel M. Halpern
>> > > Cc: ipr-wgietf.org
>> > > Subject: Re: Suggested text for text vs
code
>> > >
>> > > "Joel M. Halpern" <joelstevecrocker.com> writes:
>> > >
>> > > > My understanding of my instructions
from San Diego was to
>> > be explicit
>> > > > in the section about code rights
that these were distinct
>> > from text
>> > > > rights.
>> > >
>> > > Good!  Then my suggested text to be
explicit about the separation
>> of
>> > > licenses code should be
non-controversial.
>> > >
>> > > > And that I was to document that
>> > > > a) the code rights applied to any
sections of RFCs which
>> > were of the
>> > > > form X, Y, Z, W.  A specific list of
cases.
>> > > > b) That the trust would define a way
of marking portions
>> > of RFCs as
>> > > > code so that if there were other
things that the WG
>> > concluded needed
>> > > > to be treated as code (such as a
RelaxNG schema if I don't
>> include
>> > > > that in the list above), the the
working group can
>> > indicate that the
>> > > > code rights apply to that section as
well.
>> > > >
>> > > > I much prefer being explicit in the
right place about
>> > what the rights
>> > > > apply to, rather than putting a
general description up at
>> > the front.
>> > >
>> > > That wouldn't result in a document that
explains that we've made a
>> > > decision about separating licenses for
text and code.  If I
>> > understand
>> > > correctly, Harald said there was
consensus that there needs to be
>> > > different licenses for text and code. 
(And I'm not disputing that
>> > > consensus...)  Explicitly reflecting that
decision in the document
>> > > would be useful as a trail of what the WG
has discussed and
>> decided.
>> > >
>> > > /Simon
>> > >
>> > > >
>> > > > Yours,
>> > > > Joel
>> > > >
>> > > > At 10:20 AM 12/5/2006, Simon
Josefsson wrote:
>> > > >>I'm changing the subject because
this is a separate issue.
>> > > >>
>> > > >>Harald Alvestrand <haraldalvestrand.no> writes:
>> > > >>
>> > > >> > Simon Josefsson wrote:
>> > > >> >> Harald Alvestrand
<haraldalvestrand.no> writes:
>> > > >> >>
>> > > >> >>
>> > > >> >>> I believe that the
WG has declared consensus that it
>> > disagrees with
>> > > >> >>> you on the
code/text separation issue.
>> > > >> >>>
>> > > >> >>
>> > > >> >> If so, please have that
be reflected in Joel's draft, so it
>> is
>> > > >> >> recorded as the WG
consensus.  The code vs text
>> > separation is a
>> > > >> >> decision that has to be
made before the current
>> > discussions makes
>> > > >> >> sense.  Recording that
earlier decision, which this
>> discussion
>> > > assume,
>> > > >> >> seems to be the
appropriate way forward.
>> > > >> >>
>> > > >> > It is reflected in Joel's
draft.
>> > > >>
>> > > >>No, it does not appear to be
reflect explicitly.  I re-read
>> Joel's
>> > > >>draft now, and it implicitly
assumes that rights to code
>> > and text will
>> > > >>be handled differently from each
other.  You can see that in how
>> > > >>section 5 is divided into rights
granted for different purposes,
>> > > >>without discussion of how that
separation came to be.  There is
>> > > >>nothing explicit in there to
indicate that how the
>> > sub-sections of 5
>> > > >>are outlined is based on an
implicit assumption.
>> > > >>
>> > > >>I suggest adding a paragraph
before section 5.1, in the
>> > introduction
>> > > >>text in section 5:
>> > > >>
>> > > >>   The structure below assumes
that there can be
>> > different licenses,
>> > > >>   and different outgoing rights,
for different parts of
>> > a particular
>> > > >>   document.  For example, the
rights to code portions of
>> > a document
>> > > >>   may be different from the
rights to text portions of a
>> > document.  To
>> > > >>   permit different licenses for
different parts of a
>> > document was an
>> > > >>   intentional decision, and it
allows more flexibility
>> > when deciding
>> > > >>   the license for any specific
parts.
>> > > >>
>> > > >>With text like that, or actually,
any text whatsoever
>> > that explicitly
>> > > >>mention the problem, I would
regard the issue closed.  I
>> > still believe
>> > > >>it will be an unfortunate
decision that we'll have to
>> > revise in a few
>> > > >>years, though, but I understand
that unless someone gives
>> > me support
>> > > >>on this, the above appear to be
the current consensus.
>> > > >>
>> > > >>Thanks,
>> > > >>Simon
>> >
>> >
>> >
_______________________________________________
>> > Ipr-wg mailing list
>> > Ipr-wgietf.org
>> > https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>> >

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

...
> However, I believe it doesn't make sense to decrease
the quality of a
> specification by removing code that is only available
under, say, the
> GPL.  That works against the goals of the IETF of
having
> specifications implemented widely and quickly.  Some
code is better
> than no code in a document.

The specific problem with GPL is that if GPLed code is
included
in a standard, any implementor who cannot accept the risk
of GPL contamination in his or her code is going to have a
heck
of a time understanding the standard without inadvertently
reading
the GPL code. It might be necessary to have a colleague
outside the
clean room blank out those sections of the RFC first. I
think
we should avoid that.

As already observed, it can be avoided by contributing the
code
to the IETF process directly instead of via a GPLed
document.
Nobody is forced to put their code under GPL before
contributing
it to the IETF.

    Brian

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Brian E Carpenter <brczurich.ibm.com> writes:

> ...
>> However, I believe it doesn't make sense to
decrease the quality of a
>> specification by removing code that is only
available under, say, the
>> GPL.  That works against the goals of the IETF of
having
>> specifications implemented widely and quickly. 
Some code is better
>> than no code in a document.
>
> The specific problem with GPL is that if GPLed code is
included
> in a standard, any implementor who cannot accept the
risk
> of GPL contamination in his or her code is going to
have a heck
> of a time understanding the standard without
inadvertently reading
> the GPL code.

If you are required to read code to understand a standard,
I'd say the
standard is already too inadequate for further
consideration, and
should never be published anyway.  I believe we should
assume that
standards continue to have high quality.

Further, it seems you are talking about a patent situation. 
There is
no problem in reading and running GPL'd code and trying it
out against
your proprietary or BSD licensed code.  It is only if you
distribute
the GPLed code in a product that the reciprocal terms of GPL
apply.

> It might be necessary to have a colleague outside the
clean room
> blank out those sections of the RFC first. I think we
should avoid
> that.

Sure, but that is not the case.  That's the situation with
patents,
but not with copyrights.

> As already observed, it can be avoided by contributing
the code
> to the IETF process directly instead of via a GPLed
document.
> Nobody is forced to put their code under GPL before
contributing
> it to the IETF.

Sure, and I absolutely agree.  What I'm talking about is
when that
situation did not happen and was not feasible.

/Simon

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

>> As already observed, it can be avoided by
contributing the code
>> to the IETF process directly instead of via a GPLed
document.
>> Nobody is forced to put their code under GPL before
contributing
>> it to the IETF.
>
> Sure, and I absolutely agree.  What I'm talking about
is when that
> situation did not happen and was not feasible.

What I'm referring to here may not be obvious to everyone,
so here is
a example from my own experience.

There is RFC 3548 on base64 encoding.  There were _many_
requests to
include sample code in the document, to make it easier to
verify
correctness of implementations, and to provide more details,
for those
who are interested.

I created a 'bis-document, now RFC 4648, and asked
contributors to
supply example code.  Few of the people who requested that
example
code was present sent me any code, which is to be expected. 
I can
only recall that people sent me pointers to existing code in
various
free software.

I looked at those implementations, and in the ~10
implementations that
I surveyed, I found one bug or another that made the code
violate the
specification.  Including such code would make the situation
worse.

Instead I created my own implementation based on parts from
the best
implementations that I could find.  I chose the GPL for the
license,
because nobody paid me to work on this, and I find the GPL
the most
appropriate for work that I do on my spare time.  That
choice allowed
me to base my work on other GPL'd code as well, which was
another
motivation for me to use the GPL.  That also enabled me to
get code
review and improvements from C89 and POSIX portability
experts around
the world, since the code was included in the
"gnulib" portability
library.

The draft contained the code, and it went through the IETF
process,
but there were some objections.  Still, it passed IETF last
calls and
IESG review unchanged.

The IAB rejected Ted's request to make a process-variation
to be able
to include the code, but it was denied.  I removed the code,
and the
document was published.

The net result?  The document didn't fulfil the primary
motivation for
developing the revised document, and was delayed
considerably.

People now have to chase a URL to my own home page and
download the
code instead, and the problems with that solution should be
familiar
to everyone.

I believe this is a good example of how the IETF rules here
worked
against the goal of making the Internet work better (i.e.,
RFC 3935).
People now have less easy access to an implementation of an
important
protocol, which is referenced by many other protocols, than
what they
would have if the code was included in RFC 4648.  The end
result is
disappointing to the number of people who requested sample
code.

/Simon

PS.  If someone wants to donate an implementation under a
BSD license
that follows RFC 4648, I'll happily include it in RFC
4648bis.  (Don't
forget to validate the implementation against the
specification first,
most widely used implementations are broken in one way or
another...)

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Simon,

Code contamination is a problem. If rewritten code
accidentally
contains a few lines the same as the original, lawyers can
get active. It has happened.

     Brian

Simon Josefsson wrote:
> Brian E Carpenter <brczurich.ibm.com> writes:
> 
> 
>>...
>>
>>>However, I believe it doesn't make sense to
decrease the quality of a
>>>specification by removing code that is only
available under, say, the
>>>GPL.  That works against the goals of the IETF
of having
>>>specifications implemented widely and quickly. 
Some code is better
>>>than no code in a document.
>>
>>The specific problem with GPL is that if GPLed code
is included
>>in a standard, any implementor who cannot accept the
risk
>>of GPL contamination in his or her code is going to
have a heck
>>of a time understanding the standard without
inadvertently reading
>>the GPL code.
> 
> 
> If you are required to read code to understand a
standard, I'd say the
> standard is already too inadequate for further
consideration, and
> should never be published anyway.  I believe we should
assume that
> standards continue to have high quality.
> 
> Further, it seems you are talking about a patent
situation.  There is
> no problem in reading and running GPL'd code and trying
it out against
> your proprietary or BSD licensed code.  It is only if
you distribute
> the GPLed code in a product that the reciprocal terms
of GPL apply.
> 
> 
>>It might be necessary to have a colleague outside
the clean room
>>blank out those sections of the RFC first. I think
we should avoid
>>that.
> 
> 
> Sure, but that is not the case.  That's the situation
with patents,
> but not with copyrights.
> 
> 
>>As already observed, it can be avoided by
contributing the code
>>to the IETF process directly instead of via a GPLed
document.
>>Nobody is forced to put their code under GPL before
contributing
>>it to the IETF.
> 
> 
> Sure, and I absolutely agree.  What I'm talking about
is when that
> situation did not happen and was not feasible.
> 
> /Simon
> 

_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

Simon,

You wrote:
> The point is, as far as I understand, that the IETF
rules should
> _permit_ authors to use code licensed under a
share-alike license as
> examples in documents.

Far more important is the goal that IETF specifications,
even the
"examples," can be implemented with equal rights
and conditions in both
proprietary and open source software and documentation. 

As you know, I'm a strong supporter of open source. But when
it comes to
*open standards*, I believe we have a broader responsibility
to be free for
all--without a share-alike license that disadvantages
proprietary software.

That is why, for a patent covenant, I support the Microsoft
Open
Specification Promise as the clearest expression yet of this
principle. IETF
should demand similar covenants today from other
patent-owning companies for
free implementation of patented technology in IETF industry
standards--in
both open source and proprietary software.

And that is also why, for a copyright grant, I recommend a
license such as
AFL 3.0, which grants a license to everyone (for both text
and code!)
conditioned only upon fair attribution and the retention of
defensive rights
in the event of patent or copyright litigation. 

Of course, when someone implements an IETF specification, he
or she can
*then* choose to distribute that implementation under a
share-alike license.
I'll cheer that decision! I may even recommend, as do Linux
standards
organizations and other open source projects, that the
GPL-licensed software
become a model implementation against which others are
judged.  But
that's very different from contaminating IETF specifications
with code or
text that some companies can't or won't be able to use.

/Larry Rosen


> -----Original Message-----
> From: Simon Josefsson [mailto:simonjosefsson.org]
> Sent: Wednesday, December 06, 2006 11:45 PM
> To: lrosenrosenlaw.com
> Cc: ipr-wgietf.org
> Subject: Re: Suggested text for text vs code
> 
> "Lawrence Rosen" <lrosenrosenlaw.com> writes:
> 
> >> This sounds similar to the reasoning I have
for opposing
> >> author-specific, and especially viral,
licensing in IETF documents.
> >
> > I don't know what you mean by
"author-specific" licensing.
> >
> > So-called "viral" licenses (I prefer the
term "reciprocal" as being less
> > associated with disease states), even though they
are wonderful for
> > encouraging free software and discouraging free
riders, are also
> > incompatible with open standards. That is because
open standards must be
> > available for implementation in proprietary
software also.
> >
> > If someone here is proposing allowing reciprocal
licenses for either
> IETF
> > contributions or IETF out-licensing, I vote -1 on
that too.
> 
> The point is, as far as I understand, that the IETF
rules should
> _permit_ authors to use code licensed under a
share-alike license as
> examples in documents.
> 
> Of course, having code available under a more liberal
license,
> e.g. the BSD license, is preferable.  Several code
examples in RFCs
> use similar licenses, and I expect that to be the norm.
> 
> However, I believe it doesn't make sense to decrease
the quality of a
> specification by removing code that is only available
under, say, the
> GPL.  That works against the goals of the IETF of
having
> specifications implemented widely and quickly.  Some
code is better
> than no code in a document.
> 
> Code in older RFCs, licensed under a license that
nobody can use
> legally, is still helpful when developing a new
implementation.  The
> license is unfortunate, and I don't believe we should
permit it in
> future RFCs, but not being able to use widely available
GPL'ed code as
> examples seems like a mistake to me.
> 
> I'll vote to permit reciprocal licenses, but will
suggest that when
> there is a choice, a BSD-licensed implementation should
be preferred.
> It is for the cases where there isn't a choice a GPL
implementation
> would be useful to be able to include.
> 
> /Simon
> 
> > /Larry
> >
> >
> >> -----Original Message-----
> >> From: David B Harrington
[mailto:dbharringtoncomcast.net]
> >> Sent: Wednesday, December 06, 2006 3:37 PM
> >> To: lrosenrosenlaw.com; ipr-wgietf.org
> >> Subject: RE: Suggested text for text vs code
> >>
> >> Hi Larry,
> >>
> >> This sounds similar to the reasoning I have
for opposing
> >> author-specific, and especially viral,
licensing in IETF documents.
> >>
> >> I don't want WGs and companies trying to
implement standards to be
> >> forced to waste time trying to divine which
piece of a document has a
> >> author-specific (possibly viral) license
associated with it, and I
> >> certainly do not want contribution of a code
snippet to allow the
> >> author of that snippet to impose viral
licensing for the whole IETF
> >> document.
> >>
> >> dbh
> >>
> >> > -----Original Message-----
> >> > From: Lawrence Rosen [mailto:lrosenrosenlaw.com]
> >> > Sent: Wednesday, December 06, 2006 4:33
PM
> >> > To: ipr-wgietf.org
> >> > Subject: RE: Suggested text for text vs
code
> >> >
> >> > > That wouldn't result in a document
that explains that we've made a
> >> > > decision about separating licenses
for text and code.  If I
> >> > understand
> >> > > correctly, Harald said there was
consensus that there needs to be
> >> > > different licenses for text and
code.  (And I'm not disputing that
> >> > > consensus...)  Explicitly reflecting
that decision in the document
> >> > > would be useful as a trail of what
the WG has discussed and
> >> decided.
> >> >
> >> > This confusion is why I keep insisting
people should license
> >> > "original works
> >> > of authorship" to IETF for open
standards rather than some
> >> > imprecise IETF
> >> > invention purporting to distinguish
between text and code.
> >> > (See [1] and
> >> > [2].)
> >> >
> >> > It is a waste of time to change code (for
whatever open source or
> >> > proprietary reason!) embodying an IETF
standard and then not
> >> > be able to
> >> > change the IETF-published text that
explains that code. Placing this
> >> > unnecessary burden on recipients of
IETF's open standards
> >> > documentation is a
> >> > penalty that serves no valid purpose yet
identified and
> >> > endorsed by this WG.
> >> >
> >> >
> >> > When any of us give our copyrighted (and
perhaps patented)
> >> > works to IETF in
> >> > collaboration with others for the
creation of industry standards, we
> >> > shouldn't want people sitting around in
working groups trying
> >> > to divine what
> >> > the difference is between code and text
in IETF draft
> >> > specifications, and
> >> > then waste more time documenting such
hair-splitting in the
> >> published
> >> > official IETF specifications themselves,
and even more time within
> >> the
> >> > companies that implement those
specifications trying to
> >> > decide what they can
> >> > use and what they can't.
> >> >
> >> > To the extent that this suggestion to
distinguish code from
> >> > text came up for
> >> > a vote before, but is still pending, I
vote -1.
> >> >
> >> > /Larry Rosen
> >> >
> >> > [1] 17 USC 102, first sentence, at
> >> > http://www.law.cornell.edu/uscode/html/uscode17/us
c_sec_17_000
> >> > 00102----000-.
> >> > html.
> >> >
> >> > [2] AFL 3.0, first sentence, at
www.rosenlaw.com/AFL3.0.htm.
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: Simon Josefsson
[mailto:simonjosefsson.org]
> >> > > Sent: Wednesday, December 06, 2006
8:53 AM
> >> > > To: Joel M. Halpern
> >> > > Cc: ipr-wgietf.org
> >> > > Subject: Re: Suggested text for text
vs code
> >> > >
> >> > > "Joel M. Halpern"
<joelstevecrocker.com> writes:
> >> > >
> >> > > > My understanding of my
instructions from San Diego was to
> >> > be explicit
> >> > > > in the section about code
rights that these were distinct
> >> > from text
> >> > > > rights.
> >> > >
> >> > > Good!  Then my suggested text to be
explicit about the separation
> >> of
> >> > > licenses code should be
non-controversial.
> >> > >
> >> > > > And that I was to document that
> >> > > > a) the code rights applied to
any sections of RFCs which
> >> > were of the
> >> > > > form X, Y, Z, W.  A specific
list of cases.
> >> > > > b) That the trust would define
a way of marking portions
> >> > of RFCs as
> >> > > > code so that if there were
other things that the WG
> >> > concluded needed
> >> > > > to be treated as code (such as
a RelaxNG schema if I don't
> >> include
> >> > > > that in the list above), the
the working group can
> >> > indicate that the
> >> > > > code rights apply to that
section as well.
> >> > > >
> >> > > > I much prefer being explicit in
the right place about
> >> > what the rights
> >> > > > apply to, rather than putting a
general description up at
> >> > the front.
> >> > >
> >> > > That wouldn't result in a document
that explains that we've made a
> >> > > decision about separating licenses
for text and code.  If I
> >> > understand
> >> > > correctly, Harald said there was
consensus that there needs to be
> >> > > different licenses for text and
code.  (And I'm not disputing that
> >> > > consensus...)  Explicitly reflecting
that decision in the document
> >> > > would be useful as a trail of what
the WG has discussed and
> >> decided.
> >> > >
> >> > > /Simon
> >> > >
> >> > > >
> >> > > > Yours,
> >> > > > Joel
> >> > > >
> >> > > > At 10:20 AM 12/5/2006, Simon
Josefsson wrote:
> >> > > >>I'm changing the subject
because this is a separate issue.
> >> > > >>
> >> > > >>Harald Alvestrand
<haraldalvestrand.no> writes:
> >> > > >>
> >> > > >> > Simon Josefsson wrote:
> >> > > >> >> Harald Alvestrand
<haraldalvestrand.no> writes:
> >> > > >> >>
> >> > > >> >>
> >> > > >> >>> I believe that
the WG has declared consensus that it
> >> > disagrees with
> >> > > >> >>> you on the
code/text separation issue.
> >> > > >> >>>
> >> > > >> >>
> >> > > >> >> If so, please have
that be reflected in Joel's draft, so it
> >> is
> >> > > >> >> recorded as the WG
consensus.  The code vs text
> >> > separation is a
> >> > > >> >> decision that has
to be made before the current
> >> > discussions makes
> >> > > >> >> sense.  Recording
that earlier decision, which this
> >> discussion
> >> > > assume,
> >> > > >> >> seems to be the
appropriate way forward.
> >> > > >> >>
> >> > > >> > It is reflected in
Joel's draft.
> >> > > >>
> >> > > >>No, it does not appear to be
reflect explicitly.  I re-read
> >> Joel's
> >> > > >>draft now, and it implicitly
assumes that rights to code
> >> > and text will
> >> > > >>be handled differently from
each other.  You can see that in how
> >> > > >>section 5 is divided into
rights granted for different purposes,
> >> > > >>without discussion of how
that separation came to be.  There is
> >> > > >>nothing explicit in there to
indicate that how the
> >> > sub-sections of 5
> >> > > >>are outlined is based on an
implicit assumption.
> >> > > >>
> >> > > >>I suggest adding a paragraph
before section 5.1, in the
> >> > introduction
> >> > > >>text in section 5:
> >> > > >>
> >> > > >>   The structure below
assumes that there can be
> >> > different licenses,
> >> > > >>   and different outgoing
rights, for different parts of
> >> > a particular
> >> > > >>   document.  For example,
the rights to code portions of
> >> > a document
> >> > > >>   may be different from the
rights to text portions of a
> >> > document.  To
> >> > > >>   permit different licenses
for different parts of a
> >> > document was an
> >> > > >>   intentional decision, and
it allows more flexibility
> >> > when deciding
> >> > > >>   the license for any
specific parts.
> >> > > >>
> >> > > >>With text like that, or
actually, any text whatsoever
> >> > that explicitly
> >> > > >>mention the problem, I would
regard the issue closed.  I
> >> > still believe
> >> > > >>it will be an unfortunate
decision that we'll have to
> >> > revise in a few
> >> > > >>years, though, but I
understand that unless someone gives
> >> > me support
> >> > > >>on this, the above appear to
be the current consensus.
> >> > > >>
> >> > > >>Thanks,
> >> > > >>Simon
> >> >
> >> >
> >> >
_______________________________________________
> >> > Ipr-wg mailing list
> >> > Ipr-wgietf.org
> >> > https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
> >> >


_______________________________________________
Ipr-wg mailing list
Ipr-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg