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)
-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
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,
[..]
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
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,
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-
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 3rd 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
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-
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.
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
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
>
> 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