Ted Hardie wrote:
> I also don't think this is nearly as burdensome as you
do. Drafting
> a description of code that is valid for all IETF
documents may be a
> daunting task, but I think it will be pretty obvious to
most folks
> writing a document which bits could be passed to a
compiler or an
> interpreter and which could not. You can invent or
imagine corner
> cases, but I strongly suspect that it will be
straightforward in
> most cases we deal with.
And in which world is it useful or economically practical to
rewrite from
scratch the *text* that surrounds *code* whenever the *code*
is modified?
Why should the *text* and the *code* be treated differently
in IETF
documents? What economic or other interests does it serve to
distinguish the
two? What is the cost of including such mind-numbing
distinctions in our
already obscure standard-setting process?
> I think Simon's recent effort in
draft-josefsson-rfc3548bis-04.txt is
> instructive. It was not much work for him to identify
the bits
<snip>
> Getting that
> sorted out is a bigger burden than we need, and I'm
glad Simon has
> proposed a way forward from it.
I'm also grateful for Simon's efforts. I just think we
should take not only
steps forward but also occasionally steps back, in this case
back from the
abyss of silly distinctions between *text* and *code* in
published industry
standard specifications to which we all contribute.
/Larry
Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm
(www.rosenlaw.com)
Stanford University, Lecturer in Law
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and
Intellectual Property Law" (Prentice
Hall 2004)
> -----Original Message-----
> From: Ted Hardie [mailto:hardie qualcomm.com]
> Sent: Tuesday, June 06, 2006 10:42 AM
> To: lrosen rosenlaw.com; 'Harald Alvestrand'
> Cc: ipr-wg ietf.org
> Subject: RE: #1175 Code vs text - second attempt at
resolution
>
> At 8:42 AM -0700 6/6/06, Lawrence Rosen wrote:
> >What aspect of Qualcomm's copyrighted works do you
seek to
> >protect that could possibly justify burdening each
working group to
> separate
> >"text" from "code" in IETF
specifications?
>
> I have never spoken on this list for Qualcomm, and you
are outside
> the bounds of IETF culture to impute a corporate motive
to my
> contribution. I am not speaking for Qualcomm, the
IESG, the
> Episcopal Church or anyone else with whom I happen to
have
> an affiliation.
>
> I also don't think this is nearly as burdensome as you
do. Drafting
> a description of code that is valid for all IETF
documents may be a
> daunting task, but I think it will be pretty obvious to
most folks
> writing a document which bits could be passed to a
compiler or an
> interpreter and which could not. You can invent or
imagine corner
> cases, but I strongly suspect that it will be
straightforward in
> most cases we deal with.
>
> I think Simon's recent effort in
draft-josefsson-rfc3548bis-04.txt is
> instructive. It was not much work for him to identify
the bits
> for which he was author and could grant additional
rights (see
> his section 15); I think it took two rounds of email to
do it. Note that
> he didn't need to know what was code to do that; he
only needed
> to know which bits were not ISOC's.
>
> He also knew going in that section 11.1 and 11.2 were
code and, maybe
> more importantly, were code for which different copying
conditions should
> apply. Marking them as such with some token or
well-understood phrase
> would
> have not added much to the burden of publication. The
real hassle was that
> adding the notices related to his copying conditions
and the code's
> open source license requires IAB approval of a
variance to 3978. Getting
> that
> sorted out is a bigger burden than we need, and I'm
glad Simon has
> proposed a way forward from it.
>
> Ted Hardie
_______________________________________________
Ipr-wg mailing list
Ipr-wg ietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|