Goals of the Open Web Foundation (strawman)

[DeWitt Clinton]

Hi all,

Now that the mailing list has grown to several hundred members, many of whom have already actively participated in helping turn this idea into a reality, I thought it might be wise to seek a public re-articulation of why so many of us came together to do this work in the first place.  With that in mind, here's another statement of the goals of the OWF for people to comment on.   Please feel free to disagree with me as vehemently as you'd like to now, as I'd like the the end result of this to be something we can refer back to as a way of keeping future discussions focused and on topic.

Goals:

• To create a permissive intellectual property policy that closely mirrors the Apache License in intent and language, modified for use with specifications instead of source code.

• To create an incubation process, similar to the Apache Incubator, that helps individuals and corporations collaborate on open technologies, such that the result is intellectual property that can form the fabric of the open web.

• To create an organization, similar to the Apache Foundation, that can sustain and support the other two goals, for the benefit of the web as a whole, above the undue influence or control of any one party or interest.

Non-goals:

• Everything else.

Wordsmithing aside, that pretty much sums up why I'm interested in and involved in the OWF.   We're here to meet the need for a permissive and open intellectual property policy, and yes, we're explicitly modeled after the work that Apache has done before us.

Everything else is out of scope.  We're not going to develop half-open or semi-permissive IPR modes.  We're not going to dictate standards.  We're not going to make technical decisions or influence specifications or try to gain advantages for our respective employers.  We're not going to compete with the W3C or OASIS or the IETF or ISO.  We're not going to raise millions of dollars in funding or hire full-time staff.  There are many other organizations that already exist for those types of things, and our time would be better spent there than here if that's what we are interested in.

No, we're simply going to write a open specification license and we're going to help individuals and companies apply that license to intellectual property that they would like to contribute for the benefit of the open web.

If these goals have your support, then the community gathered here right now is, in my opinion, exactly the right group to make this a reality. 

If we are in agreement, then for everyone that may have goals that differ from those above -- and I know that there are plenty of other legitimate interests out there -- I politely request that you respect the goals of this effort and the time of the people contributing to it and help us stay focused and on topic.

Thoughts and comments?

-DeWitt


 

[Ben Laurie]

+1

>
> -DeWitt
>
>
>
>
> >
>

[Brady Brim-DeForest]

+1

[Chris Messina]

+1.

I might reverse the order of your strawman:

The OWF will do NOTHING except:

* Point 1

* Point 2

* Point 3

But yes, a very minor point.

It probably doesn't belong in the strawman, but I think a preference towards rough consensus, running code, and meritocratic-driven responsibility assignment should be part of the organizational fabric that helps keep the thing running -- ostensibly similar in nature to the Mozilla community (where, ideally if MoFo or MoCo failed, the community would still be able to carry the effort forward).

Chris

--
Chris Messina
Citizen-Participant &
 Open Source Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private

[David Recordon]

+1.

[Gabe Wachob]

+1, except that my *goals* do not include emulation of the Apache
Foundation. Emulation, as I see it now, is merely the best means to
achieve the sort of IPR safe zone (which includes an IPR policy and
minimal process), which I think is the real goal.

I'd be perfectly happy if we achieved my goal with some other model
than one based on ASF, but doing so seems unlikely (and undesirable)
right now.

-Gabe

On Thu, Sep 25, 2008 at 9:28 AM, DeWitt Clinton <dew...@google.com> wrote:

--
Gabe Wachob / gwa...@wachob.com \ http://blog.wachob.com

[Chris Messina]

I think my tendency is to invent as little as possible where other or
previous [historical] examples or models exist, and to only create
novel solutions when absolutely necessary, and in the smallest
incremental steps.

That Apache exists and has been rather successful at what it does
means that we can devote our energy to the hard, new tasks -- which
are primarily social and socializing our work and refining our purpose
and what we offer -- whereas developing or innovating in the
organizational structure might otherwise be a misapplication of our
collective (and very limited) energies.

Chris

--

[Jim Jagielski]

So let it be written...

So let it be done.

:)

On Thu, Sep 25, 2008 at 12:28 PM, DeWitt Clinton <dew...@google.com> wrote:

[Art Botterell]

Might it be worthwhile to memorialize the specific regards in which
this effort is intended to be different from the Apache model? For
the benefit of newcomers and also, as noted, for future reference?
I'm thinking it might not be obvious to everyone who reads this why
the OWF effort isn't duplicative. (And no, I'm not implying that it
is, I'm just offering a suggestion.)

- Art

[chris....@gmail.com]

The most fundamental difference is that we deal with specs and issues
around IPR/patents, whereas Apache deals with source code and
copyright (a reductionist view perhaps, but close enough).

From an organizational perspective, so far we're of the impression
that little else needs to differ from the Apache model to be
successful and to offer value.

Chris

[DeWitt Clinton]

2008/9/26 Art Botterell <a...@incident.com>

Might it be worthwhile to memorialize the specific regards in which
this effort is intended to be different from the Apache model?  For
the benefit of newcomers and also, as noted, for future reference?
I'm thinking it might not be obvious to everyone who reads this why
the OWF effort isn't duplicative.  (And no, I'm not implying that it
is, I'm just offering a suggestion.)

Fair question, and I appreciate the concrete suggestion.  The truth is that my preference has long been that the Apache Foundation itself would take up the challenge of licensing specifications in addition to source code, and that the OWF wouldn't be necessary.  The last thing that most of us wanted to do was create yet another foundation, except as a means of meeting the stated goals.

For better or for worse, and I honestly can't fault them for it, the consensus was that the Apache community decided to continue to focus exclusively on open source code, rather than expand their mission to take on the different range of social and legal challenges that developing specifications presents.  That there are so many Apache members also volunteering here to help create the OWF shows there is a mutual recognition of the need for this work, even if it is best done separately.

So this is very similar effort indeed, just tailored for type of intellectual property and communities involved in the creation of specifications, rather than source code.

Thanks for asking, Art!

-DeWitt

[David Rudin]

I’d agree with Gabe about not emulating Apache for an IPR policy.
Apache is fine for software, but specifications are different and need
a different legal approach. It’s not just that software is code and
specifications describe how the software is built, it’s that that the
main point behind getting together to agree upon a specification is to
ensure interoperability between different implementations. If you’re
not going to have interoperability, there simply isn’t a need for a
common technical specification.

Apache was designed for a very different purpose. You can fork the
code and turn a web server into an application server into whatever
you can imagine. That’s fine since there is no need for my forked
version to interoperate with your original version. For a patent
owner, one reason they are granting patent rights to the code is for
the benefit they get by being able to access, use, and modify the
code. Let a 1000 flowers bloom.

You can’t fork a standard the same way, though. If I decide I want to
change the fundamental operation of HTTP for my web server, I’ve just
broken interop with every application out there that is expecting to
receive data according to the HTTP specification. Patent owners are
giving rights to their patents in exchange interop (there is no code
here, just instructions on how to build it). That’s why IPR policies
for standards generally attach to a specific version of a
specification since patent owners are granting rights in exchange for
interop. Without a common, relatively stable specification to build
from, there is no interop.

If we’re talking about inventing as little as possible, we should be
looking at traditional standards bodies, not Apache. Traditional
standards bodies have been working on IT related standards for close
to half a century now and have helped form the backbone of the
computer industry. To ignore how these spec development organizations
have approached IPR policies and use Apache as a basis instead is a
bit like using a plumbing manual to try to fix an electrical problem.
There might be some commonalities, but it’s only going to get you so
far.

I also think it’s important that we avoid vague terms to set the
guidelines for what we’re trying to accomplish. I’m sure we can spend
months discussing what we mean by a permissive intellectual property
policy and not get very far. In the end, I believe OWF’s goal should
be to establish an IPR policy that helps ensure its specifications can
be implemented and used regardless of the software’s licensing
approach or implementer’s business model.

[DeWitt Clinton]

Thanks, David.  I'm glad you sent that note, as I think it highlights some of the lingering open questions about the role of the OWF within the standards ecosystem.

One way to frame a response is to reiterate that the OWF is not a standards organization itself at all.  While I agree that one purpose of a standards organization is to enforce mechanisms for interop, interop itself is not really a primary goal of the OWF.   Rather, the OWF is designed to create an IP policy that explicitly protects the right to fork and create derivative works of specifications -- even to the extent that those derivative works may deviate from interoperability.

Standardization is a separate and orthogonal step, and one best done in a standards organization.  That step well may enforce restrictions (preferably in the form of trademarks, not patent threats) in order to facilitate interop and discourage fragmentation.  But the underlying specifications themselves would still be made available under the original terms.

It was precisely the lack of reusable permissive IP terms that led to the creation of the OpenID Foundation, the OpenSocial Foundation, the Dojo Foundation, the Django Foundation, the XMPP Foundation, etc., etc.  The common thread among all of those efforts is the belief that the work that those communities engage in should be for the benefit of all, and that no one party should control a product that was created for the betterment of the web.  So perhaps I agree with you, David.  Maybe you can't fork a standard.  But you can make it easier for contributors to donate specifications and intellectual property for the common good.

Will these permissive terms around derivative works appeal to all communities?  Probably (well, certainly) not, and that's okay.  We're not here to meet the majority of needs, just a subset of technologies that contributors want to openly license.  There are plenty of other ways to retain control over intellectual property, and I suspect we'll all be involved with those for a long time to come.  This is different -- the appeal of the OWF is to solve a fundamentally distinct problem.  Our legal system makes it terribly difficult to give something away.  We're here to make it easier.

Last month I published a draft of a modified version of the Apache License for use with specifications.  While I am not a lawyer, and it obviously needs plenty of work, this draft still represents what I believe to be the open source spirit as applied to specifications, not source code.  At the very least, it is my personal stake in the ground, and I look forward to working with this community to see where we can take those principles.

Cheers,

-DeWitt

[Eran Hammer-Lahav]

> Rather, the OWF is designed to create an
> IP policy that explicitly protects the right to fork and create derivative
> works of specifications -- even to the extent that those derivative works
> may deviate from interoperability.

This is not something we actually have agreement on and has proved
itself to be the most contested item.

My motivation for this work hasn't been the lack of existing licenses.
There are plenty of licenses that with minor modifications would suit
my needs and will make me happy to create specifications. In the trade-
off between a wider participation to unlimited ability to create
derivative work, I vote for participation. My view is that if someone
wants to create derivative works that do not comply with the spec, it
is reasonable to ask past contributors to re-license their IP. If the
spec directly applies in part or whole, then it is covered anyway. The
technical aspects of forking or creating derivative work from source
code is completely different from specifications.

EHL

[Gabe Wachob]

On Fri, Sep 26, 2008 at 8:40 AM, David Rudin <davi...@microsoft.com> wrote:
>

> I'd agree with Gabe about not emulating Apache for an IPR policy.
> Apache is fine for software, but specifications are different and need
> a different legal approach.

I think you're mischaracterizing my statement a bit. What I tried to
say was that the reuse of the ASF framework is a means to an end for
me, not an end.

And for what its worth, I had the same initial feeling - "We can't
possibly use ASF - specs are so different from code".

But if you think about the IPR policy itself as a piece of code, then
actually the same community effort around such output is very similar
to what comes out of an open source software effort at ASF. Here at
OWF, we're just one level of meta away from code. To wit, we're
producing the code (the IPR policy, process) for systems (spec
contributors) to interoperate (e.g. not sue each other).

Its a bit of a stretch, but in this way, the cultural fit of the
ASF-style structure actually seems appropriate.

-Gabe

[DeWitt Clinton]

On Fri, Sep 26, 2008 at 11:23 AM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:

> Rather, the OWF is designed to create an
> IP policy that explicitly protects the right to fork and create derivative
> works of specifications -- even to the extent that those derivative works
> may deviate from interoperability.

This is not something we actually have agreement on and has proved
itself to be the most contested item.

Fair enough.  I should have prefaced each paragraph with a few more "in my opinion" disclaimers, but that was getting repetitive so I omitted them in favor of a "strawman" thread.  I stand corrected.

My motivation for this work hasn't been the lack of existing licenses.
There are plenty of licenses that with minor modifications would suit
my needs and will make me happy to create specifications. In the trade-
off between a wider participation to unlimited ability to create
derivative work, I vote for participation.

Isn't that just the IETF, then?  The IETF has one of the most open participation models you could ask for.

And -- in my opinion -- the IETF standards process makes for a fine incubator for projects once we have the open IPR policy down.  Even our own efforts here may prove redundant.

-DeWitt

[Dennis E. Hamilton]

I think there is some strange conceptual pitfall that has it be presumed
that one can expect non-copyright IP to travel with derivative works of
either code or specifications under any meaningful licensing regime.

I think the easiest way to express this (another generalization) is that
copyright is about the tangible expression and patents are about the
application -- a mixture of what an implementation does, how it does it, and
where (on what behalf) it does it.

Continuing this over-simplification, I suggest that is why patent claims
usually do not apply to specifications but their implementations and what is
done with those implementations. Notice that the existing non-assertion
statements and covenants that have been cited on this list are all worded in
terms of implementation of such-and-such specification.

- Dennis

PS: Important subtlety: It is of course, valuable to make sure that there is
no patent claim that can't be escaped in making any practical implementation
whatsoever, if one wants to ensure that royalty- and license-free
implementations are possible. Unfortunately, an IPR agreement by
participants/contributors to a specification id not by itself sufficient to
avoid that situation, if the necessary claim subsists in a patent held by a
non-participant.

PPS: I don't even play a lawyer on television, only in my head.

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability
mailto:Dennis....@acm.org | gsm:+1-206.779.9430
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org

-----Original Message-----
From: DeWitt Clinton
http://groups.google.com/group/open-web-discuss/msg/c680e358c4325b21?hl=en
Sent: Friday, September 26, 2008 10:55
To: open-web...@googlegroups.com
Subject: Re: Goals of the Open Web Foundation (strawman)

[ ... ]

Rather, the OWF is designed to create an IP policy that explicitly protects
the right to fork and create derivative works of specifications -- even to
the extent that those derivative works may deviate from interoperability.

[ ... ]

-----Another Message-----
From: Eric Hammer-Lahav
http://groups.google.com/group/open-web-discuss/msg/a80c0b46295ceb0b?hl=en

[ ... ]

The technical aspects of forking or creating derivative work from source
code is completely different from specifications.

[ ... ]

[Ben Laurie]

On Fri, Sep 26, 2008 at 11:30 AM, DeWitt Clinton <dew...@google.com> wrote:
> On Fri, Sep 26, 2008 at 11:23 AM, Eran Hammer-Lahav <er...@hueniverse.com>
> wrote:
>>
>> > Rather, the OWF is designed to create an
>> > IP policy that explicitly protects the right to fork and create
>> > derivative
>> > works of specifications -- even to the extent that those derivative
>> > works
>> > may deviate from interoperability.
>>
>> This is not something we actually have agreement on and has proved
>> itself to be the most contested item.
>
> Fair enough. I should have prefaced each paragraph with a few more "in my
> opinion" disclaimers, but that was getting repetitive so I omitted them in
> favor of a "strawman" thread. I stand corrected.

So, I guess it depends what you mean by a "right to fork". Setting
ourselves up so that you can't reuse language from a spec would be
bad. But I agree with Eran that you can't expect IPR holders to grant
a licence to implementations of a spec and all possible derivatives,
since that would include all possible specs. It seems to me quite
reasonable that if you want to get IPR assigned to your new spec, then
you have to ask (or be prepared to show you were already covered
somehow).

[Dennis E. Hamilton]

+1 (or perhaps more to the point, "Amen.")

-----Original Message-----
From: Ben Laurie
http://groups.google.com/group/open-web-discuss/msg/dc79304bb89101d2?hl=en
Sent: Friday, September 26, 2008 12:05
To: open-web...@googlegroups.com
Subject: Re: Goals of the Open Web Foundation (strawman)

[ ... ]

So, I guess it depends what you mean by a "right to fork". Setting

[DeWitt Clinton]

I've always had this crazy idea that we could create a license that grants a) the right to create an implementation of a specification, b) the right to create derivative works of that specification, and c) the right to create an implementation of portions of the specification that appear in derivative works.

So say a specification α contains concepts A, B, and C.  The license grants the right to produce an implementation α', which consists of parts A', B', and C', each corresponding to their respective concepts as defined in the original specification α.  The description of those concepts (i.e., A, B, and C) is covered under the copyright license.  The implementation of those concepts (i.e, A', B', and C') is covered under the patent license.

The license also allows for the creation of a new derivative specification β, which for example, contains concepts A and B, and the new concept D.  The original license continues to grant the right to create implementations A' and B', but says nothing about any implementation D'.  Thus a new license would need to be applied for the purposes of covering D and D', and thereby covering all of β.  But this would not require the relicensing of the already covered concepts A and B, as those rights would still be granted by the original license.

But I'm an engineer, not a lawyer, so we'll leave it at that.

-DeWitt

[Ben Laurie]

2008/9/26 DeWitt Clinton <dew...@google.com>:

> I've always had this crazy idea that we could create a license that grants
> a) the right to create an implementation of a specification, b) the right to
> create derivative works of that specification, and c) the right to create an
> implementation of portions of the specification that appear in derivative
> works.
>
> So say a specification α contains concepts A, B, and C. The license grants
> the right to produce an implementation α', which consists of parts A', B',
> and C', each corresponding to their respective concepts as defined in the
> original specification α. The description of those concepts (i.e., A, B,
> and C) is covered under the copyright license. The implementation of those
> concepts (i.e, A', B', and C') is covered under the patent license.
>
> The license also allows for the creation of a new derivative specification
> β, which for example, contains concepts A and B, and the new concept D. The
> original license continues to grant the right to create implementations A'
> and B', but says nothing about any implementation D'. Thus a new license
> would need to be applied for the purposes of covering D and D', and thereby
> covering all of β. But this would not require the relicensing of the
> already covered concepts A and B, as those rights would still be granted by
> the original license.
>
> But I'm an engineer, not a lawyer, so we'll leave it at that.

I have no idea if this can be achieved in legalese, but I think this
sounds like a perfectly reasonable aspiration. Probably you would have
to call out what A, B and C were (i.e. define their boundaries) in the
original spec, or, as I suggested earlier, argue after the fact that A
and B are clearly covered by the original licence.

Simply assuming that because A is used in the original spec, A can
therefore be used in _any_ spec gets you back to the original problem:
if you require a blanket licence, you're going to hurt participation.

[Eran Hammer-Lahav]

To the point A’, B’, and C’ are sufficiently self standing, we have the same goal. As a spec editor, it is critical that new specs, derivative or not, are able to freely reference other specs, especially ones created under the OWF license. For example, OAuth uses small parts of 11 other specifications, and those parts are used exactly as defined, but only the applicable portions. I would apply this test to any license we create. But if you wanted to create a new spec called XAuth which is just like OAuth but with different parameter names and some changes to the signature workflow, I would argue that protecting that use case isn’t worth significantly reducing participation. If it is a needed evolution of the spec, I expect the previous contributors to be part of it and license it again.

EHL

--‾--‾---------‾--‾----‾------------‾-------‾--‾----‾
You received this message because you are subscribed to the Google Groups "Open Web Foundation Discussion" group.
 To post to this group, send email to open-web...@googlegroups.com
 To unsubscribe from this group, send email to open-web-discu...@googlegroups.com
 For more options, visit this group at http://groups.google.com/group/open-web-discuss?hl=en
 -‾----------‾----‾----‾----‾------‾----‾------‾--‾---

[Eran Hammer-Lahav]

More than anything else, I think clarity on behalf of the contributors and users of the spec is critical. I would be open to a compromise in which we define an atomic unit of a spec, and when that whole unit is used as is, the license covers it no matter in what application that unit is implemented. This can be a section, part, etc. and we will need to have a very tight definition. This will mean companies will be able to view the spec and raise issues with some IP being too isolated in the spec for them to be able to sign. This is a half baked idea but maybe one of the lawyers here can help.

EHL

[Eran Hammer-Lahav]

It is important that we separate the license from the process. There are many good things about the IETF process. The problem is their lack of real license. The only requirement is disclosure, and even that is not worth much. I can be making contribution to a spec for which my employer has patents on (and is actively asserting them) but as long as I don’t know about them, I can make any contribution. Then my employer can sue anyone implementing the spec, even if my name and my employer is listed on the front page. Also, the IETF simply requires stating the licensing terms, and allows RAND and other such licenses as long as they are clearly stated. I think the IETF can be a great arena for OWF-licensed specs...

EHL

[Joe Andrieu]

I think this is a good simplification. However, it misses the derivative situation I think David was touching on (and which I am most concerned about).

 

What happens when derivative specification β breaks functionality of specification α? That is, you have forked to an incompatible specification?

 

As long as β's use of α is entirely compliant, then β can be defined as α + ε, and the re-used parts of α are covered under the IPR regime of α and the ε components need new IPR. But if β breaks α, it can no longer be expressed in terms of α + ε, and therefore breaks the interoperability of α in a way that should, IMO, require re-licensing from any IP holders who agreed to the IPR for α.

 

The quid-pro-quo for permissive licensing of IP is that the open specification enables interoperability. If IP holders simply wanted the pure benefits of open source licensing (of which there are many), they could have already adopted any one of many open source licensing terms. If OWF actually wants to bring commercial vendors in who have significant IP, it seems to me we should encourage fair value (interoperability) in exchange for IP.

 

I get the benefits of N.E.A.-style open systems, but I worry that the commitment to permissiveness by some of the folks here comes at the expense of interoperability between implementations. As one who sees dataportability and service portability as the critical next step in the open web, I argue that this exuberance for permissive, incompatible derivatives is misplaced.

 

There's a challenging dance between open innovation and interoperability. If OWF ends up adopting the extremes of either, I think we will have failed.  However, if we can find an effective way to enable NEA systems that ensure both interoperability and a forward path for innovation... that would be work well worth all of our effort.

 

-j

 

--
Joe Andrieu
SwitchBook
http://www.switchbook.com
j...@switchbook.com
+1 (805) 705-8651

 

From: open-web...@googlegroups.com [mailto:open-web...@googlegroups.com] On Behalf Of DeWitt Clinton
Sent: Friday, September 26, 2008 12:27 PM
To: open-web...@googlegroups.com
Subject: Re: Goals of the Open Web Foundation (strawman)

 

I've always had this crazy idea that we could create a license that grants a) the right to create an implementation of a specification, b) the right to create derivative works of that specification, and c) the right to create an implementation of portions of the specification that appear in derivative works.

[Brett McDowell]

I'm not a lawyer either, but I've been in the middle of lawyers talking to lawyers about various IP policies (like the one from my organization) so based on that...

If I understood the main theme of the goal, I think the good news is that there is a way of doing this kind of license and it's been done before.  You can use legal language to enforce the idea that "hey, you already granted RF on your patents when we did the IPR review on this spec when it was version 1.0, so you can't withhold that RF grant now just because its in version 1.1, and A.B and X.Y.".  You bind the patent holder to the required component that must be implemented in order to have a compliant implementation at a point-in-time and then that's that.  With new derivatives and forking you get new IPR review "moment in time" but the only thing "at risk" of not being granted on the new material is new functionality.  The old stuff was granted once and for all, regardless of any new future contexts of those Necessary Claims.  BTW, this usually only flies if the grants are contingent on reciprocal licensing from the implementer, but that's just a good idea anyway for lots of reasons.

That's how a lot of SDO licenses work today.  So I don't think your goal is actually to create a new legal paradigm but it's more akin to what I heard Eran refer to... inclusive participation.  It sounds like you are working on the creation of an IETF with a different (but not necessary never-before-seen) license policy (IETF is not one of the SDO's who has the kind of license I'm referring to above, afaik).

BTW, if this was the primary goal, why didn't someone work with some IP lawyers to put together a strawman IP policy *before* investing all this energy in spinning up a new organization?

|| Brett McDowell | Calendar | Blog | Profile | +1.413.652.1248

[Gabe Wachob]

Brett-

   I think the OpenID and OAuth IPR policies are two examples that motivated many of the participants here... and probably will serve as strawmen.

   -Gabe

[Chris Messina]

Indeed, and we're coming up on needing IPR policies for projects like Portable Contacts and XRDS-Simple as well... I know Eran has been in the guts of this IPR stuff w/r/t the OAuth spec and that's where the lion's share of the thrust for the OWF came from. We couldn't simply dump OAuth into the OpenID Foundation; and rather than create the OAuth Foundation (ad infinitum), we opted for something that ideally can serve the current needs as well as many others into the near and not-too-near future.

Chris

[Brett McDowell]

Thanks Chris and Gabe.  Those two policies make sense as initial strawmen, but how does that map to DeWitt's actual initial strawman which was a derivative of the current ASF v2.0 CLA?

And, perhaps a more useful question would be, where is this strawman IPR discussion taking place... here or on the legal committee (which I withdrew my nomination from since all deliberations were intended to be open and trackable by non committee members).

|| Brett McDowell | Calendar | Blog | Profile | +1.413.652.1248

[DeWitt Clinton]

This is the list:

  http://groups.google.com/group/open-web-legal/about

Not any real activity there yet, so you haven't missed anything.  I'd just as soon keep the discussion on this list, as IPR is fun for everyone, but just in case it is best for people who are interested to sign up for both.

-DeWitt