Subject: Re: I-D ACTION:draft-josefsson-ipr-rules-update-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Dec 2005 12:18:34 +0100

Simon Josefsson wrote:
> Brian E Carpenter <[email-masked]> writes:
> 
> 
>>Personal comments:
>>
>>I'm still of the opinion that Simon's proposal inadvertently
>>amounts to the IETF giving up change control of our own documents,
>>and that seems plain wrong to me.
>>
>>IMHO we've *got* to limit the field of use such that we get
>>to decide explicitly when it's OK for another body to
>>update one of our specifications. How to do that while
>>allowing the kind of uses we think are OK is really a
>>problem for a legal drafting expert, not for a bunch of
>>engineers. I suspect the license will end up being much
>>longer than what we have today, and will enumerate cases,
>>both those that are allowed and those not allowed, e.g.
>>
>>o License is granted to copy, use, extract, modify and distribute
>>  the material when included in software code, provided only that
>>  the material may not subsequently be extracted from the software
>>  code for use other than in software code
>>
>>o License is not granted to copy, use, extract, modify and distribute
>>  the material in any document which appears or purports to be an
>>  alternative version of a publicly available technical standard or
>>  technical specification of a same or similar name
>>
>>etc etc.
> 
> 
> That language seem incompatible with the GPL and the BSD license to
> me.

It wasn't intended as definitive text. We need to agree on the
effect we want, and then get the drafting done by legal experts.

...

> I believe compatibility with the BSD/GPL licenses is important for the
> IETF document license, because spreading RFC material into free
> software further the goals of the IETF.

That's one of multiple considerations. We have to satisfy a bunch
of simultaneous constraints, and that will lead to a rather complex
result.

...
> If you have objections to other aspects of my license, please explain
> exactly what you mean, and perhaps also how it could be fixed.  I
> don't understand what you mean by "giving up change control".  The
> IETF clearly has rights to change document, and it still control the
> authoritative version.

But we also want to stop rogue versions, created by individuals or
other SDOs, that make non-interoperable changes. And that constraint
will need to survive any use of the text under an open source license.
Some legal ingenuity will be needed to achieve that.

        Brian

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 Dec 2005 12:35:22 +0100

> of simultaneous constraints, and that will lead to a rather complex

We haven't documented the constraints yet, so concluding that the end
result will be complex seem premature.

An all-permissive license like what I have proposed seem to me to
solve all constraints that have presented so far.

This suggest that we should start working on a requirements document.
To get the widest possible input to that process, I again believe it
is important to update the WG charter.

> other SDOs, that make non-interoperable changes.

I believe my license achieve that goal.

> And that constraint will need to survive any use of the text under
> an open source license.  Some legal ingenuity will be needed to
> achieve that.

It may be needed, but there is plenty of history to lean on here.  The
free software community have dealt with "rogue" and incompatible
changes for many years.  Witness Emacs vs XEmacs, OpenBSD, FreeS/WAN
vs OpenS/WAN, etc.  No legal ingenuity has been required to solve
those issues.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Dec 2005 15:53:45 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Simon Josefsson wrote:
    >>> amounts to the IETF giving up change control of our own
    >>> documents, and that seems plain wrong to me.
    >>> 
    >>> IMHO we've *got* to limit the field of use such that we get to
    >>> decide explicitly when it's OK for another body to update one
    >>> of our specifications. How to do that while allowing the kind
    >>> of uses we think are OK is really a problem for a legal
    >>> drafting expert, not for a bunch of engineers. I suspect the
    >>> license will end up being much longer than what we have today,
    >>> and will enumerate cases, both those that are allowed and
    >>> those not allowed, e.g.
    >>> 
    >>> o License is granted to copy, use, extract, modify and
    >>> distribute the material when included in software code,
    >>> provided only that the material may not subsequently be
    >>> extracted from the software code for use other than in
    >>> software code
    >>> 
    >>> o License is not granted to copy, use, extract, modify and
    >>> distribute the material in any document which appears or
    >>> purports to be an alternative version of a publicly available
    >>> technical standard or technical specification of a same or
    >>> similar name
    >>> 
    >>> etc etc.
    >> That language seem incompatible with the GPL and the BSD
    >> license to me.

    Brian> It wasn't intended as definitive text. We need to agree on
    Brian> the effect we want, and then get the drafting done by legal
    Brian> experts.

That effect is also incompatible with the GPL.  It's not about the
text; it is about basic properties of what you are proposing.

[I don't strictly know that you consider MIBs etc being useful to
Linux to be a requirement so the following may not directly apply to
you.]

I do second Simon's desire that this discussion would be more
effective if those making suggestions learned enough about the
landscape of licensing to understand the implications of their
suggestions.  I think there's enough of a challenging situation here
even once we remove all the self-inconsistent proposals.  I think it
would be a lot easier if we didn't have to revisit the same
self-inconsistent proposals again and again.

Are there steps we could take to make it easier for people to become
educated?  If someone worked up a FAQ about licensing explaining
constrainnts for open source and proprietary use, would people read
it?
Alternatively is it worth presentation time?
Is it worth having some nice long conference calls or something like that?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Dec 2005 15:39:14 +0100

Sam,

Sam Hartman wrote:
...
> text; it is about basic properties of what you are proposing.

I want to make a positioning statement in response to that. It's
a personal position, not an AD position.

If we do a first class job on the IETF license, there is every reason
it could become a very powerful force, just like the GPL.

Therefore, I believe we should concentrate first on what we want,
not on what the GPL attempts to impose.

If we later find our needs and the GPL to be incompatible, then we
can decide what to do about it.
...
> constrainnts for open source and proprietary use, would people read

I think that would be valuable.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Dec 2005 16:45:35 +0100

> not on what the GPL attempts to impose.

I believe we want RFCs to be as widely implemented as possible, and
BSD/GPL is used for many implementations of IETF protocols,
consequently compatibility with free licenses follow quickly.

I would welcome a document that collect all the requirements.

Regards,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Dec 2005 17:39:49 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> Sam,
    Brian> Sam Hartman wrote:
    Brian> ...
    >> That effect is also incompatible with the GPL.  It's not about
    >> the text; it is about basic properties of what you are
    >> proposing.

    Brian> I want to make a positioning statement in response to
    Brian> that. It's a personal position, not an AD position.

    Brian> If we do a first class job on the IETF license, there is
    Brian> every reason it could become a very powerful force, just
    Brian> like the GPL.

I don't think that's our job.  Our job is to make a better Internet
and to produce useful standards not to become a very powerful force in
licensing.  The FSF has spent over a decade with significant resources
dealing with licensing politics; in many ways that has been their
primary contribution to the world.  I'd consider it very alarming if
we felt the need to make that sort of politics one of our focuses.
That's especially true because I don't think we can get consensus on
the politics necessary to take that approach.  Instead I suggest that
we view licensing as a tool to allow us to build a better Internet; we
should make decisions about licensing based on whether those decisions
allow us to build a better net.  Whenever someone proposes a change to
our licensing practices we should ask them to explain how that change
fits within the mission of the IETF and we should evaluate that change
based on whether it improves or harms our ability to build a better
Internet.  I do not see how becoming a very powerful force in
licensing fits within the IETF mission so I oppose that as a goal for
this working group.

    Brian> Therefore, I believe we should concentrate first on what we
    Brian> want, not on what the GPL attempts to impose.

See, I believe one of the things we want is for source-code like items
extracted from our RFCs to be useful to software vendors including
both the proprietary and open-source community.  I'd actually like to
see whether that's something the WG has consensus on; I suspect it is.

I believe that it is a fact that in order for these extracts to be
useful to the open-source community they must be GPL compatible.  I
believe that it is a fact that in order for these extracts to be
useful for the open-source community they need to be 2-clause BSD
compatible.  If you doubt that these are facts, I can explain in more
depth why I think that I'm making factual statements and attempt to
show that the statements are true.  I believe that there are similar
factual statements for the proprietary side of the house including for
example that these extracts cannot simply be distributed under the
terms of the GPL because many proprietary software packages would not
want to use the GPL.

So, I believe that we do need to consider what constraints
distributing under the BSD and GPL licenses create.  It will make our
job easier because it will better constrain a solution space.  I also
think it follows reasonably directly from something I consider a
requirement.

Note that debating whether our software extracts needs to be useful to
open-source is something we can do.  Similarly debating whether
non-software extracts need to be available under the same license is a
valuable thing is something reasonable.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Dec 2005 18:12:35 -0500

This is, roughly, what John proposed.
Simon's response was that this was unacceptable.

If this model, of making the code-like portions explicitly identifiable and 
usable (including allowing modifications to that code) without making the 
RFC text fully useable / modifiable, is an acceptable path, then we can 
work out how to get there for the future.  (And then try to figure out what 
if anything can be done for the past.)

Yours,
Joel