Open Web Foundation characterization

[Gabe Wachob]

An early way I'm describing the Open Web Foundation is (as Scott says)
not a Standards Body, but a "IPR DMZ" - (an intellectual property
rights demilitarized zone).

Most folks who are hearing about this haven't directly participated in
a community standards effort, or a more formal standards body. They
think the W3C/IETF/OASIS "covers it".

But I think the sense of folks here is that there needs to be
something lighter weight that's only focused on the minimum needed for
a spec to become widely adoptable. For me, thats IPR hygiene -- almost
everything else can be done *easily* without an org (save, maybe the
organizational standup of a new org to hold/manage IPR). Having
slogged through this IPR policy stuff several times,I'm really happy
to see this effort to create a reusable framework for community
efforts. I only hope it remains lightweight and facilitates the widest
range of community efforts as possible.

-Gabe

[Chris Messina]

+1

Yes, we should be promoting the/an "open source model" for IP/IPR.

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

[Elias Bizannes]

I like the approach, but am wondering about where the line is? If it's
a specification, does that mean anyone that knocks on the door can be
supported? Will there be a difference between, say, a specification
for authentication as opposed to a CMS plugin?

+1 on lightweight. Sounds simple, but there is a lot of value in that
alone...but hard to achieve as well.

[Chris Messina]

We'll be looking at a lot of the Apache processes for incubation. Anyone of course can start an independent specification process; the ones that go through the OWF will probably need to meet some set of criteria, still TBD.

Chris 

[Gabe Wachob]

Chris-

Are these criteria for content, or merely for openness?

Is this group trying to be some sort of judge of technical merit, or
of market value?

-Gabe

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

This ideas in this email: [ ] I freely license [X] Ask first [ ] May
be subject to patents

[Chris Messina]

No, I don't think that's the intention -- we need to think/talk more
about what will encourage good practices/"good IPR hygiene" in
projects. I don't think it'd make sense to become kingmakers in any
sense, but, for example, if I'm going to start a new project to create
some kind of specification (like oEmbed) what do I need to do to align
myself with the OWF? Maybe it means no more than getting everyone on
the initiative to sign an OWF-provided CLA (contributor's license
agreement assigning copyright to the foundation) or maybe there's more
to it.

I'm not going to speak on behalf of the group of course at this point
but would be interested in your thoughts on this notion of "criteria".

Chris

Sent from an iPhone Classic.

[Eran Hammer-Lahav]

I am going to spend tomorrow writing down about a lot of the discussions and ideas that are driving this effort.

But for now, the simple answer is that we are going to come up with a system that will answer these questions without really dealing with them. For example, we can require a certain number of initial contributors to start a project, or a certain number of implementations, etc. The role of the foundation is to handle IPR in a community friendly way (which doesn't exist today), but also to assign experienced mentors to new projects. The incubation process is not about the foundation forming any technical or economical opinions.

I am a big believer in market forces and trust the open web community to know when it should offer competing solutions and when it should rally around an existing one. When bringing a project to the foundation for incubation, the foundation is going to dedicate some resources to help make the project more successful. Remember that you will be able to take the legal documents and use them outside the foundation if you so desire. But to get accepted you will need to answer some question such as what exists today and why it is not enough. But again, it will not be some foundation committee that should review your application, but the community at large.

For example, say I want to start a competing spec to OAuth. I can just write it using the IPR policy the foundation will publish or bring it for incubation. If I ask to incubate it, I am going to be asked to say:

1. Why isn't OAuth good enough?
2. Did I propose my idea to the OAuth community?
3. How is my solution better?
4. Who is going to use it?
5. Etc...

The idea is that at this point, to get into the foundation process, I will need to convince enough people that my answers justify another spec. If I can do that my project should be accepted. But I better come up with damn good answers to get such support from other people. Given that this entire process will be done in the open, it will be very hard to get away with bullshit ideas.

EHL

[Eran Hammer-Lahav]

Another way I've been talking about this, especially with lawyers (pretty much full time for the past 2 months), is what I call the 'OAuth test'. Basically, whenever someone suggests a process, legal or otherwise, I apply it to the 4 months specification writing period of OAuth and see what happens. Let me tell you - it usually blows into tiny pieces. It is the easiest way to show why we need the OWF. I want OAuth-like successes without the OAuth-like 7 months of post-IPR work. If we do that, we've accomplished everything we set to do.

[Elias Bizannes]

On Jul 25, 4:10 pm, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> I am going to spend tomorrow writing down about a lot of the discussions and ideas that are driving this effort.

Thanks Eran, I would appreciate seeing that.

[Gabe Wachob]

I'm looking forward to seeing your thoughts, Eran.

The more this group goes outside just providing the legal/IPR
framework, the more I get nervous.

What exactly is the purpose of being a gatekeeper w/r/t competing
specs? Why *not* let the market decide if two "competing" specs come
out of efforts under the OWF umbrella? This org's purpose is not to
promote a certain spec over another, except as to the "openness", right?

I'm just really worried that once you get into the "this spec is
blessed and this isn't", for any reasons other than IPR openness, you
instantly become un-lightweight, and the purpose gets muddled.
Furthermore, you likely end up turning away potential work that
*could* be useful and would leverage the IPR framework in OWF.

-Gabe

[Eran Hammer-Lahav]

I completely agree.

I think the key here is more about setting minimum requirements that are *not* about content, such as certain number of participants, the ability to find an experienced spec editor to sponsor/mentor the effort, getting some level of actual adoption before graduation. Basically - find ways to let the market guide us in an open way.

[Gabe Wachob]

This group has to be thin (just IPR, and minimum critical mass for new
work) and wide (anyone can participate, nobody blackballs or blesses
specs, etc).

Most stds bodies are tall and skinny..

-Gabe

[DeWitt Clinton]

Good thing we're not a standards body!

Many people here are already familiar with the Apache Incubator process, but for newcomers, here are some good links to read on one model that works very well, and can probably be adapted to specifications:

  http://incubator.apache.org/incubation/Incubation_Policy.html

And the proposal guidelines:

  http://incubator.apache.org/guides/proposal.html

Which all fits within the general Apache framework, which is described extremely well here:

  http://www.apache.org/foundation/how-it-works.html

Worth reading again as we get started.  I'd also love to hear from the Apache members on this list as to what works in practice, and what, if anything, they wish they could change about the Incubator.

Cheers,

-DeWitt

[Luca Mearelli]

2008/7/25 Eran Hammer-Lahav <er...@hueniverse.com>:

> The role of the foundation is to handle IPR in a community friendly way (which doesn't exist today), but also to assign experienced mentors to new projects.

IMHO even just defining clear and simple processes and documents
(IPR-related mainly) would be a huge contribution to the diffusion of
open standards.

It will be a great value to the big corporations as they'll know that
a spec has been developed using a commonly agreed (legal) framework,
BUT it will be of greater value to the small players and groups that
may be able to come up with interesting specs but may not (and usually
don't) have the experience and ability to go beyond the technical
spec.

In the end, with OWF, we may come out with something akin to an
IPR-commons (or Open-IPR, doing for specs IPR what CC did for the
licensing of creative work).

Also important is that these efforts are grounded on some real prior
work that has succeeded ans has been validated "by the market", as the
process and IPR work around OAuth.

Luca Mearelli

[Eran Hammer-Lahav]

A great quote from Stephen Walli at OSCON this week (which I hope I remember right):

 

 Standards are how companies declare war against the market leader.

 

(http://en.oreilly.com/oscon2008/public/schedule/detail/2313)

 

EHL

[James Tauber]

One example of a "specification-developing body" that adopts the
approach of allowing multiple competing specifications to be developed
within is OASIS (http://www.oasis-open.org/)

In fact, if you describe OWF as "Apache for specs", you could describe
OASIS as an "Apache for Enterprisey Specs" ;)

Whether OWF is OASIS-Lite or something else, there are probably a lot
of interesting things to borrow from at:

http://www.oasis-open.org/who/policies_procedures.php

James
--
James Tauber http://jtauber.com/
journeyman of some http://jtauber.com/blog/

[Dan Peterson]

I absolutely agree that OWF shouldn't be a gate keeper for "competing" specs. Two (or really "n"), in the same domain, should be able to co-exist peacefully.

As for going beyond legal/IPR, I feel like we -- collectively -- could come up with some "default" best practices around spec governance and related processes. While I'd recommend they not formally be "required," I'd imagine most sub-projects would then use them as a baseline when setting up their own processes. It'd avoid re-inventing the wheel, and lower the per-project learning curve on etiquette and culture.

-Dan

[Gabe Wachob]

James-
I have been an OASIS TC chair for almost 6 years. I totally agree
that hte model should be OASIS lite. In fact, I have been arguing to
those who would listen that OASIS should just drop its membership fees
for individuals... and then it would be pretty good (the process needs
a little fat-trimming in OASIS admittedly).

I'm worried about the whole filtering process inside ASF - totally
appropriate for that environment, but it feels like friction we don't
need for specs...

-Gabe

--

[David Recordon]

Great discussion so far and like Eran I intend to write up more of my thoughts around the incubation process.  Like DeWitt shared with Apache, I think that we should have a lightweight proposal process and then a clear set of requirements for "graduation".

In my head the proposal tries to tease out if they've thought about how what they want to do relates to other specifications, how they intend to develop a diverse community of contributors, some sort of argument around why the work is useful, and two or three mentors who are members of the OWF who are committed to help the community through the process.

Graduation then focuses on things like having a diverse community of contributors, at least 2 publically availiable on the internet interoperable implementations, good open source reference implementations in at least 2? different languages, a spec which is readable and well edited, a community which feels it is ready to be done, and non-assertion statements issued by all of the contributors.

--David

[Gabe Wachob]

DeWitt-
Well, if you say this is like the apache project - then this "org"
is producing something? Not standards? Specifications? So its a
specifications organization, not a standards body? Rhetorical
questions.

Point is, the more we excercise criteria like the following ones
[1] from ASF, the more it looks feels a standards body:

Alignment / Synergy
* Use of other ASF subprojects
* Develop synergistic relationship with other ASF subprojects

If it were up to me, any group that met a minimum bar could come
into the org and comply with the IPR rules (and maybe extra rules
about openness, including diversity of participation, transparency,
etc) and produce a spec. And the meaning of OWF's association would be
that the IPR hygiene is clean and the spec was made in a minimally
transparent way.

The Apache meritocracy is about producing good quality code, where
good is defined by "being done by people with good reputation". I just
get really nervous when a group, no matter how experienced and well
respected the leaders/comitters are, decides a spec gets a thumbs up
or thumbs down before a spec even gets to market. It dilutes the
purpose of this org, I believe. Call me a free marketer ;)

So I hear you about lightweight and focus on IPR, but I'm trying
to understand the purpose of the Apache process for promoting work
from "candidate" to podling to project and why that's needed here.
Maybe I'm just being too literal here - but why do we need anything
other than "in/out" (and maybe "dead to inactivity or failure to
comply with IPR and/or process")? Once you come and show that your
contributors are good to go with the OWF IPR rules (and that there's a
legitimate community effort -- but thats a low bar I think), what else
should you need?

-Gabe

[1] http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator

[Gabe Wachob]

What are we afraid of?

Too many specs?

Diluting the OWF brand?

The OWF not being "relevant enough"?

Can we do half as much and be twice as successful?

-Gabe

[David Recordon]

On Fri, Jul 25, 2008 at 12:36 AM, Gabe Wachob <gwa...@wachob.com> wrote:
> I'm worried about the whole filtering process inside ASF - totally
> appropriate for that environment, but it feels like friction we don't
> need for specs...

I actually believe that some level of filtering is needed.  Obviously lots of filtering and a complex process is not with our goals.  Making sure that a proposal supports the Open Web and has a chance of building a good community seem reasonable.  I really doubt that someone who takes the time to create a thought out proposal and recruit a few mentors would be turned down.  That said, OWF should not be a dumping ground for any specification.  As Chris Messina often talks about, we should also work to produce the IP docs in such a way that someone could apply them to work they're doing outside of OWF just as you can use the Apache license outside of the ASF.

--David

[David Recordon]

You're being a bit too literal, but we also haven't written out drafts of the incubation process so I don't blame you. :)

There are pieces of the ASF incubation process we should follow and others which we should learn from and decide that they're not applicable/right for this environment.

--David

[David Recordon]

My largest concern is time and resources of smart people.  The more that get involved then the more that we can do.  We shouldn't start with an open specification for a DSL modem authentication protocol as I doubt we have the domain expertise to do a good job.

--David

[James Tauber]

On Jul 25, 2008, at 3:47 AM, David Recordon wrote:

> My largest concern is time and resources of smart people. The more
> that get involved then the more that we can do. We shouldn't start
> with an open specification for a DSL modem authentication protocol
> as I doubt we have the domain expertise to do a good job.

But following on from the OASIS-Lite meme, would we want to allow a
group of DSL modem auth protocol experts to create a working group
under OWF to do this if they came to us?

[David Recordon]

I imagine we'd want to allow it.  Hard to predict every situation, I think we should focus on what we've seen as criteria for successful open specifications and their communities.  From there we'll see what sort of projects get proposed.

--David

[Eran Hammer-Lahav]

The key here is not the subject matter or technical qualities of the spec. It is about being worth the foundation’s resources – really people: experienced editors, contributors, etc. If not, as David and Chris said, feel free to use the process and self manage.

EHL

[Daniel Lewis]

Hi all,

I like the sound of an IPRDMZ (aka "Hyperdems"), and lightweight is
good.

What I was hoping from OWF was a kind of communications bridge between
the all of the standards bodies, and also a communications bridge
between all of things like DataPortability, GNU, Apache, Open Source
Initiative etc.

Oh, and by the way, over here in the UK this group shares its name
with another OWF..... the "Order of Women Freemasons" ( http://www.owf.org.uk/
), I've heard that they are a lovely group of ladies.

Many thanks,

Daniel

[Ben Laurie]

On Fri, Jul 25, 2008 at 4:08 AM, Gabe Wachob <gwa...@wachob.com> wrote:
>
> An early way I'm describing the Open Web Foundation is (as Scott says)
> not a Standards Body, but a "IPR DMZ" - (an intellectual property
> rights demilitarized zone).
>
> Most folks who are hearing about this haven't directly participated in
> a community standards effort, or a more formal standards body. They
> think the W3C/IETF/OASIS "covers it".
>
> But I think the sense of folks here is that there needs to be
> something lighter weight that's only focused on the minimum needed for
> a spec to become widely adoptable. For me, thats IPR hygiene -- almost
> everything else can be done *easily* without an org (save, maybe the
> organizational standup of a new org to hold/manage IPR). Having
> slogged through this IPR policy stuff several times,I'm really happy
> to see this effort to create a reusable framework for community
> efforts. I only hope it remains lightweight and facilitates the widest
> range of community efforts as possible.

If we are going to learn from other organisations, then a second thing
that is needed is process. One of the main reasons the ASF works, IMO,
is because of two pretty simple rules:

1. Meritocracy

2. Three +1s, anyone can veto but must justify.

The IETF lets anyone participate equally. This is broken because WGs
can be stalled by any idiot with time on his hands. The ASF allows
anyone to speak, but only votes from committers are counted.

The W3C lets you buy a voice - and won't give you one unless you pay.
I hope its obvious why this is broken.

The three +1s with veto allows progress to be made rapidly without
having to pause for formal votes on a regular basis. The justification
requirement seems to pretty effectively prevent hidden agendas and
frivolous vetos (no-one is going to say "I vetoed because my plan is
better than yours").

>
> -Gabe
>
> >
>

[Ben Laurie]

On Fri, Jul 25, 2008 at 8:33 AM, Dan Peterson <dpet...@google.com> wrote:
> I absolutely agree that OWF shouldn't be a gate keeper for "competing"
> specs. Two (or really "n"), in the same domain, should be able to co-exist
> peacefully.
>
> As for going beyond legal/IPR, I feel like we -- collectively -- could come
> up with some "default" best practices around spec governance and related
> processes. While I'd recommend they not formally be "required," I'd imagine
> most sub-projects would then use them as a baseline when setting up their
> own processes. It'd avoid re-inventing the wheel, and lower the per-project
> learning curve on etiquette and culture.

The lesson the ASF learned is that you actually do have to require
governance and process or you end up with some very dysfunctional
projects. This is largely why the incubator exists.

[Ben Laurie]

On Fri, Jul 25, 2008 at 8:36 AM, Gabe Wachob <gwa...@wachob.com> wrote:
>
> James-
> I have been an OASIS TC chair for almost 6 years. I totally agree
> that hte model should be OASIS lite. In fact, I have been arguing to
> those who would listen that OASIS should just drop its membership fees
> for individuals... and then it would be pretty good (the process needs
> a little fat-trimming in OASIS admittedly).
>
> I'm worried about the whole filtering process inside ASF - totally
> appropriate for that environment, but it feels like friction we don't
> need for specs...

Could you expand on what you mean by "the whole filtering process inside ASF"?

[Ben Laurie]

On Fri, Jul 25, 2008 at 8:40 AM, Gabe Wachob <gwa...@wachob.com> wrote:
>
> DeWitt-
> Well, if you say this is like the apache project - then this "org"
> is producing something? Not standards? Specifications? So its a
> specifications organization, not a standards body? Rhetorical
> questions.
>
> Point is, the more we excercise criteria like the following ones
> [1] from ASF, the more it looks feels a standards body:
>
> Alignment / Synergy
> * Use of other ASF subprojects
> * Develop synergistic relationship with other ASF subprojects

I would agree that these should be suggestions rather than requirements.

> If it were up to me, any group that met a minimum bar could come
> into the org and comply with the IPR rules (and maybe extra rules
> about openness, including diversity of participation, transparency,
> etc) and produce a spec. And the meaning of OWF's association would be
> that the IPR hygiene is clean and the spec was made in a minimally
> transparent way.

+1

> The Apache meritocracy is about producing good quality code, where
> good is defined by "being done by people with good reputation". I just
> get really nervous when a group, no matter how experienced and well
> respected the leaders/comitters are, decides a spec gets a thumbs up
> or thumbs down before a spec even gets to market. It dilutes the
> purpose of this org, I believe. Call me a free marketer ;)

The meritocracy decides who is trusted to screw up the code base, not
the popularity of the product.

> So I hear you about lightweight and focus on IPR, but I'm trying
> to understand the purpose of the Apache process for promoting work
> from "candidate" to podling to project and why that's needed here.
> Maybe I'm just being too literal here - but why do we need anything
> other than "in/out" (and maybe "dead to inactivity or failure to
> comply with IPR and/or process")? Once you come and show that your
> contributors are good to go with the OWF IPR rules (and that there's a
> legitimate community effort -- but thats a low bar I think), what else
> should you need?

Process that ensures that genuine participants are treated fairly.

[Danny Weitzner]

I agree that creating a zone of greater IPR certainty with lower
negotiation costs is a good goal.

On Jul 24, 11:08 pm, "Gabe Wachob" <gwac...@wachob.com> wrote:
> An early way I'm describing the Open Web Foundation is (as Scott says)
> not a Standards Body, but a "IPR DMZ" - (an intellectual property
> rights demilitarized zone).

Not to force the analogy, but I'd suggest that demilitarization is
hard to achieve in the patent licensing world simply because there
are too many insurgencies (trolls and even legitimate technology
developers) whose business model is to make money by sitting outside
community processes and pouncing when the opportunity arise. I'll
leave the insurgency/counter-insurgency discussion off here... :-)

I would suggest that goal might be IRP safe passage. A set of terms
that participants can agree to on a no-negotiation basis and then
attach to the work that they do. As others have said, this follows the
Creative Commons and open source model. There's no guarantee that the
license attached to a document is actually cleared, but at least
everyone is talking the same language.

>
> Most folks who are hearing about this haven't directly participated in
> a community standards effort, or a more formal standards body. They
> think the W3C/IETF/OASIS "covers it".
>
> But I think the sense of folks here is that there needs to be
> something lighter weight that's only focused on the minimum needed for
> a spec to become widely adoptable. For me, thats IPR hygiene -- almost
> everything else can be done *easily* without an org (save, maybe the
> organizational standup of a new org to hold/manage IPR). Having
> slogged through this IPR policy stuff several times,I'm really happy
> to see this effort to create a reusable framework for community

^^^^^^^^^^^^^^^^^^^

!!

> efforts. I only hope it remains lightweight and facilitates the widest
> range of community efforts as possible.
>

>      -Gabe

[Ben Laurie]

On Fri, Jul 25, 2008 at 12:02 PM, Danny Weitzner <djwei...@gmail.com> wrote:
>
> I agree that creating a zone of greater IPR certainty with lower
> negotiation costs is a good goal.
>
> On Jul 24, 11:08 pm, "Gabe Wachob" <gwac...@wachob.com> wrote:
>> An early way I'm describing the Open Web Foundation is (as Scott says)
>> not a Standards Body, but a "IPR DMZ" - (an intellectual property
>> rights demilitarized zone).
>
> Not to force the analogy, but I'd suggest that demilitarization is
> hard to achieve in the patent licensing world simply because there
> are too many insurgencies (trolls and even legitimate technology
> developers) whose business model is to make money by sitting outside
> community processes and pouncing when the opportunity arise. I'll
> leave the insurgency/counter-insurgency discussion off here... :-)
>
> I would suggest that goal might be IRP safe passage. A set of terms
> that participants can agree to on a no-negotiation basis and then
> attach to the work that they do. As others have said, this follows the
> Creative Commons and open source model. There's no guarantee that the
> license attached to a document is actually cleared, but at least
> everyone is talking the same language.

I think it is a given that we can only bind participants to IPR
agreements. Patent trolls are out of scope.

[DeWitt Clinton]

Jumping back in and popping back up the stack a bit:

The reason OWF is not a standards body is because we're explicitly saying that the OWF is not a standards body.  OASIS and IETF and W3C are standards bodies because their charters say to be standards bodies, and thus they are optimized to produce something called standards at the end.  One of the goals of standard bodies is to reduce competing or conflicting technologies; that is not one of our goals.  Also, standards bodies have accepted the challenge of convincing the world that their work is the canonical version of a given specification.  Again, that's not one of our goals.   (I'd also posit that one of the reasons it is difficult for a standards body to run a successful incubator in-house is because those goals, however good, are often at odds with getting immature technology off the ground.)

The end result of project that goes through the OWF incubation process is a working specification with clean IP that has demonstrated the ability to sustain a diversity of contributors.  Nothing more, nothing less.

That's not an easy thing to obtain, but it is easier to do that than build a actual standard.  The logical consequence is there will be specifications that make it through the OWF process that are non-standard.  And that's okay.

I do consider standardization a higher bar, and I hope many projects incubated with OWF go on to standardization at IETF, W3C, OASIS, or wherever.  But that is not our goal either.

Regarding IPR, yes, I think what we're trying to do is a) create some commonly agreed upon language around specification licensing, a. la. the CC license for copyright or the Apache license for source code, and b) ensure that all project contributors have agreed to those terms.  Challenges like dealing with non-contributors and/or trolls are out of scope (partly because I think those problems are intractable).

And popping way back up, I really hope we don't spend too much time creating committees.  The Apache governance model is pretty much the high end of what I personally have the stomach for.     The OWF governance model should be optimized for participation by busy engineers, not full-timers.

Cheers,

-DeWitt

[Steve Ivy]

DeWitt,

This is a great summation - thanks. While the OWF is not a standards
body, I expect that specs that come out of the OWF process with a
clean IPR bill of health will be easier to move through the standards
process, since the IPR issues will have already been dealt with.

--Steve

On Fri, Jul 25, 2008 at 7:59 AM, DeWitt Clinton <dew...@google.com> wrote:

> The end result of project that goes through the OWF incubation process is a
> working specification with clean IP that has demonstrated the ability to
> sustain a diversity of contributors. Nothing more, nothing less.

--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Paul Downey]

> The reason OWF is not a standards body is because we're explicitly
> saying that the OWF is not a standards body.

thanks Dewitt, that greatly reassures me.

> Regarding IPR, yes, I think what we're trying to do is a) create
> some commonly agreed upon language around specification licensing,
> a. la. the CC license for copyright or the Apache license for source
> code, and

I can see that working, with some legal resource, of course CC had
Larry Lessig to turn a sea of bespoke licenses into pressing a set of
simple radio buttons.

There are existing licenses to reuse, W3C document springs to mind,
but IANAL, and I for guess this to work, we're going to need one. Or a
bunch.

> b) ensure that all project contributors have agreed to those terms.

That's something every collaborative effort has to tackle at some
stage. Having a transparent, off the shelf process which scales
horizontally will help many and be invaluable. Is that the intent?

> The OWF governance model should be optimized for participation by
> busy engineers, not full-timers.

Bang on. Don't make me think!

Paul
--
http://blog.whatfettle.com

[Gabe Wachob]

Thanks Dewitt, this is great.

However, I think you are maybe mischaracterizing OASIS a bit and I'd
just like folks to keep OASIS in mind as a model in addition to ASF.

OASIS doesn't make any attempt to "de-dupe" specs. OASIS has a very
very lightweight process (scales down to a handful of individuals if
you want - except the final Oasis-wide vote which has a lot of warts).
OASIS, in fact, does no real filtering at all except minimum bars of
transparency and adherence to one of several IPR modes (only one of
which folks here would find acceptable for "open standards"). When I
was saying "filtering" before re: ASF, it was not a dig - but rather a
statement that anyone who wants to be an ASF project cannot just show
up and be a project - in fact, you have to convince disinterested
parties that you belong there. Probably the right answer for OWF is
somewhere in between.

I'm not suggesting we copy OASIS, any more than you guys are
suggesting we copy ASF. Lets just not throw the baby out with the
bathwater....

I think the first step for OWF is a statement of rather detailed goals
and principles because otherwise, this thread will go on forever ;)

-Gabe

On Fri, Jul 25, 2008 at 7:59 AM, DeWitt Clinton <dew...@google.com> wrote:

--

[Stephen Paul Weber]

> This is a great summation - thanks. While the OWF is not a standards
> body, I expect that specs that come out of the OWF process with a
> clean IPR bill of health will be easier to move through the standards
> process, since the IPR issues will have already been dealt with.

I think that realistically the way things are today the traditional
standards bodies have stopped adding anything meaningful. Something
light and open like has been described here for OWF is really all that
should every be necessary - even in the long run.

Really excited to see what comes of this!

--
- Stephen Paul Weber (Singpolyma)

Web: http://singpolyma.net/
Twitter: http://twitter.com/singpolyma
IM: singp...@gmail.com

[Kevin Marks]

Actually, that's an idiotic quote that represents a massive
misunderstanding, and it should not stand.
Standards are positive sum, war is negative sum.

[Chris Messina]

On Fri, Jul 25, 2008 at 9:12 AM, Gabe Wachob <gwa...@wachob.com> wrote:

Thanks Dewitt, this is great.

+1. This is very clear, and speaks to the many conversations that were had mulling over our intentions, goals and (minor) ambitions in getting this off the ground.

We're not solving world hunger (as someone said yesterday), we're trying to ease the pain that we're feeling today, and have been feeling for the past two years with OpenID and then OAuth. And then generalize what we've produced and learned so that others don't have to repeat the same pains when they engage in something that, as Kevin pointed out, is positive sum.

I'm not suggesting we copy OASIS, any more than you guys are
suggesting we copy ASF. Lets just not throw the baby out with the
bathwater....

I'd be really eager to keep things concrete and hear from personal testimony about specific cases where OASIS, ASF and other processes have worked well -- and where they've failed. We will only be able to learn and improve upon what's come before us if we are able to extract the practices that *actually* lead to success, rather than saying "we should just do what X did and not what Y did". 

I think for some of us who are newer to the standards process, we have some ideas about what's worked for us, but don't have the breadth or depth of knowledge for specific historical examples of what's worked and hasn't, down to a specific, practical level. Gabe, I'd love to hear specific examples that we could trace back at OASIS that support what you're saying so I understand more clearly.

 

I think the first step for OWF is a statement of rather detailed goals
and principles because otherwise, this thread will go on forever ;)

I think this conversation has been elucidating -- so clearly that kind of document should be forthcoming! ;)

Chris

[Webmink]

On Jul 25, 9:36 am, "Gabe Wachob" <gwac...@wachob.com> wrote:
> James-
>    I have been an OASIS TC chair for almost 6 years. I totally agree
> that hte model should be OASIS lite. In fact, I have been arguing to
> those who would listen that OASIS should just drop its membership fees
> for individuals... and then it would be pretty good (the process needs
> a little fat-trimming in OASIS admittedly).

I'd agree with this - I think OWF would do well to open a dialogue
with OASIS. And I'd definitely agree with adding a no-charge
membership category over there.

I do think they need to go further with their liberalisation of IPR
terms though. Adding the RF template (and making it the implied
default for new work) was an excellent move, but RF isn't enough for
open source. Open source needs the be sure that any declared patents
will be available without restrictions of any kind, financial or
otherwise.

S.

[Webmink]

On Jul 25, 1:48 pm, "Ben Laurie" <b...@google.com> wrote:
> I think it is a given that we can only bind participants to IPR
> agreements. Patent trolls are out of scope.

Totally agree. However, binding participants is probably enough since
almost all patents in a given area will arise from the work of
participants; trolls don't file patents. We need to make sure that any
non-assert is binding on participants /and their heirs and assigns/ so
that trolls are unable to attack in the future.

S.

[Joe Andrieu]

Webmink wrote:
> I do think they need to go further with their liberalisation of IPR
> terms though. Adding the RF template (and making it the implied
> default for new work) was an excellent move, but RF isn't enough for
> open source. Open source needs the be sure that any declared patents
> will be available without restrictions of any kind, financial or
> otherwise.

What about compliance to the standard?

Arguably the most important reason for a standard is to assure
interoperability among different implementations. Contributing one's IP
(whether licensed or through non-assertion) to a standard with minimal
restrictions is fine, but shouldn't that extend only to those compliant with
the standard? I don't mind giving IP to help create a standard, even on a
royalty-free basis, but I'm not too excited about non-assertion clauses that
favor forking and potential incompatibility.

Wouldn't compliance be an obvious and fair quid-pro-quo for IP
contributions? That would make it at least one kind of restriction on
declared patents that makes sense.

-j

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

[David Recordon]

It's my opinion that formal compliance can come later.  I think the IETF's model of two independent interoperable implementations is a pretty decent start toward compliance. :)

--David

[David Recordon]

To build on this, someone at the BOF last night was talking about how compliance testing is a bit different in a networked world.  In many cases, someone only implementing a part of a specification will end up hurting themselves.

[Simon Phipps]

On Jul 26, 2008, at 10:01, Joe Andrieu wrote:
>
> Wouldn't compliance be an obvious and fair quid-pro-quo for IP
> contributions? That would make it at least one kind of restriction on
> declared patents that makes sense.

It makes sense at first sight, but opens up a hole for gaming.
Measuring "compliance" is really, really hard, and introducing any
kind of dependency for IP grant ("compliance" and "necessary claims"
being examples) immediately renders open source developers unsafe due
to uncertainty.

* Adding "required claims" language (where the grant of rights is
dependent on the only way of implementing your software being to use
the patent) requires an outside expert to help determine eligibility.
* Requiring "compliance" renders the rapidly iterative "use &
improve" approach of open source impossible as only the final,
"compliant" version will be eligible for the grant (and even then only
after following some form of onerous certification process).

I recommend that OWF not allow either "necessary claims" or
"compliance" as predicates to IP grant. A straightforward,
unconditional, sublicensable, non-expiring and ownership-change-
surviving non-assert is the answer in my view. Plenty of dragons to
tame in those words, mind you.

S.

[scottw]

Bit of a slippery slope, David. I like the IETF interop model, which
is part of why its such a good *standards body*. If you're not going
to be a standards body, you have to be very careful about what you
mean here. Why not just "graduate" a spec in terms of IPR clarity and
then let the community choose how it goes towards standardisation,
whether its IETF, W3C, OASIS, CEN, ISO or UN/CEFACT? Those
organisations have the mechanisms for sorting out things like
compliance and conformance specifications and testing/certification
processes.

The fact you are even *thinking* about interop testing and compliance
should raise alarm bells. Are people working on their community-
generated specs in OWF expected to conform to a specific development
process and quality assurance criteria? Set by whom? Or can they
develop their spec however they please and OWF offers them an IPR
*service* and some hosting space if they want it?

Here's a scale:

1. Sourceforge -> 2. Apache -> 3. W3C -> 4. ISO

Currently I'd say OWF sounds like its registering between 2.5 and 2.9.
I'd prefer it to be more around 1.5.

Cheers!

S

[Joe Andrieu]

Simon,

Seems to me the difficulty with compliance depends, in large part, on
whether or not the spec is complete enough to test. As you imply, an
underspecified standard is easy to rev and hard to test for compliance.

But that doesn't mean you can't bake compliance into the spec, with a test
suite.

The last thing I want to do is get into a market-driven standards war with
Microsoft (or any big company) over which variant of a spec is going to
actually be supported by the majority of service/content providers on the
net.

We've seen that mess with HTML, css, and javascript. There's gotta be a
better way.

It seems that the extra work to properly define compliance more than pays
for itself in interoperability. Smart wording of compliance licensing could
manage a reasonable distinction between development and production code.
Code in development must be able to be iteratively evolved, but, IMO, it
shouldn't be moved to production until it is actually compliant with the
standard.

Isn't it precisely that kind of distinction that OWF is here to figure out?
If all we're here for is to define good IPR = non-assertion, that seems to
miss the point. Mind you, compliance-based IPR policy may not be right for
every project, but seems like finding one way to do it well is the kind of
thing that could be leveraged across a lot of projects.

-j

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

> -----Original Message-----
> From: open-web...@googlegroups.com [mailto:open-web-
> dis...@googlegroups.com] On Behalf Of Simon Phipps
> Sent: Saturday, July 26, 2008 1:41 AM
> To: open-web...@googlegroups.com
> Subject: Re: Open Web Foundation characterization
>
>
>

[chris....@gmail.com]

My instinct is that compliance is out of scope for OWF. To David's
comment, now that we live in a networked ecosystem where a bigger
challenge is buy-in from the web community at large, the work of the
OWF incubator should be about helping produce clear, straight-forward
and from my experience, narrowly focused specifications focused on
solving tractable, salient problems. While initial interop may be
necessary to "graduate" (a term I'm not yet comfortable with), our
emphasis and resources should not (if up to me *shall not*) be applied
to compliance because of the reasons Simon cited: the cost to
community-driven projects is prohibitive and inhibitive and
market-driven adoption can be applied to pick from competive
specifications. I think we're also looking to increase the degree to
which individual actors, looking to scratch an itch, can influence
technological innovation.

Two examples: the Delicious API vs the Ma.gnolia API. The latter was
richer, possibly better and more intentionally designed; the former
simpler and easier to implement. The latter took off as such and only
after Ma.gnolia mirrored the delicious API did people start to build
against it. Their was no formal compliance testing -- either it worked
or it didn't, and if it didn't you spent more in support costs dealing
with angry or frustrated customers.

Second is the Flickr API, where a number of services have spring up
that implement it, or portions of it, depending on the purpose of the
application. Again, no formal compliance process there, and yet their
API specification has been both very successful and quite influential
on other similar APIs.

Those are cases informing my thinking here -- as well as cases like
OpenDD or oEmbed, where the specs might be a page or two long and no
more. You typically need compliance testing in systems where
complexity requires more attention than a single developer's. I think
we'd like to enable and encourage an ecosystem of simpler, more direct
technologies and then see where that leads us, through the application
of Darwinian open source survival-of-the-easiest to socialize and
implement!

Chris

[Ben Laurie]

On Sat, Jul 26, 2008 at 2:02 PM, <chris....@gmail.com> wrote:
>
> My instinct is that compliance is out of scope for OWF.

If we want this to be true, then we will have to depart significantly
from existing IPR agreements (or wash our hands of the problems they
introduce), since they pretty much universally talk about "Necessary
Claims", which refer to "Compliant Portions" (of implementations),
which, obviously, have to be compliant with the spec.

So, implementations that are not compliant are not covered by any
non-assert or licence.

Now, I'm no fan of the "Necessary Claims" language but its pretty
obvious that its going to be hard to entirely eliminate, since that
would mean that participants would be granting a free-for-all on all
their patents that can be in any way read to be relevant to the
specification.

[Simon Phipps]

On Jul 26, 2008, at 16:32, Ben Laurie wrote:

> Now, I'm no fan of the "Necessary Claims" language but its pretty
> obvious that its going to be hard to entirely eliminate, since that
> would mean that participants would be granting a free-for-all on all
> their patents that can be in any way read to be relevant to the
> specification.

Sun has done that for ODF. It was cheap and easy for Sun to do (in
terms of legal due diligence), and it declares implementations of ODF
risk-free (at least from Sun) for open source developers.

S.

[Ben Laurie]

Pointer?

[Simon Phipps]

On Jul 26, 2008, at 12:39, Joe Andrieu wrote:

> Seems to me the difficulty with compliance depends, in large part, on
> whether or not the spec is complete enough to test. As you imply, an
> underspecified standard is easy to rev and hard to test for
> compliance.

I don't think it's to do with "underspecification". Java was and is
very thoroughly specified, yet the initial (significantly complex)
compliance tests published in the late 90s were still holey enough to
drive a coach through. Over the years they have become gargantuan and
thorough, but in some cases it is to the point where they test for now-
rarely-used capabilities (CORBA, anyone?). Compliance is
combinatorial, so building compliance suites for any non-trivial
specification will be costly and slow and those who do it will be
likely to seek compensation. And trust me, we don't want that...

> It seems that the extra work to properly define compliance more than
> pays
> for itself in interoperability. Smart wording of compliance
> licensing could
> manage a reasonable distinction between development and production
> code.
> Code in development must be able to be iteratively evolved, but,
> IMO, it
> shouldn't be moved to production until it is actually compliant with
> the
> standard.

I admire your confidence, but experience to date shows what you
describe is not easy. And done imperfectly it creates gameability for
the wiley corporation.

I'd assert that compliance testing is contrary to the open market
spirit of Apache. Just as the Apache license has no concern for the
uses to which downstream users put code that uses it, so I suspect OWF
should have no concern about the way its specifications are used. The
very best compliance test is a comprehensive open source
implementation. Once it exists, implementors will base their work on
that implementation and those who fail to interoperate with it will
become isolated.

OWF should focus on timely open source implmentation. Maybe the
graduation criterion should be the existence of an open source
implementation created by multiple independent parties? As for
compliance: leave it to the standards body that adopts the spec when
it graduates.

S.

[Simon Phipps]

The non-assert for ODF is at:
http://www.oasis-open.org/committees/office/ipr.php
I discuss it at:
http://blogs.sun.com/webmink/entry/ten_reasons_the_world_needs

There's no "essential claims" language in Sun's SAML and OpenID
covenants either, links in that blog posting.

S.

[Ben Laurie]

Well, that's indeed a good thing, though I wonder how one would decide
whether some piece of software implements a specification, and whether
that is, in practice, any different from "Essential Claims".

My non-lawyerly assessment is that in some sense it could actually be
worse - if I only implement part of a specification, would I be
covered by Sun's non-assert? "Implements the XXX specification" would
suggest to me that an implementation had to implement all of it to be
coverered.

To be clear, I am not questioning Sun's intent with these non-asserts
- but I am wondering if they are perhaps too brief...

I'd also note that it is much easier for a company to make this kind
of agreement after the fact, when it is clear what you are giving
away, than when a spec is in the process of being defined. I am
curious whether Sun always did these in retrospect?

[Steve Ivy]

Perhaps a suggestion for new specs would be the development of a
testing suite or validator, and implementations must pass the
validator to be compliant? I'm thinking of something along the lines
of the Feed Validator[1] or the APE[2], for example.

--Steve

[1] http://feedvalidator.org/
[2] http://www.tbray.org/ongoing/When/200x/2006/08/11/Meet-the-Ape

--

[Danese Cooper]

I think its important to mention wrt ODF that Google paid the SFLC a
fair amount of money to review ODF and Sun's potential patent claims
and the effects of the non-assert before drawing the conclusion that
ODF was "safe". So the wording of those agreements has been carefully
reviewed. Not sure I would say it was "easy" given the amount of non-
Sun lawyer time that went into verifying...

I'm not saying Sun is bad here. Just that verification costs money.

Danese

[Ben Laurie]

On Sat, Jul 26, 2008 at 4:47 PM, Danese Cooper <dan...@gmail.com> wrote:
>
> I think its important to mention wrt ODF that Google paid the SFLC a
> fair amount of money to review ODF and Sun's potential patent claims
> and the effects of the non-assert before drawing the conclusion that
> ODF was "safe". So the wording of those agreements has been carefully
> reviewed. Not sure I would say it was "easy" given the amount of non-
> Sun lawyer time that went into verifying...

Was "safe" the outcome, or "acceptable"? I ask because there are
clearly many IPR agreements out there that many companies have found
acceptable, but we wouldn't be here today if they were "safe".

[DeWitt Clinton]

On Sat, Jul 26, 2008 at 7:32 AM, Ben Laurie <be...@google.com> wrote:

On Sat, Jul 26, 2008 at 2:02 PM,  <chris....@gmail.com> wrote:
>
> My instinct is that compliance is out of scope for OWF.

If we want this to be true, then we will have to depart significantly
from existing IPR agreements (or wash our hands of the problems they
introduce), since they pretty much universally talk about "Necessary
Claims", which refer to "Compliant Portions" (of implementations),
which, obviously, have to be compliant with the spec.

I'm in agreement with much of what Simon says.  So I think "Compliant Portions" will need to be carefully but aggressively (re)considered in the OWF IPR policies; there is an inherent difficulty in defining the term "Compliant" without introducing a politicized morass that runs counter to the open source spirit*.  And agreed, that term is extremely poorly defined in the current generation of open IPR policies.

If the worst case outcome is that we require contributors to make slightly broader non-assertion promises as a result, then I suspect few of us here will have too many complaints.  If that shakes out a few potential contributors that refuse, then so much the better for the open web that they've been identified early. 

<soapbox>We're trying to produce intellectual property that can form a permanent part of the fabric of the open web.  There should be no doubt as to the interests and integrity of the contributors.  If we lose some potential contributors because we don't have "Compliant Portions" narrowly defined enough, then those people probably shouldn't be making contributions to the open web.</soapbox>

That's not to say the testability and test suites and multiple implementations for specifications aren't useful, and perhaps even a necessar