IPR Draft Guidelines

[Eran Hammer-Lahav]

DISCLAIMER: This is the work of individuals. It in no way represents the opinions of their employers or companies supporting the Open Web Foundation which can only be made by signing the IPR policy agreement by an official representative of the companies. This document has not been cleared or approved by any company. This is not a legal document and cannot be used for any legal process.

What are the guiding principles of the Open Web Foundation's IPR process?

The Open Web Foundation's IPR process is designed to maximize community involvement. Instead of designing it to resolve worse-case scenarios and edge-cases, the process focuses on community building and participation. The process is modeled after some recent successful community specifications such as OAuth, OpenSocial, and OpenID (prior to the creation of the respective foundations), in which a community came together to work on a specification they were passionate about and were able to produce a quality specification. All three communities started their work without clear IPR policy or process and were able to produce an IPR-clear specification with wide adoption by small and large providers.  In the case of OpenID, this took a few years due to the timing around the community requesting clarity around IPR though with OAuth it was quicker (7 months for IPR) after OpenID having just done it.

The process is an attempt to find the right balance between two conflicting needs: enable the community to participate freely and develop specifications organically vs. ensuring that the specifications emerging out of these communities are freely implementable from an IPR perspective. When such a balance is not attainable, the process goes in favor of the community, utilizing the tools available to it such as public relations and future exclusion of offending parties. The Open Web Foundation's position is that community enforcement is generally preferred to strict legal rules and requirements.  This often goes against the model of formal standards bodies. The focus is on the end result being IPR-free.

What process is used by current standards organizations?

There are two main processes currently used by open standard organizations. The first is based on external work contributed to a standards organization in which the specification is not actually developed within that organization, just refined or adjusted. This is usually done by a very small group of contributors, many times from only one or two companies, and so coming into the standard body has little to no IPR issues. Within the standards body, the focus is getting the necessary votes to pass the specification as a standard. This process represents the strongest upfront scope as it is defined by a full specification contributed to the body. The main utility of this process is to take a successful proprietary specification donated to the public domain by an industry leader looking to create a new market for their services.

The second process is based on a well defined scope which is negotiated among all the key participants prior to any actual specification work. Many times companies write unpublished specification drafts ahead of such negotiation, using them to have a better understanding of where they want to end up, but during the scope process such drafts are usually not shared. In reality, the negotiation process over scope is where most of the specification work is done. Once the detailed scope is finished, there is usually very little technical freedom as the scope defines the potential patents covered by the specification. The main utility of this process is to enable industry coalitions or consortiums to work together on well defined needs and produce IPR free specifications.

Why can't the Open Web Foundation use existing IPR processes?

The decision to create a new process and not to use the current processes established by exisiting standard bodies comes form the actual reality of the communities the Open Web Foundation emerged from. After years of experience with the common standard bodies process, we can fully appreciate the value they provide but also the significant pitfalls they create. Some organizations leave it up to the specification editors to decide on their IPR policy. The reality is that the types of communities that are emerging to create open specifications for the web do not feel that they fit within existing processes often oriented toward big company participation.

The two main issues with these processes are that they are strongly designed to accommodate and protect big companies, and that they usually take a very long time from idea to final specification. Other issues include complicated bureaucracy, the need for strong political allies within the board or other such entities to get work done, complicated legal documents inaccessible by most individuals, expensive fees and travel costs, and an existing body of work which in many cases creates a strong bias against new ideas.

The reality is that many new communities are voting with their feet and stay away from such bodies. They knowingly create work that is not legally protected from the IPR perspective because the alternatives are just not practical. The specifications mentioned earlier are perfect examples of work that would not have been as successful within the current processes, mostly because it would have been impossible to define the necessary scope that would have allowed them to operate within most standard bodies. Time to market has also been dramatically changed from years to months which these processess do not properly accomodate.

What is the proposed Open Web Foundation's IPR process?

The new IPR policy places the IPR steps at the beginning and end of the incubation process, creating entry and graduation requirements for projects. The process intentionally leaves a significant part of its enforcement up to the community using non-legal tools.

In order for a project to be accepted into incubation (beside other non-IPR requirements), the initial contributors must all sign a Contributor License Agreement (CLA) which licenses their copyrights of any contribution to the foundation. What this means is that the foundation will be allowed to freely use the contribution in published materials and make them freely available to anyone under the Creative Commons Attribution license (or similar). The CLA is intended to be signed by unaffiliated individuals and the employers of anyone who is affiliated with a company (which may own all IPR created by such individual).

The CLA includes two other provisions. First, it includes a declaration in which the signing entity states their intention to sign a non-assertion agreement (non-assert) with regard to patents covered by the final specification. This declaration means that as long as the final specification is within the general boundaries of the project charter, the entity intends to sign a non-assert on the entire specification. While this does not guarantee that all contributors will sign the required patent non-assert, it places community pressure to do so and raises the bar for entities withdrawing their contribution from the project. The second provision is that the entity agrees to the language of the non-assertion agreement which will not be open for negotiation at the conclusion of the project.

In order to graduate from incubation (again, beside other non-IPR requirements), the project must obtain signed Patent Non-Assert (PNA) agreements from all contributors to the particular specification. Without going into the legal details of the agreement, it basically means that the contributors promise not to sue anyone for implementing any part of the specification. If the project is unable to obtain such signature from a contributor, the project's community must resolve it by excluding any such contribution from the specification and obtaining signatures again for the modified specification. To graduate, the project's community must obtain such signatures from all contributors and it is up to the community as to how to reach that position. The incubation process might include provisions for handling such situations but the IPR process simply requires full coverage of all listed contributors. Projects are free to negotiate specification changes, remove contributions altogether, or engage in other means to reach the finish line with all contributions non-asserted.

The Open Web Foundation process does not leave it up to the editors to make IPR decisions. Any Open Web Foundation specification enjoys the same equal protections and guarentees.

What kind of protections does the IPR process offers?

The two most important protections provided by the process address both individuals and companies. The first protection is the guarantee that any final specification graduating from the Open Web Foundation is offered freely and implementers cannot be sued by any contributor (the risk of being sued by non-contributors always exists and can only be removed by waiting 20 years or so until all patents expire).

The second protection is for companies with a patent portfolio having a process in which they can first evaluate the risk to their portfolio during the CLA step (by studying the project charter and making sure it doesn't overlap with their properties), and at the end by getting to review the final specification before agreeing to the PNA. This protection is critical for the community to grow, for individuals to be able to contribute, and for specifications to develop organically within the community and not during a legally-heavy upfront scope process.

The process also ensures that all copyrights are licensed appropriately and that specifications can be distributed freely including translations.

What are the process' shortcomings and how are they being addressed?

The process does not guarantee that the community's work will produce a specification. Since up until the final specification there is no legal requirement to disclose any IPR claims or non-assert contribution, contributors may introduce proposals that they or their employer will refuse to sign the PNA at the end. In addition, the process doesn't protect early adopters as their work will be based on specifications that have not yet been non-asserted, nor does it provide any protections from non-contributors (however this last risk is common to all specifications including standard bodies).

The short answer to how these concerns are addressed by the foundation process is 'the community'. The process is based on the strong belief that the community has the power to self regulate and reach the necessary consensus. Instead of requiring unanimous voting or a specific process to remove contributions, the foundation is allowing each community to regulate itself and to obtain the necessary signatures to graduate from incubation.

If a contributor does not sign the PNA their contribution cannot remain in the specification. The Foundation is well aware that this might cause significant problems, but given the entire process, and the stiff community price to be paid by not signing the PNA, we believe that the risk is worth the reward for a simple process with a very low entry barrier.

This does not mean that the Foundation will not provide tools and guidelines on how to avoid such circumstances. The Foundation will provide tools for better tracking contribution and offer templates on how projects can resolve such deadlocks. But the key is that these will remain outside the scope of the legal IPR process which tend to be complicated, expensive, and inaccessible by most people who are not IPR lawyers.

How does the IPR policy handle trademarks?

Trademarks remain the proverbial stick by which projects can regulate acceptable use of their brand.  While the goal of the Open Web Foundation is to promote free and unrestricted use of the intellectual property of open web technologies, this is not to say that all uses are equally good or aligned with the spirit of a particular community.  By registering and enforcing trademarks, individual communities can prevent the dilution or damaging of their of brand.

The Open Web Foundation will maintain its own trademark, as well as the trademarks of projects who wish to assign such IPR to the foundation. The foundation does not require projects to assign or even deal with trademarks, however, if desired, it will assist and manage that legal process for the projects who opt-in. If a trademark has been assigned to the foundation, it will operate in the same manner as all other trademarks owned by the foundation.

The licensing and usage policies with regard to foundation trademarks are still being developed.

How does the Open Web Foundation deal with source code?

It doesn't. The Foundation focus is on publishing open specifications. These specifications may drive source code projects and even end up as standards but those steps are beyond the scope of the foundation IPR process. The Foundation is expected to work closely with other organizations such as the Apache Software Foundation as a complementary resource for the incubated projects.

Why is the Open Web Foundation using Patent Non-Asserts instead of Licenses?

It is not yet absolutely certain it will, but non-assert covenants - the promise not to assert or sue an implementer - may be as good as licenses when it comes to open specifications. The covenant used by the IPR process simply guarantees that implementers are free to use the specification without any risk of being sued by the contributors. The benefit of this approach is that it is much easier to read and understand by people who are not IPR lawyers, is significantly shorter than licenses and other IPR agreements, and does not introduce other legal side effects for both contributors and implementers. It is just a promise not to sue.

Patent non-asserts have been gaining momentum and have been used by the communities the foundation is based on (OAuth, OpenID, and OpenSocial). While there are merits to outright license grants (such as the potential to relicense without further approval, such as when a spec is taken to a standards body), the simplicity and corporate preference to these agreements are important counter-factors that are more inline with the community building goals of the Open Web Foundation.

What constitute a contribution?

The entire IPR process is based on the notion of a contribution. Contributions are made to an open specification within the boundaries of a project and the IPR process is specific to each project (that is, if you sign an agreement for one project, it does not affect other projects). Projects may have many participants and supporters but not all of them are considered contributors. The decision of who is considered a contributor is hard to define and is something the project leads or spec editors will have to manage

However, there is a simple test that can assist in defining what does not constitute contribution. Any participation that does not contain new ideas and merely states an opinion regarding ideas presented by others does not count as contribution for the purpose of the IPR process. This includes voting for or against changes, offering grammatical edits or proofs, or offering analysis of specification drafts. As long as the participation is not by itself an idea, new or improved, and is just a response to the work of others, it does not constitute a contribution.

Who is responsible for getting companies to sign CLAs and PNAs?

While the foundation and project leads may be involved in obtaining signatures from corporate entities, it is ultimately the responsibility of the employees of such entities to obtain such agreements. When an employee applies to join a project as a contributor, the project leads must check if the individual is affiliated with another entity or not. If the individual is affiliated they must obtain a signed CLA from that entity, unless that entity already signed a CLA for that project for a previous employee. Unaffiliated individuals sign CLAs on behalf of themselves.

At the conclusion of the project work, the project leads must ensure each contributor has obtained a signed PNA from their affiliated entity or on behalf of themselves (for unaffiliated individuals). It is the responsibility of the contributor to approach its employer and obtain the PNA, however project leads are expected to assist in the process.

The foundation may provide tools to assist editors and project leads to better facilitate this process.

 

(This will be posted on the wiki as well)

[DavidIllsley]

Lots to read and think about! One point of clarification: The snippet
below seems to suggest that a project cannot graduate from incubation
without releasing a 'final specification'. Is that what is intended?

"This declaration means that as long as the final specification is
within the general boundaries of the project charter, the entity
intends to sign a non-assert on the entire specification. While this
does not guarantee that all contributors will sign the required patent
non-assert, it places community pressure to do so and raises the bar
for entities withdrawing their contribution from the project. The
second provision is that the entity agrees to the language of the non-
assertion agreement which will not be open for negotiation at the
conclusion of the project.

In order to graduate from incubation (again, beside other non-IPR
requirements), the project must obtain signed Patent Non-Assert (PNA)
agreements from all contributors to the particular specification."

David

[Gabe Wachob]

I assume this is this way because without a final spec that is clear
about what IPR is in or out, contributors will not sign a non-assert.

-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

[Eran Hammer-Lahav]

Yep. You need a point of reference. There is nothing preventing a spec to have any other designation such as final draft, etc. as long as from the IPR process perspective, it is a final version ready to be non-asserted.

EHL

[Daniel Weitzner]

Nice document. I'd like to offer one suggestion. Reconsider the timing
of the final patent non-assert/license commitment -- seek an earlier
patent commitment for participants.

As described here[1], participants make an initial 'intent to sign a
non-assert' and then have to sign the actual non-assert when the spec
is finished. While I am certainly aware that this will provide greater
certainty for patent holders, it puts the developer community under
significant pressure due to uncertainty and seems out of sync with the
stated preference to resolve such tensions in favor of the
community[2]. As a user and implementer of OpenID, for example, I can
say that early uncertainty about licensing there was a real
disincentive to early use in my work. I see OWF as an effort to
minimize this uncertainty and suggest pushing as far as possible in
that direction.

I'd suggest picking some earlier point in the process to seek final
commitments. Perhaps a set number of weeks after the group starts
working, perhaps after x number of spec drafts have been produced. Or,
perhaps the group can decide for itself the point at which the spec is
baked enough to request final patent commitments. It's also possible
to set early commitment as a goal, though not a requirements. This
would be a way to bring positive community pressure to bear on the
process.

If a group's work is reasonably well scoped out, then it should be
possible even for large patent holders to make early commitments.In
most cases, the decision to make an open, RF licensing commitment is
really much about business strategy, than about the low-level
technical and legal details of which patent claims are included and
which excluded. The commitment to license without seeking fees or
restrictive conditions is generally based on a decision that it is in
the **business interest** of the patent holder to have an open,
unencumbered spec in the particular technical area. (There may be some
exceptions to this, but EVEN in the W3C process, characterized by some
here as being just about the big-guys. :-), this is what we found.)

Thanks,

Danny

[1] Section on non-assert timing

On Jul 28, 2008, at 10:51 PM, Eran Hammer-Lahav wrote:

>

[..]
[2] Section on balancing needs of community and patent holders
[from earlier in the document]

>
> The process is an attempt to find the right balance between two
> conflicting needs: enable the community to participate freely and
> develop specifications organically vs. ensuring that the
> specifications emerging out of these communities are freely
> implementable from an IPR perspective. When such a balance is not
> attainable, the process goes in favor of the community,

[..]

[Sam Ruby]

On Tue, Jul 29, 2008 at 1:51 AM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
>
> Who is responsible for getting companies to sign CLAs and PNAs?
>
> While the foundation and project leads may be involved in obtaining
> signatures from corporate entities, it is ultimately the responsibility of
> the employees of such entities to obtain such agreements. When an employee
> applies to join a project as a contributor, the project leads must check if
> the individual is affiliated with another entity or not. If the individual
> is affiliated they must obtain a signed CLA from that entity, unless that
> entity already signed a CLA for that project for a previous employee.
> Unaffiliated individuals sign CLAs on behalf of themselves.
>
> At the conclusion of the project work, the project leads must ensure each
> contributor has obtained a signed PNA from their affiliated entity or on
> behalf of themselves (for unaffiliated individuals). It is the
> responsibility of the contributor to approach its employer and obtain the
> PNA, however project leads are expected to assist in the process.

This sounds like an either/or, namely either an individual or
corporate CLA is required to cover every contributor. In practice,
who owns the IP contained in a contribution of an employee may vary
from company to company and even jurisdiction to jurisdiction.

The ASF approach is to require an ICLA from every sustained
contributor, and in the ICLA (section 4, to be exact) states that the
person represents that they are legally entitied to grant the license,
including the rights necessary from their employer, via either
explicit permission, a waiver, or a separate CCLA.

- Sam Ruby

[Eran Hammer-Lahav]

This is a very good point.

Before any company is going to sign a license or non-assert they are going to review the exact scope and details of what they are signing. That means you need to have a stable document. For companies to do that early, you need a very well defined scope that they can be comfortable with, which really means you are writing the spec before you write the spec... :-)

I would expect specs that take years to develop to publish stable drafts along the way and get them IPR clearance. So you can think about that as treating a draft as final for a short period of time. That is, the license/non-assert is only good for the duration in which the spec is valid (for example, IETF expires draft after a fixed number of days).

The problem with asking for early non-asserts is that it takes away from the value of the patent. When you go to court to enforce your patent, the court looks at previous licenses you granted when considering how to move forward. This means that giving temporary licenses can take away from the value of the patent even after the license expires.

We are starting from the end, making sure that final specs are free to implement for ever. Protecting early adopters is an issue we currently don’t have good ideas on how to protect. However, the reality is, this isn’t really any bigger risk than being sued by any other third party.

EHL

[Gabe Wachob]

The OpenID IPR process uses the concepts of "Implementer's Drafts" as
intermediate steps to which non-asserts are made.

A contributor is allowed to withdraw from a WG at any time, but their
non-assert w/r/t the lastest Implementer's Draft cannot be revoked.
They can,however, withdraw and are NOT obligated to issue a non-assert
on further drafts or the "Final Specification". This gives
contributors the right to withdraw if they feel that the WG is
broadening the spec to require use of IP that a contributor to the
spec may not want to contribute.

Would this satisfy an "earlier patent commitment" need? A sort of
phased commitment as things get closer and closer to final
specification...

-Gabe

--

[Eran Hammer-Lahav]

The problem with that is the repeated effort needed by large players to perform legal review on spec drafts because an employee really cares about it. And small players with a potential patent or two to keep paying for legal services to review specs and make sure their assets are protected. It is reasonable to have to review a spec 1-2 times a year but OAuth had 7 drafts in 4 months. How would you apply this approach to that?


EHL

[Daniel Weitzner]

Eran,

One question and one comment...

On Jul 30, 2008, at 8:50 PM, Eran Hammer-Lahav wrote:

> This is a very good point.
>
> Before any company is going to sign a license or non-assert they are
> going to review the exact scope and details of what they are
> signing. That means you need to have a stable document. For
> companies to do that early, you need a very well defined scope that
> they can be comfortable with, which really means you are writing the
> spec before you write the spec... :-)

I understand this in theory but not in practice. At least two of the
more formal standard groups (W3C and OASIS) are able to get licensing
commitments from participants based on a combination of a a charter
(which is usually just a page or so) and an early draft of a spec. Is
there are reason that OWF would need to give patent holders more leeway?

>
>
> I would expect specs that take years to develop to publish stable
> drafts along the way and get them IPR clearance. So you can think
> about that as treating a draft as final for a short period of time.
> That is, the license/non-assert is only good for the duration in
> which the spec is valid (for example, IETF expires draft after a
> fixed number of days).

Can you explain this further? Does this mean that you think there will
be lots of incrementally changing drafts each of which will have a non-
assert from all participants?

thanks,

Danny

[Gabe Wachob]

Eran-

Completely valid point - but it comes down, again, to the balance of interests of the community (maximum, earliest non-assertion commitments) vs corporate/organization interests (costs/risks of making those commitments).   

In the context of OAuth, this was kind of a non-issue, I *think* because everyone involved wasn't really paying attention to the IPR issues, due in part to the fact that there was personal familiarity. Also, I don't think the larger orgs with "strategic interest" in patents (those who want to limit contributions of IPR) were contributing directly.  Thus, an intermediate commitment probably wasn't needed. In broader efforts, with a more diverse set of contributors, that may not be the case.

I would expect, like in OpenID, that "number of implementers drafts" knob could be adjusted by each group. Perhaps they wouldn't even need one if the group didn't want it. But the mechanism would be there to allow early/midprocess commitments of IPR. This shows, at the very least, good faith and some commitment to openness on the part of all the participants. Its a very good signal to the outside community that the IPR waters will not be choppy if there's an IPR commitment to an intermediate draft. 

   -Gabe

[Joe Andrieu]

Eran,

 

Do you really need legal to keep reviewing a changing spec?

 

As a small startup guy, I think this is mostly a non-issue. My concern is with the IPR itself first, which is a legal issue. Then as the spec evolves, it becomes a technical issue and I should be following it closely anyway.  I'll have lawyers review the IPR and potentially the first spec, but from that point on, I doubt it makes sense to keep having legal review it. As you suggest it is simply too expensive.

 

As someone said, the main choice is strategic, not technical. So, once the main IPR is ok, the evolving spec is a matter of technical, not legal review, which falls to the tech team (who should all be cognizant of the IP issues that matter for the spec and exactly the lines drawn by the lawyers in the first review).

 

That said, the fewer "Implementer's Drafts" the better.

 

-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 Gabe Wachob
Sent: Wednesday, July 30, 2008 7:56 PM
To: open-web...@googlegroups.com
Subject: Re: IPR Draft Guidelines

 

Eran-

[Eran Hammer-Lahav]

Your second question first. I think that some projects are going to take longer than others. I such cases, they might want to have implementations tried out for a long period of time before declaring a spec final. If you know you are going to take some time to let a draft be tried out, you might want to have it non-asserted.

As to your first comment. It is critical to understand how organizations such as OASIS and W3C obtain such commitments prior to a final spec, and what those really mean. They all have withdrawal provisions which in some cases take IP with them. The commitment isn't fully legally binding and is open to wide interpretation. That early draft you mention is a critical point and a big problem because that is the stick big companies use to keep the WG in line with that draft they are happy with (and usually the one drafting). You need to read exactly what they give up front and what it means.

But beside the fact those upfront promises are not absolute protections, they create a major obstacle for building a wide community. You have companies like IBM and Microsoft (and this is not meant as criticism) who hire people full time just to work on standards and they are experts on both the subject matter but also the company's IP portfolio. On the other side, you have companies like Yahoo! who are more defensive about their IP and want their employees to go through some review process before any standard body participation. This is one of the main reasons why many W3C member companies do not encourage their employees actually participate in WG.

EHL

-----Original Message-----
From: open-web...@googlegroups.com [mailto:open-web...@googlegroups.com] On Behalf Of Daniel Weitzner
Sent: Wednesday, July 30, 2008 7:50 PM
To: open-web...@googlegroups.com
Subject: Re: IPR Draft Guidelines

[Eran Hammer-Lahav]

This is not how it works though. From a legal stand point, a small change to the spec can mean big IPR impact. I like using OAuth as an example because I know every little detail, it was the success that inspired the OWF among other things, and it is recent enough to reflect the current state of the community. With OAuth, around the 3^rd draft we change the 3 separate workflows (server, desktop, mobile) into one unified flow. That is brand new IPR potential.

 

Anytime you sign a non-assert or grant a license, every word of what you sign matters. If you read some patent litigation you will see how the entire case can revolve around a couple of words. So I disagree with the notion of ‘main IPR is ok’ because there is no such thing. I also don’t want any process that calls for any evaluation of IPR and patents applicability. The only place that should happen is in front of a jury.

 

Are you a small startup with patents? If you don’t have loads of cash or patents, you should not really care about IPR either way. You can’t really lose your IP and no one will sue you if you have no money for them to go after. But the little guy who has a little IP is going to have a problem with repeated reviews. The big guy is going to be yelled at by his/her legal team about wasting their time with all these constant reviews.

 

EHL

[Eran Hammer-Lahav]

See, this assignment of interest is wrong. The most important interest of the community is to have a community. If the people you want to be part of your work (say, because they are world experts and industry leaders in the space) are not allowed because their employers is too afraid to let them, the community pays the price. Participation is crucial.

 

Crafting this policy is like building a D&D character. Whatever skill you gain means skill lost when you assign your initial points. Yes, from licensing perspective it is the IP holder (usually bigco) vs. the implementer (usually littleguy). But that is just one axis things operate on. Another is guaranteeing being able to produce a spec which comes at a cost of upfront compromises in scope. Sweeping absolute licenses vs. IP holders comfort to allow their employees to participate.

 

Maybe standard bodies use the duty to declare IP as a key element of their process. But they write those provision in a way that doesn’t protect you from my employer, if I truly have no clue what IP my employer has and hence cannot disclose it.

 

The two top goals I would like to see accomplished are:

 

1.       Final specs are free, really free, absolutely free, no fine print no loopholes.

2.       Everyone can participate and employers don’t feel the need to stand in the way.

 

EHL

 

 

From: open-web...@googlegroups.com [mailto:open-web...@googlegroups.com] On Behalf Of Gabe Wachob

Sent: Wednesday, July 30, 2008 7:56 PM
To: open-web...@googlegroups.com
Subject: Re: IPR Draft Guidelines

 

Eran-

[Joe Andrieu]

Good points. As I've said before I'm an IPR newbie, so this is a learning experience as much as anything.

 

FWIW, we are both small and have IP. And that is precisely why IPR is a hot button of mine—and why I'm stoked that OWF showed up when it did.

 

Your points have me leading to non-binding statements of intention early, with the binding non-assert on Final, as originally suggested.

 

-j

 

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

 

[David Recordon]

On Wed, Jul 30, 2008 at 11:33 PM, Joe Andrieu <j...@switchbook.com> wrote:
> Your points have me leading to non-binding statements of intention early,
> with the binding non-assert on Final, as originally suggested.

:) We have been thinking about this and trying a few different things
over the past year.

--David

[David Dillard]

On Jul 31, 2:28 am, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> See, this assignment of interest is wrong. The most important interest of the community is to have a community. If the people you want to be part of your work (say, because they are world experts and industry leaders in the space) are not allowed because their employers is too afraid to let them, the community pays the price. Participation is crucial.

Amen!

[Ben Laurie]

On Thu, Jul 31, 2008 at 3:50 AM, Daniel Weitzner <djwei...@gmail.com> wrote:
>
> Eran,
>
> One question and one comment...
>
> On Jul 30, 2008, at 8:50 PM, Eran Hammer-Lahav wrote:
>
>> This is a very good point.
>>
>> Before any company is going to sign a license or non-assert they are
>> going to review the exact scope and details of what they are
>> signing. That means you need to have a stable document. For
>> companies to do that early, you need a very well defined scope that
>> they can be comfortable with, which really means you are writing the
>> spec before you write the spec... :-)
>
> I understand this in theory but not in practice. At least two of the
> more formal standard groups (W3C and OASIS) are able to get licensing
> commitments from participants based on a combination of a a charter
> (which is usually just a page or so) and an early draft of a spec. Is
> there are reason that OWF would need to give patent holders more leeway?

I don't know how W3C works in practice, but I've heard that OASIS
specs tend to be mostly done before they start the OASIS process. Am I
mistaken?

[Gabe Wachob]

On Jul 31, 2008, at 10:16 AM, Ben Laurie wrote:
>>
>> I understand this in theory but not in practice. At least two of the
>> more formal standard groups (W3C and OASIS) are able to get licensing
>> commitments from participants based on a combination of a a charter
>> (which is usually just a page or so) and an early draft of a spec. Is
>> there are reason that OWF would need to give patent holders more
>> leeway?
>
> I don't know how W3C works in practice, but I've heard that OASIS
> specs tend to be mostly done before they start the OASIS process. Am I
> mistaken?
>

I don't think thats uniformly true at all. I know some specs have been
completely rewritten from scratch several times in OASIS ;)

-Gabe

[Daniel Weitzner]

On Jul 31, 2008, at 1:16 PM, Ben Laurie wrote:

>
> On Thu, Jul 31, 2008 at 3:50 AM, Daniel Weitzner
> <djwei...@gmail.com> wrote:
>>
>> Eran,
>>
>> One question and one comment...
>>
>> On Jul 30, 2008, at 8:50 PM, Eran Hammer-Lahav wrote:
>>
>>> This is a very good point.
>>>
>>> Before any company is going to sign a license or non-assert they are
>>> going to review the exact scope and details of what they are
>>> signing. That means you need to have a stable document. For
>>> companies to do that early, you need a very well defined scope that
>>> they can be comfortable with, which really means you are writing the
>>> spec before you write the spec... :-)
>>
>> I understand this in theory but not in practice. At least two of the
>> more formal standard groups (W3C and OASIS) are able to get licensing
>> commitments from participants based on a combination of a a charter
>> (which is usually just a page or so) and an early draft of a spec. Is
>> there are reason that OWF would need to give patent holders more
>> leeway?
>
> I don't know how W3C works in practice, but I've heard that OASIS
> specs tend to be mostly done before they start the OASIS process. Am I
> mistaken?

I can't speak to OASIS, but W3C is a pretty even mix across the
spectrum from starting with a charter and a blank page, to small fixes
on a complete spec.

For reference as of today, the W3C patent policy has produced:

• 198 specifications, including 26 W3C Recommendations
• produced by 48 W3C Working Groups operating under the W3C Patent
Policy
• 636 licensing commitments made by 222 different W3C Members

This is with a model the depends on a charter and first/second draft
specs defining the scope of the RF license commitment.

[Eran Hammer-Lahav]

In the past 2 years (don't care about earlier statistics), what do these numbers look like and what is the average time from suggesting a spec to final?

Speaking only for myself, I never claimed other bodies are broken or don't work. I just don't think they works for me. They don't create the kind of community I want to be part of.

EHL

-----Original Message-----
From: open-web...@googlegroups.com [mailto:open-web...@googlegroups.com] On Behalf Of Daniel Weitzner
Sent: Thursday, July 31, 2008 10:42 AM
To: open-web...@googlegroups.com
Subject: Re: IPR Draft Guidelines

* 198 specifications, including 26 W3C Recommendations
* produced by 48 W3C Working Groups operating under the W3C Patent
Policy
* 636 licensing commitments made by 222 different W3C Members

[John Kemp]

Hi Eran,

Eran Hammer-Lahav wrote:
> In the past 2 years (don't care about earlier statistics), what do
> these numbers look like and what is the average time from suggesting
> a spec to final?
>
> Speaking only for myself, I never claimed other bodies are broken or
> don't work. I just don't think they works for me. They don't create
> the kind of community I want to be part of.

I drew the conclusion that the kind of community I want to be part of is
one where I feel (both myself, and on behalf of my company) I am in a
position to create something useful within a group of other like-minded
individuals. That has so far depended on a) a reasonable and written IPR
commitment from participants (and their companies) and b) the intent and
actions of others (a very vague concept not usually written down
anywhere!) to also create something interesting.

W3C (and others) have attempted to legislate the former, often with
apparent success (in that some members create and implement a
specification). However, there's still the b) part, which is (I think)
harder to legislate than the written legal language governing IPR as it
has largely to do with things like corporate politics and interpersonal
relationships.

I agree with you that standards bodies don't always create "the kind of
community I want to be part of", but if a standards body is successful
at achieving anything, it's a fair bet that at some point, some people
who join will have different motives than you or I for participating.

How will we get OWF to deal with this any better than others have been
able to do?

Regards,

- johnk

[Daniel Weitzner]

On Jul 31, 2008, at 2:07 PM, Eran Hammer-Lahav wrote:

>
> In the past 2 years (don't care about earlier statistics), what do
> these numbers look like and what is the average time from suggesting
> a spec to final?

I don't have statistics on that but my gut sense is that average start-
to-finish

>
>
> Speaking only for myself, I never claimed other bodies are broken or

> don't work.I just don't think they works for me. They don't create

> the kind of community I want to be part of.

I can understand that. By the same token, I would never claim that the
current array of standards organizations meets all needs. Seems that
OWF is responding to a new set of needs from a new community of
developers. That's how W3C grew out of the IETF and that's earlier why
the people who got IETF together never felt they should go to the
formal standards bodies of the time.

All that said, I'm here partly because I'm a user of some of the
recent lightweight specs, and because I hope that some of what has
been learned about IPR policy at W3C (at great pain to myself. :-) )
will be useful to the OWF effort. Also, I'm hoping that the IPR models
that OWF comes up with will be easily interoperable with those of W3C,
so that our specs an reference each other where needed.

Danny

[Eran Hammer-Lahav]

I think there are two issues here. One is how to keep the foundation itself consistent with the ideals the founders had in mind. The other is how to keep individual projects free of people who try to change the nature of the community that is working on a particular spec. I think the bylaws and closed membership will keep the foundation consistent. It works well for the ASF which is the model we are building on. As for the spec, I think it is really up to the personalities involved and the communities will need to self regulate. The OAuth leads had an idea and we made sure the community didn’t change.

EHL