FW: FW: IETF copying conditions
Lawrence Rosen
I meant ie...@ietf.org below. Minor typo. Sorry. /Larry
From:
open-web...@googlegroups.com [mailto:open-web...@googlegroups.com] On Behalf Of Lawrence Rosen
Sent: Wednesday, September 17,
2008 2:44 PM
To:
open-web...@googlegroups.com
Subject: RE: FW: IETF copying
conditions
I'm moving this to ie...@ieft.org. There are important policy implications here that the entire community should understand before we let the IPR WG decide for us on a policy so opposite to open source and open standards!
I am also copying this separately to the Open Web Foundation (OWF) list, which I believe may have some interest in ensuring that it can copy and modify IETF specifications for its own standards any time it damn well pleases.
/Larry
> > At 11:18 AM -0700 9/17/08, Lawrence Rosen wrote:
> >> Suppose you were to specifically ask whether IETF wants to prevent
> other
> >> SDOs from re-publishing (modified) IETF text within their own specs? Do
> you
> >> expect that the community here really wants to limit the use of IETF
> specs
> >> in that way?
>
> Yes, undoubtedly that was the WG consensus. We don't want to see other
> SDOs
> publishing incompatible versions of our protocols, period. And this is
> not paranoia; it's evidence-based, although I don't want to point the
> finger
> at specific SDOs, since such matters are usually handled by courteous
> bilateral discussions. Using copyright protection is clearly a last
> resort.
>
> >> Why on earth would a volunteer, cooperative standards
> >> organization like IETF want to do that to other volunteer, cooperative
> SDOs?
>
> Becaus our primary mission is to make the Internet work better, which
> requires interoperable protocols, which precludes incompatible versions.
>
> Brian
*********************
Please note: There is an earlier set of emails on this thread in the archives of the IPR WG.
/Larry
*********************
> -----Original Message-----
> From: ipr-wg-...@ietf.org [mailto:ipr-wg-...@ietf.org] On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, September 17, 2008 2:15 PM
> To: ipr...@ietf.org
> Subject: Re: FW: IETF copying conditions
Dennis E. Hamilton
It strikes me that there is a concern for forkings of IETF specifications
that might be disguised as or confused for the IETF standard. I would think
that some sort of non-confusion condition would be a better solution.
I would expect that such a condition might be desirable for specifications
developed under OWF as well. Not to limit derivative works, but that
derivatives not appear to be the specification from which they are derived.
Is that the basic issue?
- Dennis
-----Original Message-----
From: Lawrence Rosen
http://groups.google.com/group/open-web-discuss/browse_thread/thread/4bc88c8
6306c47bc?hl=en
Sent: Wednesday, September 17, 2008 14:51
To: open-web...@googlegroups.com
Subject: FW: FW: IETF copying conditions
[ ... ]
[quoting Brian E Carpenter on the IETF IPR WG mailing list]
> Yes, undoubtedly that was the [IETF IPR WG] consensus. We don't want to
see other
> SDOs
> publishing incompatible versions of our protocols, period. And this is
> not paranoia; it's evidence-based, although I don't want to point the
> finger
> at specific SDOs, since such matters are usually handled by courteous
> bilateral discussions. Using copyright protection is clearly a last
> resort.
[ ... ]
Peter Saint-Andre
> Larry,
>
> It strikes me that there is a concern for forkings of IETF specifications
> that might be disguised as or confused for the IETF standard. I would think
> that some sort of non-confusion condition would be a better solution.
>
> I would expect that such a condition might be desirable for specifications
> developed under OWF as well. Not to limit derivative works, but that
> derivatives not appear to be the specification from which they are derived.
Right. We have a clause like that in the XSF IPR Policy:
"Unless separate permission is granted, modified works that are
redistributed shall not contain misleading information regarding the
authors, title, number, or publisher of the Specification, and shall not
claim endorsement of the modified works by the authors, any organization
or project to which the authors belong, or the XMPP Standards Foundation."
/psa
Lawrence Rosen
> It strikes me that there is a concern for forkings of IETF specifications
> that might be disguised as or confused for the IETF standard. I would
> think
> that some sort of non-confusion condition would be a better solution.
>
> I would expect that such a condition might be desirable for specifications
> developed under OWF as well. Not to limit derivative works, but that
> derivatives not appear to be the specification from which they are
> derived.
>
> Is that the basic issue?
Yes, that is the basic issue. But the solution created out of whole cloth by
the IETF IPR WG was to distinguish between "code" and "text" and to allow
only the former to be modified in derivative works. That means you can
modify the code but not its documentation. How silly can you get in order to
solve an entirely different problem? Using copyright licenses to prevent
forking is contrary to open source.
/Larry
> -----Original Message-----
> From: open-web...@googlegroups.com [mailto:open-web-
> dis...@googlegroups.com] On Behalf Of Dennis E. Hamilton
> Sent: Wednesday, September 17, 2008 3:31 PM
> To: open-web...@googlegroups.com
> Subject: RE: FW: IETF copying conditions
>
>
Brett McDowell
What about the patent side of OWF IPR? Will the non-asserts only be
binding to the official OWF versions of specs, or will they be crafted
to be binding on any implementation of necessary claims to mechanisms
captured in the OWF specs?
For example, if OWF publishes a version of OpenFoo and someone else
takes OpenFoo and changes a few things and publishes that as
OpenFooPrime... would the non-asserts on OpenFoo apply for
OpenFooPrime? Would folks implementing OpenFooPrime be protected from
patent infringement suites by OpenFoo contributors?
-- Brett
P.S.
Regardless of what the answer to my question is, would the adoption of
OpenFooPrime -- especially if that resulted in OpenFoo not being
adopted -- be an outcome that OWF members would be ok with? It seems
that such a scenario opens the door for whoever has enough marketing
muscle and pre-existing install base to just publish their own version
of OWF specs and undermine the interoperability of the OpenWeb... or
worse, co-opt it.
Stephan Wenger
Comments inline.
Stephan
On 9/18/08 2:58 PM, "ext Brett McDowell" <br...@projectliberty.org> wrote:
>
> Thank you for that clarification.
>
> What about the patent side of OWF IPR? Will the non-asserts only be
> binding to the official OWF versions of specs, or will they be crafted
> to be binding on any implementation of necessary claims to mechanisms
> captured in the OWF specs?
>
I don't think that Nokia could make a patent non-assert promise under these
conditions. How could we control that a community is not waddling into
patent-territory that we do not wish to license, where we have
royalty-bearing licenses already out, where we have sub-licensable licenses
out, etc. etc.? If something along these lines would be required, you would
loose a lot of talent developing the specs.
To be positive, I think that we would allow our people to work in
communities if the IPR policy they work under follows, for example, one of
the following two principles:
1. Charter based approach
A community agrees on a charter. Nokia personnel could work on projects
under that charter after an internal clearance is given. Our non-assert
commitments holds for any specification within the scope of that charter.
We would also need an "opt-out" mechanism that allows us to remove our
non-assert commitment for named patents at an appropriate point in time; we
can discuss what that appropriate point in time would be. Any re-chartering
requires a renewed non-assert commitment. And, of course, the non-assert
must be reciprocity-conditioned, so to preserve the defensive value of
patents.
In essence this is the W3C model, but requiring non-assert instead of
RF-licensing.
2. Document-based approach
A community agrees to work towards a document (or perhaps an updated version
of an existing document). The initial work towards that document would not
be protected by a non-assert. At some point in the lifecycle, an alpha
version of the document is agreed on by consensus. From that point on, all
contributors need to either (implicitly) agree to a patent non-assert
related to the alpha version and all following versions until final, or they
must leave at that point. It would be possible to add a clause in the
policy to the extend that those who leave should (but not must) provide the
reason why they opt out (so to make design-around approaches easier, and
also provide hooks for litigation if there is another Son of RAMBUS case).
Again, the non-assert must be reciprocity-conditioned.
> For example, if OWF publishes a version of OpenFoo and someone else
> takes OpenFoo and changes a few things and publishes that as
> OpenFooPrime... would the non-asserts on OpenFoo apply for
> OpenFooPrime? Would folks implementing OpenFooPrime be protected from
> patent infringement suites by OpenFoo contributors?
>
> -- Brett
>
> P.S.
> Regardless of what the answer to my question is, would the adoption of
> OpenFooPrime -- especially if that resulted in OpenFoo not being
> adopted -- be an outcome that OWF members would be ok with? It seems
> that such a scenario opens the door for whoever has enough marketing
> muscle and pre-existing install base to just publish their own version
> of OWF specs and undermine the interoperability of the OpenWeb... or
> worse, co-opt it.
Indeed, that risk exists. I see also a problem of document stability for
those of us mostly worried in devices that cannot easily be updated. For
us, it's much more useful to have a stable spec for a couple of years than
something a community tinkers around with forever... However, that's a
concern of today; it may be less a concern tomorrow.
David Orchard
Hi all,
Comments inline.
Stephan
I don't think that Nokia could make a patent non-assert promise under these
On 9/18/08 2:58 PM, "ext Brett McDowell" <br...@projectliberty.org> wrote:
>
> Thank you for that clarification.
>
> What about the patent side of OWF IPR? Will the non-asserts only be
> binding to the official OWF versions of specs, or will they be crafted
> to be binding on any implementation of necessary claims to mechanisms
> captured in the OWF specs?
>
conditions. How could we control that a community is not waddling into
patent-territory that we do not wish to license, where we have
royalty-bearing licenses already out, where we have sub-licensable licenses
out, etc. etc.? If something along these lines would be required, you would
loose a lot of talent developing the specs.
This has often been termed the "bulldoze the forest" problem because the community may end up bulldozing over all sorts of patents to get at the particularly necessary patent.
To be positive, I think that we would allow our people to work in
communities if the IPR policy they work under follows, for example, one of
the following two principles:
1. Charter based approach
A community agrees on a charter. Nokia personnel could work on projects
under that charter after an internal clearance is given. Our non-assert
commitments holds for any specification within the scope of that charter.
We would also need an "opt-out" mechanism that allows us to remove our
non-assert commitment for named patents at an appropriate point in time; we
can discuss what that appropriate point in time would be. Any re-chartering
requires a renewed non-assert commitment. And, of course, the non-assert
must be reciprocity-conditioned, so to preserve the defensive value of
patents.
In essence this is the W3C model, but requiring non-assert instead of
RF-licensing.
The downside of this approach is the same problems that W3C (and others like OASIS) have, where some charters are tightly scoped to a specific submitted specification to allegedly ensure that the right IP conditions are met, whereas the real reason is to ensure company x's spec is rubberstamped.
It's very difficult to find the right balance between knowing up front what IP needs to be granted vs overlying constraining the committee(s) works.
Cheers,
Dave
Lawrence Rosen
depending on how this OWF community evolves. Both provide generous ways for
open standards to be created.
Our policy can specify that copyright licenses for contributions and
specifications be open source for both code and text. That would do better
than the current proposed IETF IPR policy in that we could discourage, but
not forbid, forking of our documents.
At the same time, we can allow contributors to carve out their patent
licenses carefully, with appropriate contribution rules and opt-out
procedures, in such a way that we encourage effective specifications without
denuding companies' patent portfolios. I'm not sure whether the
charter-based or document-based approach works better for OWF. But both
result in clear licenses to patented technology for specific standards. The
Apache Software Foundation accepts patent licenses through its CLA in almost
that way, except the final opt-out date is the date the contributor makes
his contribution, and ASF defines "project" rather than "charter" or
"document".
/Larry
[LR:] <snip>