Speaking of patent licenses
DeWitt Clinton
http://code.google.com/apis/gdata/patent-license.html
Patent License
Subject to the terms and conditions of this License, Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this License) patent license for patents necessarily infringed by implementation (in whole or in part) of this specification. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the implementation of the specification constitutes direct or contributory patent infringement, then any patent licenses for the specification granted to You under this License shall terminate as of the date such litigation is filed.
See, they're not that hard to write. : )
-DeWitt
Simon Phipps
Gabe Wachob
DeWitt Clinton
But I will say this -- we're talking about technology that is ostensibly given to the public to help build a better and more interoperable Internet. If the public has to live in fear when using that technology then we still have a long way to go in creating a truly open web.
My sincere and personal hope is that the Open Web Foundation makes is poignantly clear that if you contribute to something you want called "open web" then you are not going to be allowed to play games, you are not going to be allowed to hold litigation threats in your back pocket, you are not allowed to say "it's okay for you to use these contributions for this one purpose, but not that other one you have in mind." You may be giving up something, something real, but the end result is much bigger and much more beneficial than what we have today.
This is going to be hard on some who depend on how that game is played. But maybe it is time those rules changed.
(The lawyers are here to help us make that happen.)
-DeWitt
Joe Andrieu
DeWitt,
I think your position is alienating to IP owners and doesn't support the idea of a community working together. Granting a non-assert in support of a specification shouldn't mean that developers get to use that IP for other applications. The applications have to implement the spec.
Consider some novel, patented approach to OCR that uses a proprietary image format and somehow that format requires that OCR magic. Further, that format is a good idea for a standard and the owner is willing to contribute the IP for that purpose. That shouldn't allow you to go use that OCR on some other file format or for video.
Licensed IP, grants, non-asserts, however the mechanism works, must be related to the covered specification and implementations thereof.
Did I misread your comment or do you really think that IP contributed to a specification needs to be given to the world for use anyway anyone wants?
-j
--
Joe Andrieu
SwitchBook
http://www.switchbook.com
j...@switchbook.com
+1 (805) 705-8651
Chris Messina
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
DeWitt Clinton
This is the place where we are discussing open web technologies. We're not going to solve all IP problems here. On the contrary, we're concerned about a very specific subset. The same subset that is generally understood to be covered today by open source code licenses like the Apache License.
Let's read that license again now:
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
We need to work to make the spirit of this license apply to works other than source code. It's the "necessarily infringed" and "Work" language that we need to focus our attention on here. (And I only use the Apache license as an example of the spirit that we're getting at, if there are better ways of getting there then that's on the table, too, of course.)
Oh, and I'm perfectly happy to see some people not contribute to open web technologies if they don't like these terms. Like I said, there are plenty of other places that exist for other types of licensing terms.
I think that perhaps there are a lot of people paying attention to this list because they aren't happy with the existing standards organizations. If so then I'm sorry, but simply that's not be the problem we're trying to solve here. If there are specific things that the standards organizations can do to improve, then please take it to their lists. This list is about taking a successful model for open source and applying to an ever increasingly specification and protocol enabled web.
-DeWitt
Joe Andrieu
Nothing in the Apache license contradicts my point. But I will suggest, diplomatically, that the stated purpose of OWF is not to abolish IP or to make developers happy. It is to enable an open web.
And that means meeting both the needs of IP holders and developers. Otherwise, you'll find a bunch of IP holders finding alternatives that aren't so onerous.
To require blanket non-asserts, independent of whether or not the use is actually related to the specification, is a non-starter for many, many of the companies that I believe we want to participate in this community. This isn't about making a smaller pond in which developers have free reign. It's about creating a vastly larger pond where developers and IP owners can build on open specifications without fear of litigation or losing the value of our contributions.
I'll be clear: I'm not here because other standards bodies suck.
I'm here because an open web, in the sense of NEA, is better. For everyone.
If you want a paradigm that reaches broadly, instead of getting stuck in GPL-style battles over IP v FREE software, I think you'll find necessary claims and reciprocity—in some form—required. Otherwise, you're just asking for donations to the public domain, which isn't much of an improvement on GPL and, IMNSHO, would remain as limiting. As I've mentioned before, there is necessarily a boundary between what the non-assert covers and what it doesn't. That boundary needs to be made clear, both in terms of the non-asserting party's IP and in terms of its use. I argue that implementations of the specification is the right locus for that, rather than some explicit list of IP and applications.
So, rather than me misstating what I think your position is, could you clarify from the opposite direction?
What restrictions do you think /are/ reasonable?
Or do you really think a complete, unrestricted gift of any and all of a company's IP for any purpose is the "OWF Way" to non-assert?
-j
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
"An inconvenience is an adventure wrongly considered. An adventure is only
an inconvenience rightly considered."
--G. K. Chesterton
Daniel Weitzner
+1
What may be hard to get patent holders to cross from the RAND/
protective style of licensing business over to this approach, where
that patent holder sees it as being **in it's own interest** to make
licenses available on very open terms.
Danny
Chris Messina
Otherwise, you're just asking for donations to the public domain, which isn't much of an improvement on GPL and, IMNSHO, would remain as limiting.
What restrictions do you think /are/ reasonable?
Or do you really think a complete, unrestricted gift of any and all of a company's IP for any purpose is the "OWF Way" to non-assert?
Eran Hammer-Lahav
What we want is to know that we can implement “this spec in full or in part” without being sued by “these contributors”. As was also pointed out, “this spec” gets to be a tricky term because someone can take OAuth, “enhance it” to the point it looks like a different protocol and claim protection because his code is OAuth+. This is where we start to have problems. Most IPR leave this up to the jury to decide. They define “compliant portions” in all sorts of ways that make people happy/sad. I don’t think we are going to get a “patents in the public domain” solution.
EHL
Joe Andrieu
Chris,
Let me first answer your questions specificall and then it would be great to get an answer to mine. =)
Joe, where are you imagining that I make my money from my patent? Presumably not through lawsuits -- but potentially through licensing agreements?
Sure, lawsuits are a failure of the system. Important, sure, but not the kind of thing I'd support as a business model.
You make money by licensing or embedding it in a product.
The issue that seems to be getting missed here is the /boundary/ of the rights you've given up. I'm suggesting we must be clear about what those boundaries are. DeWitt, and now you, seem to suggest that ANY boundaries are bad, which just doesn't make sense t me. So, either there's some unstated assumptions I'd like to see out in the open or we really are operating from different propositions.
If so, if I've pledged to not assert the "property rights" that I have over a given idea or implementation, why would someone license said patented technology from me?
Just because you give up the right to assert property over a set of IP doesn't mean you can't assert your rights over other IP, even potentially "related IP", even IP bound up in the same patent. IP Portfolios are complicated. Trying to figure out what is covered by the IPR should be covered clearly early, and while developers might like it, I don't think it's going to be as free of encumbrances as possible.
So let me restate the strawman that I think/hope we would agree is far too anti-IP for practical use:
The over-the-top non-assert, a covenant not to sue anyone over any IP ever, for any reason.
Clearly, if everyone joining an OWF working group agreed to that, it would make life easy for developers using the resulting spec. But I think we would agree that that non-assert would NOT be agreed to by most companies.
So, I'll ask the question again:
What restrictions /are/ appropriate?
-j
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
"An inconvenience is an adventure wrongly considered. An adventure is only
an inconvenience rightly considered."
--G. K. Chesterton
From:
open-web...@googlegroups.com [mailto:open-web...@googlegroups.com] On
Behalf Of Chris Messina
Sent: Thursday, July 31, 2008 6:26 PM
To: open-web...@googlegroups.com
Subject: Re: Speaking of patent licenses
On Thu, Jul 31, 2008 at 6:00 PM, Joe Andrieu <j...@andrieu.net> wrote:
Gabe Wachob
Joe's well-stated point is that, practically speaking, this group has
no (as of yet) *stated* reason to ask for a contributor to contribute
IPR beyond that which is required (or maybe useful) to support open
specifications (ie to support an "open web"). The way that this
distinction (give us all your IPR vs. give us what we need) is
generally done through a "necessary claims" language, or at least a
non-assertion around the bounds of implementation of a specification.
If you demand everyone *unconditionally* give away *all* their IPR
(esp patent rights) when contributing, many organizations won't
participate, and this org has probably failed at enlargening the open
playing field for developers.
-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 DiBona
We saw this exact same kind of thing in the open source world....back then people called us a cancer, communists, etc.... I'm not saying you're this bad, or your arguments as comedic, but I think that anyone can see we are not trying to backdoor non-spec related ip. The devil is in the details, of course, but we are not taking an anti-ip stance here.
Chris
Open Source Programs Manager, Google Inc.
Google's Open Source program can be found at http://code.google.com
Personal Weblog: http://dibona.com
Gabe Wachob
DeWitt Clinton
In other words, its not about generating value or revenue off of the web (or whatever the specification is describing), its for retaining the right to get licensing or other advantage for uses *outside* the web or subject of the specification.
This actually speaks to the crux of my argument.
Say someone contributes, say, a method for encoding tokens inside authorization headers in a delegated authorization protocol. This original intent of this specification was for http-based exchanges.
But then, a few years from now, we discover that we need to exchange those tokens via mobile devices using non-http protocols.
Wouldn't it be a shame if the contributor of said method for encoding tokens decided to extort a licensing fee on implementors because, whoops, they only intended to contribute it for "web" purposes.
In my eyes that is a restriction of use, pure and simple, and a gross violation of the open spirit. I think we're here to guard against that.
-DeWitt
DeWitt Clinton
In other words, its not about generating value or revenue off of the web (or whatever the specification is describing), its for retaining the right to get licensing or other advantage for uses *outside* the web or subject of the specification.
Eran Hammer-Lahav
EHL
Chris DiBona
If you demand everyone *unconditionally* give away *all* their IPR
(esp patent rights) when contributing, many organizations won't
participate, and this org has probably failed at enlargening the open
playing field for developers.
For instance, if you want to restrict non 'web' use of a spec, then that implies a java tck style restriction on appliances and embedded. I won't go down that road again out of respect for Simon, but that's the kind of talk that might sound reasonable for an 'open' standard, but actually is quite restricting.
chris
Simon Phipps
On Aug 1, 2008, at 07:13, Chris DiBona wrote:
> For instance, if you want to restrict non 'web' use of a spec, then
> that implies a java tck style restriction on appliances and
> embedded. I won't go down that road again out of respect for Simon,
> but that's the kind of talk that might sound reasonable for an
> 'open' standard, but actually is quite restricting.
Please don't imply I am here in a corporate capacity. Just because I
work for Sun doesn't mean I agree with everything they have ever
done :-)
I'd oppose any attempt to have OWF apply any restrictions to how its
specs can be used. Field-of-use restrictions have no place in open
source.
S.
Ben Laurie
Well said.
>
> S.
>
>
> >
>
David Dillard
something that's in the spec (and I've contributed to the spec) now
I'm forced to give that away.
Simon Phipps
uniform dish though, and it avoids a reply-flood.
On Aug 1, 2008, at 02:59, Gabe Wachob wrote:
> If you demand everyone *unconditionally* give away *all* their IPR
> (esp patent rights) when contributing, many organizations won't
> participate, and this org has probably failed at enlargening the open
> playing field for developers.
Who is demanding that, apart from through careless rhetoric? If you
are trying to characterise a non-assert with no "necessary claims"
language in that way, I disagree at a profound level.
On Aug 1, 2008, at 02:58, Joe Andrieu wrote:
> If so, if I've pledged to not assert the "property rights" that I
> have over a given idea or implementation, why would someone license
> said patented technology from me?
I'm unclear why we would want OWF to support any business model that
depends on patent licensing? While I'd not want any unnecessary
barriers to corporate participation erected, I see no reason why I
would want to allow field-of-use or necessary claims restrictions to
be included in the IPR terms just because some potential contributor
might find it inconvenient to their business model.
On Aug 1, 2008, at 02:44, Eran Hammer-Lahav wrote:
> What we want is to know that we can implement “this spec in full or
> in part” without being sued by “these contributors”. As was also
> pointed out, “this spec” gets to be a tricky term because someone
> can take OAuth, “enhance it” to the point it looks like a different
> protocol and claim protection because his code is OAuth+.
My colleagues have been experimenting with use of the phrase
"substantially derived" to indicate the point on the certainty graph
where a developer can know they need to get legal advice.
> This is where we start to have problems. Most IPR leave this up to
> the jury to decide. They define “compliant portions” in all sorts of
> ways that make people happy/sad. I don’t think we are going to get a
> “patents in the public domain” solution.
Ultimately the only solution for the edge cases is to leave it to the
courts. Our gal should be to ensure that the vast majority of the use
cases do not suffer from that uncertainty. The enemy of open source
developers is not patent litigation itself, it is the /fear/ of patent
litigation. Uncertainty chills. To enable open source implementation
of OWF specs, we have to make sure that there is minimal uncertainty
in our core use-cases.
On Aug 1, 2008, at 02:00, Joe Andrieu wrote:
>
> If you want a paradigm that reaches broadly, instead of getting
> stuck in GPL-style battles over IP v FREE software, I think you'll
> find necessary claims and reciprocity—in some form—required.
> Otherwise, you're just asking for donations to the public domain,
> which isn't much of an improvement on GPL and, IMNSHO, would remain
> as limiting.
Reciprocity: Yes, because that creates a safer environment which gets
better the more patent-holders participate. The more you have to lose
by initiating patent litigation, the less likely you are to start it.
Necessary claims: No, because this language reduces certainty for
individual developers that their work is covered by the non-assert and
introduces a loophole through which a corporation can restrain
competition in the future should the work of that developer turn out
to be effective.
S.
Simon Phipps
Let's read that license again now:3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
We need to work to make the spirit of this license apply to works other than source code. It's the "necessarily infringed" and "Work" language that we need to focus our attention on here. (And I only use the Apache license as an example of the spirit that we're getting at, if there are better ways of getting there then that's on the table, too, of course.)
Eran Hammer-Lahav
It is nice to see people here with strong ideals, however, there is no veto power at the OWF and all decisions are likely to be made with a simple majority. So please stop with the ‘I will opposed all changes’ rhetoric. No one here gets to dictate anything, myself included. It is generally silly to talk in absolutes when it comes to an IPR process. Why? Because the reason why most IPR policies suck is that there are no absolutes. It is always a compromise between rights and participation.
Let’s also not forget that we are not living in a bubble. The OWF is likely to reference other standards and specifications in its work. Those are covered under different IPR policy. Part of our work will be to define which are acceptable external dependencies and which are not. Is it ok to reference HTTPS since it uses SSL which might require some licensing? (don’t pick on my examples, just trying to demonstrate my point).
If the end result of an OWF IPR policy is a de-facto assignment of patent rights, even if it doesn’t say so directly, we will fail at building a community, and without a community, it is not “open web”. We also come form a known place of specifications with existing communities and while we don’t need to accommodate individual companies, we should do our best to be able to include as many participants from the existing communities so they can actually move over to the OWF. If we go too far with the license, we will lose people we are in desperate need for.
You can talk about *fear* all you want but you have to be an idiot to think that an absolute license protects you from being sued. It will protect you from the contributors, but the more strict the license is, the less likely anyone with IP will participate, hence increasing the legal risk, not improving it. No matter what we do, third parties are not covered. And we really want third parties to sign the agreement. We require signatures from all contributors, but will ask for signatures from all other major companies and will keep track of who is a “friend” of the OWF and who is not. This is where the community is more effective than contracts. Go nuts with this license and no one will ever sign anything out of goodwill – why? Because you are showing none.
As long as we write the IPR policy in plain English (and translated to other languages), and clearly explain to developers what protections they get and what they don’t, we made progress. It doesn’t mean we shouldn’t try to get more protections, but we should always keep the balance of protections and participation. There are no absolutes in a compromise.
EHL
Simon Phipps
It is nice to see people here with strong ideals, however, there is no veto power at the OWF and all decisions are likely to be made with a simple majority. So please stop with the ‘I will opposed all changes’ rhetoric. No one here gets to dictate anything, myself included. It is generally silly to talk in absolutes when it comes to an IPR process. Why? Because the reason why most IPR policies suck is that there are no absolutes. It is always a compromise between rights and participation.
Sam Ruby
>
> It is nice to see people here with strong ideals, however, there is no veto
> power at the OWF and all decisions are likely to be made with a simple
> majority.
If this is the case, this is a clear difference between the OWF and the ASF.
Within the ASF, there is a VP, Legal Affairs and a Legal Affairs
Committee that concerns itself with matters such as these. While it
has never come to that, I have no doubt that I could stop a product
release if that release were to violate ASF IPR policies.
- Sam Ruby
Brad Neuberg
I think your position is alienating to IP owners and doesn't support the idea of a community working together. Granting a non-assert in support of a specification shouldn't mean that developers get to use that IP for other applications. The applications have to implement the spec.
Jonathan Vanasco
"""We may or may not hold several patents that cover this technology.
If we do hold a patent covering this technology, we grant everyone a
license to that infringe on that patent in the implementation of the
specification. That license does not apply to other uses, only
implementing the specification. The only way this license can be
revoked , is if you file suit against us - or countersuit /
counterclaims - regarding this patent. Should you file suit, we
revoke the license upon filing and further infringement may be subject
to patent litigation."""
I think IPR non-asset and licensing policies like that are essential.
Jumping into the semantics -- i think necessarily may be important,
though it should be clarified as to what necessarily does reference.
- the specification calls for an approach that would infringe
- the implementation offered would infringe
From the corporate side, I see their argument as this:
"""We have this technology. We want it to be open for webuse in the
context of these open protocols. But we don't want it used for
financial services or airline ticketing, which is where we generate
our revenue"""
I also see their argument as : """ We released this protocol/API that
infringes on our patents by design. people will necessarily infringe
on these claims if they implement."""
In most cases, you're going to be dealing with a 20person legal
department or an external firm that just thinks in terms of maximum
liability protection. Satisfying devs and product/division managers
is one task... satisfying overzealous lawyers who hate their job and
spend all day on semantics is another.
Developer/Implementor : Does this make me feel safe.
Company ( division / product manager ): Does this fit in with our
goals and what we're willing/wanting to open up ?
Company ( lawyer ): What risks does this expose us to? How does this
affect our other product lines ? How does this affect our other
applications of technology that we monetize ? What do we open
ourselves up into ?
> On Aug 1, 2008, at 02:58, Joe Andrieu wrote:
> > If so, if I've pledged to not assert the "property rights" that I
> > have over a given idea or implementation, why would someone license
> > said patented technology from me?
rights for certain uses and contexts of the work. In other situations
it means that you're pretty much placing it in the public domain, and
using the patent to ensure that others can't charge/license for it.
On Aug 1, 10:53 am, Simon Phipps <webm...@gmail.com> wrote:
> I'm unclear why we would want OWF to support any business model that
> depends on patent licensing? While I'd not want any unnecessary
> barriers to corporate participation erected, I see no reason why I
> would want to allow field-of-use or necessary claims restrictions to
> be included in the IPR terms just because some potential contributor
> might find it inconvenient to their business model.
create a corporate détente, where the threat of patent litigation over
technologies is used by competing firms to offset other litigations or
product development.
You also run into the situation where there is a similar dual-usage
scenario -- where an open web format / standard / system / etc can be
used by consumers to improve online communication, or by a corporation
to improve advertising sales. Some corporations would gladly like to
contribute their technology to make online communication and
experience better for people -- but not at the risk of open sourcing
their revenue stream.
Personally, I've been on both sides of the issue. Three years ago
FindMeOn spent a large investment on R&D in creating open web formats
and proprietary backend systems to run them and analyze data. The
market wasn't ready yet, but we ended up being right on just about
every concept and diligently filed about 200+ pages of patent
applications. A few years later someone larger comes in, dwarfs our
entire budget with their first-month marketing spend alone, and
releases a series of competing proprietary and open source products
under similar names that significantly overlap with some of our patent
filings. Do we plan on litigating? Yes. Do we want to continue
working on Open Source projects, foundations and specifications?
Definitely. Both my firm and that other firm want to work with OWF
and have been active in these threads -- should the issues of our two
companies on certain matters affect involvement and contribution to
Open Source development? Absolutely not.
IPR is both complex and a reality that needs to be addressed. Stuff
like scoped non-assets don't just corporations who want to help out
'help out' -- but can let open standards take advantage of otherwise
proprietary technologies or even benefit for the knowledge that 'you
wont get sued'. I remember a few years ago there was a concern over
the OpenID specification violating a patent, which led to some fears
over adoption. Had the protocol been covered by a patent, and the
owner issued a non-assert for the OpenID spec, those concerns would
have instantly vanished and adoption proceeded faster.
I brought up an IPR scoped question in another thread, which David
Recordon answered would be per-project. It seems smart to just bring
up my questioning here, since people are chatting about this more in-
depth....
Scope is important because should one company sue another over a
specific OWF format, that lawsuit shouldn't set off a chain reaction
of license nullifications.
ie:
Company 1 sues Company 2 over Format A
Because of no scope , that invalidates the non-asset in Format B
Company 2 then sues Company 1 over patented technology used in Formats
B,C,D,E,F,G
Company 3,4,5 get worried about implementing A,B as there are current
lawsuits over it.
Company 1 stops supporting Formats B,C,D,E,F,G until the mess is
resolved.
Users, across the world, are inconvenienced.
Brad Neuberg
Let's say someone creates a group at the OWF to tackle video on the web (let's ignore the HTML 5 video tag for this example). This group creates a spec, some company donates a codec and all the patents, goes through the standard OWF IPR stuff, etc. Then, a group of us over at the Apache Foundation start creating some code that is a library that implements this codec and the standard over in the incubator. Life is good.
Now, this video codec library at the Apache Foundation is good-ole open source. So someone else comes along, sees that theres a great open source video codec (with no patent claims!) and decides to grab a portion of the library to pull into their own project that has nothing to do with the original standard -- lets say its an application that lets you do fun things with videos, remixing them with effects. This developer is working and puts their app out, then suddenly they are hit with a patent law-suit from the original company that donated the codec because its not within the spec.
Do we want to protect against this scenario? Personally, I think one of the greatest strengths of open source and the open web is being able to remix things in new, unintended ways to maximize innovation. I think we should support this scenario.
Chris Messina
Ironically sent from an iPhone Classic.
Eran Hammer-Lahav
I’m not threatened by anyone unless they pose physical threat... :-)
I’m actually against field-of-use restrictions of specs, but think that in-scope restrictions of patents rights as measured by spec implementation are unavoidable. I can’t see how this work will be successful if signing the IPR policy means putting covered patents in the public domain for anything you might want to do with them. The OWF is not the anti-patent foundation...
EHL
Eran Hammer-Lahav
EHL
Eran Hammer-Lahav
Project A implements spec X which has been non-asserted or might not every have any assertable IP.
Project B implements spec Y which has been non-asserted or might not every have any assertable IP.
Project C takes parts of A and part of B. There is no guarantee project C is IPR free! None! The combination, if non-trivial, can by itself be patented. So anytime to write code, whether it implements open specs or not, you might be infringing upon someone’s IP.
This is not an example we can solve.
EHL
> factoryjoe.com <http://factoryjoe.com> # diso-project.org <http://diso-project.org>
> citizenagency.com <http://citizenagency.com> # vidoop.com <http://vidoop.com>
Joe Andrieu
Respectfully, Chris, open != unencumbered. And while I'm just one voice among many, I didn't understand this would be the Unencumbered Web Foundation. You may as well call it the Chaotic Web Foundation or the Freedom to do whatever we want Foundation.
I'm realizing that perhaps what you, and others, mean by "open" is that developers are free to code without fear of litigation. I'd suggest that's limiting.
I was attracted to OWF because I took "open" to mean that we would find ways to easily enable open interoperable systems, where technology built for one system works seamlessly with another system. Just like my email client works with your email reader. Or my web browser works with your web content. I understood that the idea was to enable the kind of open, non-proprietary web promoted by the Web Standards Project. So that anyone anywhere could build to the specification and be magically, seamlessly interoperable with all the other systems which implement the specification, without needing permission from the creators or paying anyone a license.
But what I'm reading—I could be wrong—is that you don't actually care if there is interoperability. What you care about is being able to code whatever the heck you want. Mod it. Fork it. Make it as incompatible as if it weren't even the same specification. But feel free to call it the same thing, because of course, I've given up my rights regarding trademark and copyright. Feel free from litigation from any IP of the original contributors.
Having folks put IP into a shared pot so we can collectively figure out how to make interoperability work is a good idea. I have no problem with royalty-free license to the technology required to implement a specification I contribute to. And I'm ok with some variation of that which would allow forward forking that retains backwards compatibility (which seems easy enough to do if the future spec incorporates the first spec by reference). But I have no interest in contributing IP to something that doesn't even have a minimal commitment to interoperability with the specification coming out of the process.
It appears that you are arguing to allow developers to be free-riders. You seem to want folks to give up their innovations for the common good, but you aren't willing to hold developers to work towards the common good themselves. That doesn't make sense to anyone but developers. If we all contribute to a shared specification, we get to share it as defined in the spec. It isn't carte-blanche for chaotic reinterpretation. I can't see anything good coming out of Brad's suggested potential forking of OpenID if that fork is incompatible and breaks the system.
Why give up my inventions just so anyone can fight me in a standards battle with a competing, incompatible standard? If you want my IP, sit down at the table and work through the open process with me. And when that process is complete, we'll have a specification that we can both use without fear of complications. The quid-pro-quo is giving up the IP to help create a standard. Not giving up IP so developers can go crazy with it. If I wanted to do the latter, I would just publish it and release it to public domain.
We might be arguing from ideological differences can't be resolved. The question then, isn't whether or not we can convince each other to change our ideologies. The question is whether or not we can create an agreement that meets enough of our needs for us to collaborate for the common good.
So, I, again, would like to see a proactive assertion on your part as to exactly which restrictions on IP make sense. I think my earlier "over-the-top" non-assert was misunderstood as suggesting what the OWF is about. It wasn't that at all. It was an attempt to move the needle so far to the other side of the debate as to understand what you and others think is reasonable—instead of debating what we each think is unreasonable.
It seems that reciprocity is generally agreed to be useful. "Don't sue me for stuff related to this specification and I won't sue you for stuff related to this specification." So that's at least one encumbrance we can agree on.
Ok, now what exactly is covered by "related to this specification" on the implementation and on the non-assert side?
Does IPR cover any and all implementations of anything in any form, any media, compatible or incompatible, interoperable or not, in any application, related or unrelated the "covered" specification?
If I have a compression algorithm that I contribute to the next generation file format, are you free to use that compression algorithm in a non-compatible competing standard? Are you free to tweak that algorithm and use it in a visualization system? Can you tweak it and release an incompatible version with the same name as my own product?
Does the IPR cover any and all IP owned by the non-asserter, whether it is related to the specification or not?
If I non-assert, can you use my logo on your product? That's IP. If I non-assert that compression algorithm, do you also effectively get a non-assert on all of my patents and trade secrets? Do you get the right to use my OCR patent? That's my IP.
I would suggest that clearly there is a need to bind the scope of IP contributed under an IPR agreement. That's the point of the "necessary claims" language. In fact, I'm with Gabe in that I don't understand why this isn't obvious. And I don't understand why it makes you livid, Chris. Whether "necessary claims" is the best way to do it, I don't know. But we need something. Specific licensing of particular patents or listed IP is almost certainly worse, because there could be something missing that creates a loophole for litigation. So, in some senses it needs to be broad enough to cover any appropriate IP, but focused enough so it doesn't encompass all IP of the non-asserter.
I also think the scope of use needs to be bound to implementations of the specification. Not to field of use, but to actual, good faith attempts to implement the specification. Let the courts argue what that means in practice, but at most that would suggest settlements that force interoperability instead of outrageous fees if/when it does go to court. And we can all rest assured that no matter how well we do here, sooner or later our language will end up in court.
So, Chris, are you really saying that if I non-assert in one spec, I've non-asserted for all of my IP?
Clearly there's some additional boundary you'd find reasonable.
-j
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
"An inconvenience is an adventure wrongly considered. An adventure is only
an inconvenience rightly considered."
--G. K. Chesterton
From: open-web...@googlegroups.com
[mailto:open-web...@googlegroups.com] On Behalf Of Chris Messina
Sent: Friday, August 01, 2008 12:41 PM
To: open-web...@googlegroups.com
Subject: Re: Speaking of patent licenses
The behavior of forking, modding and rereleasing should be at the core of our work and expected of all projects incubated under the OWF.
Eran Hammer-Lahav
The OWF is not an effort to void the patent system or even fix it.
EHL
Gabe Wachob
to the irc channel (irc://irc.freenode.net/#owf), and while I don't
think anything has been resolved, I personally have a much clearer
idea of what some of the concerns folks have. Its really amazing what
a few minutes of live civil back and forth can produce.
I've already had an illuminating discussion with webmink and dewitt,
along with Josh Patterson about the necessary claims language. I don't
think anyone has changed their minds, but at least I believe we
understand what our positions are, and seem to roughly agree on the
ultimate end game.
Its an ongoing conversation, please do not feel like you even have to
say anything. (We'd really like to get a logbot setup if anyone would
like to help out).
Despite some of the statements made recently on this list, I think the
common ground/interests we share is far greater than the differences
and thats usually a sign that we can achieve something meaningful.
Lets at least be civil while we suss out whether or not we have enough
common ground to move forward in whole or in part.
Thanks.
-Gabe
Chris DiBona
Respectfully, Chris, open != unencumbered. And while I'm just one voice among many, I didn't understand this would be the Unencumbered Web Foundation. You may as well call it the Chaotic Web Foundation or the Freedom to do whatever we want Foundation.
This is exactly the kind of alarmist responses to openness that I was talking about earlier. This, and calling developers 'free riders' (and me, weirdly, 'livid') are exactly what I was talking about in my other email. I see this kind of extremism as laying the groundwork for specifications that lie in wait to sabotage later adopters of 'standards'. So I'm going to go to the end question of your very long email and assume that was not your intention.
I consider the freedom to fork (while not assuming the full and qualified name of the spec) is absolutely fundamental to a truly open internet. The ability to fork keeps a project honest, productive and influential or the healthier fork continues. I hope that the OWF goes in this direction. You can do this and protect trademark quite easily, see the apache license for more info there.
I also feel it is incumbent on me to point out what happened when the web adopted the GIF protocol with its patent encumbered compression algorithm. Since there was no patent non-assert attached to that, Unisys sued a number of firms to recover 'damages' on LZW, including one run by friends of mine. I'm happy to provide more examples, but I don't know that I need to.
I'm happy to go to IRC, when a logbot is setup. In the mean time, this kind of debate should happen on archived lists if it is to matter at all.
Chris
Joe Andrieu
FWIW, Chris, it was the other Chris (Messina) who said he was livid.
I checked out the IRC, but you make a good point about archiving stuff.
The GIF example is one of a missing non-assert, not one of a bad necessary claims, so I'm not sure what it teaches.
I didn't mean to be alarmist about Free-Riders. What's the quid-pro-quo for IP owners if not having a spec that means something?
And please do explain what you mean by the sabotage scenario. I don't understand how that would work, but if it’s a problem, I'm open to finding a solution.
-j
--
Joe Andrieu
j...@andrieu.net
+1 (805) 705-8651
"An inconvenience is an adventure wrongly considered. An adventure is only
an inconvenience rightly considered."
--G. K. Chesterton
Eran Hammer-Lahav
I think if we created something that from day one prevented individuals working for AOL, MySpace, Yahoo, Microsoft, IBM, etc. from being able to participate, we've failed. And the thing is, we don't have to go to their employers directly to negotiate this agreement because we have enough experience in this room to have a good idea of what is done today, and how we can make an incremental improvement over that. Going all the way is probably not a practical approach, no matter how “just” you think it is.
One issue is that people think getting to 100% risk-free spec is possible. In reality, it is far far from it. Contributor non-asserts get you from 100% risk to 80% (my finger in the wind measurements). Making the non-assert really wide gets you to 75%. Are you willing to lose 80% of your community for 5% more protection? And from far less IP holders?
Contributor non-assert (or license) are design to prevent one risk - that someone with IP will gain control over a specification and assert its IP. It should not and *cannot* provide you any more protections. It will not protect you from people with IP who choose not to participate (probably because they have IP and don’t want to lose it).
Also, are we suggesting arbitration for resolving all matters related to the agreement? Because without, it will also not protect you from being sued by anyone(!). It might help you win in court but it someone disagrees with you, they will sue. Cost of this lawsuit (that you are likely to win because they non-assert)? US average (I’m told) is $3.5MM for a patent court litigation.
This is an extremely valuable discussion and it is ok for people to make bold statement at this stage. So throw in your test cases! Don’t say “need to be able to fork”, give a real example using real specifications.
EHL
DeWitt Clinton
Introduction
Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.
Eran Hammer-Lahav
From the Apache license:
---
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
Work is defined as:
---
"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work.
---
And so, it means you can take Source Code or Binaries, and make (I assume this means compile), use, offer to sell, sell, import, and otherwise transfer (move) it. It provides none of the sort of sweeping rights people have mentioned it, such as unlimited access to the IP covered by the Work in a different context.
In other words, if you write completely new code that does exactly what an ASF code does, you do not enjoy from patent protection from the authors of the OSS (you might be able to argue in court that their previous license void their current claims of damages and show part licensing patterns). If you take OSS and change it, the unchanged parts are still covered but the new code is open for interpretation.
What makes this easier when dealing with source code (unlike specifications) is that you are using a product as opposed to an idea.
Taking OAuth as a real example, it defines a protocol for HTTP based authorization delegation. However, it defines in details a method for signing a list of key/value pairs. If you write code that implements that method, I would argue that you can use that code anywhere and enjoy the protection of the current very limited contributor non-assert. However, if you take that method and change it to sign something else, say streaming video, you can’t argue the OAuth license applies.
More narrowly, if an OAuth contributor has a patent on an extremely efficient signature method (say, 10 times faster than HMAC-SHA1 and as strong) and is willing to contribute it for any implementations of the spec. That will cover using code that takes key/value pairs and pass them through this method, but not for signing video streams where this patent is used to generate them revenues. Ignoring the legal language – should we accommodate such a contribution?
EHL
Brad Neuberg
Brad Neuberg
Eran Hammer-Lahav
The issue I have with your example is that it makes a pretty unfounded assumption that open source code is IPR free. This is not true. It comes with some rights and those are only from contributors. Sometimes, not even the entire software, just the contribution itself (and its interaction with others) - as is the case with the ASF license.
Here is another test case. X and Y are not OAuth contributors. A writes an OAuth library and release it under the ASF license. By doing so A de-facto non-asserted the OAuth spec as implemented by his code. B comes in and contribute a patch that makes the library faster. B has patents that cover core areas of OAuth but none that make it faster. B can still sue anyone using the library for claims implemented by A. Of course B should not use OAuth or the library as he is no longer benefiting from any of their licenses. However, B just made the library much better and paying clients of B will benefit from it.
This is where we currently stand with OSS license as defined by the Apache license.
---
I think we have agreement on these points for the OWF:
- Non-asserts cover the entire spec, not just the contribution made.
- Any feature of the spec is covered, not just the required parts (the MUSTS).
- If derived work is using the entire spec with additions, the overlapping parts are covered.
The point I am having a problem with is the idea that if I contribute to a spec, and have IP that covers the spec, you want that IP to basically be make public domain. If you combine it with the idea of non-asserting the entire spec, you create an easy way to force people out by proposing something that they might have IP on (as long as you don’t know for sure, you are not breaking the rules and educated guess will work just fine). If you remove the requirement to non-assert the entire spec, but limit it to the contribution, you are trading one protection for another.
What would make you feel better, company A which has lots of IP non-asserting just their contribution and nothing else, leaving the door open to asserting other contributions, or non-asserting everything, but only for implementations of the spec, not other unrelated efforts? I would argue that very few companies will waive all IPR on everything covered by a spec.
EHL
--
Joe Andrieu
j...@andrieu.net <http://j...@andrieu.net>
+1 (805) 705-8651
"An inconvenience is an adventure wrongly considered. An adventure is only an inconvenience rightly considered."
--G. K. Chesterton
From: open-web...@googlegroups.com <http://open-web...@googlegroups.com> [mailto:open-web...@googlegroups.com] On Behalf Of Chris Messina
Sent: Friday, August 01, 2008 12:41 PM
Subject: Re: Speaking of patent licenses
The behavior of forking, modding and rereleasing should be at the core of our work and expected of all projects incubated under the OWF.
It makes me livid to think that we'd support anything less than that. I understand what Joe is saying and the point they Gabe is raising and if I understand the implications of the "necessary claims" language, it seems like boundaries placed upon the reuse and redistribution of OWF-sponsored works must not be abided.
This is the *Open* Web Foundation, not the Walled Garden Foundation.
The logical result of our work should be a Darwinian environment where thousands of permutations may derive from a single intellectual gene, without dependence or allegiance to the original.
To reiterate, if I understand Joe's point and Gabe's contributions, I reject their premise on a matter of principle and morality. The operative goal here should be unencumbered (except to the degree to which we can guarantee repropagation and enduring freedom) technology, specifications and ideas.
Chris
Ironically sent from an iPhone Classic.
On Aug 1, 2008, at 11:11, "Brad Neuberg" <bradn...@gmail.com <http://bradn...@gmail.com> > wrote:
Ben Laurie
>
> On Fri, Aug 1, 2008 at 12:01 PM, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
>>
>> It is nice to see people here with strong ideals, however, there is no veto
>> power at the OWF and all decisions are likely to be made with a simple
>> majority.
>
> If this is the case, this is a clear difference between the OWF and the ASF.
Not sure Eran is correct on this matter :-)
Eran Hammer-Lahav
Prove me wrong... :-)
EHL
-----Original Message-----
From: open-web...@googlegroups.com [mailto:open-web...@googlegroups.com] On Behalf Of Ben Laurie
Sent: Friday, August 01, 2008 9:23 PM
To: open-web...@googlegroups.com
Subject: Re: Speaking of patent licenses
David Orchard
Or, if somebody does ONLY the parts of Project C that use A and B.
Anytime you implement code that implements specs that are RF then you may be "infringing" on someone elses IP but they won't be able to claim any kind of damages.
Cheers,
Dave
Dennis E. Hamilton
this, because derivative works with respect to copyright is not a notion
that applies to patents. Furthermore, the derivative work might run athwart
of a completely different patent and not even be subject to the patent (or
the covenant) involving claims against implementations of the original
specification.
It might work for the creator of the derivative work to arrive at a new or
modified specification and pray that those who offered the original
covenants would include implementations of the new specification in their
covenants. But those covenanters might not be the folks you have to worry
about.
This is a risk of any software development (open-source or not) at any time,
whether implementing a known specification or not. I don't see how the Open
Web Foundation (or any other organization) has any way to alter that short
of turning into a public-policy advocacy organization with no immediate
benefit to specification and software developers.
- Dennis
Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability
mailto:Dennis....@acm.org | gsm:+1-206.779.9430
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org
-----Original Message-----
From: Brad Neuberg
http://groups.google.com/group/open-web-discuss/msg/46ade26e16dad870?hl=en
Sent: Friday, August 01, 2008 16:38
To: open-web...@googlegroups.com
Subject: Re: Speaking of patent licenses
On a practical level, if we don't allow Derived Works, I'm worried about a
new class of open source code that is very hard to work with. In the example
Eran gives below of a new very fast signature method, I would have to track
in the code that it could only be used with such and such a particular
method. If someone lifted that (or learned from the source and
re-implemented it themselves in a different language), then you would have
to have some pretty intense bookkeeping. It would also instantly make the
code GPL-incompatible, and while I tend to be an Apache-style license person
I think its important for Apache-style licenses to be GPL-compatible to
promote more code re-use.
[ ... ]
Eran Hammer-Lahav
Project are not done in the OWF, only specs. And no matter where something is done, you are only protected from the contributor, not the world.
EHL
From: open-web...@googlegroups.com
[mailto:open-web...@googlegroups.com] On Behalf Of David Orchard
Sent: Friday, August 01, 2008 10:07 PM
To: open-web...@googlegroups.com
Subject: Re: Speaking of patent licenses
If C is done in OWF and OWF is
always (whatever term you want but let's call it RF for now) then people are
good.
Daniel Weitzner
On Aug 2, 2008, at 11:26 AM, Eran Hammer-Lahav wrote:
> Project are not done in the OWF, only specs. And no matter where
> something is done, you are only protected from the contributor,
In your plan, are implementers protected against other participants in
the group if they happen to have been the named contributor?
Danny
> > factoryjoe.com <http://factoryjoe.com> #diso-project.org <http://diso-project.org
Eran Hammer-Lahav
EHL
Daniel Weitzner
On Aug 4, 2008, at 10:45 AM, Eran Hammer-Lahav wrote:
> Implementers are protected from the OWF spec contributors. Any
> additional protection is based on the contribution license used for
> the actual code.
So that means that if someone else makes a contribution that covers my
patents, or a group ends up defining a feature by group process that
is covered by my patents, then implementers are unprotected by OWF?
Danny
Eran Hammer-Lahav
Spec contributors only promise not to sue people who implement the spec, limited by the scope of the spec. For example, you can implement OAuth freely without an OAuth contributor suing you for the parts detailed in the OAuth spec. However, if your OAuth implementation does other things such as use a special database that I have a patent on, I (as an OAuth contributor) can still sue you for that because it is not part of OAuth. However, if that special database is the only way to get OAuth to work, you can use it freely. This is the part many licenses get really complicated. If something can make your code better, it doesn’t make it a requirement (to implement, not talking about spec MUST/SHOULD) and so should not be covered. However, the license should not require you to pay some “reasonable” royalties instead.
EHL
Daniel Weitzner
On Aug 4, 2008, at 11:48 AM, Eran Hammer-Lahav wrote:
> I am not clear what you are asking. Someone else makes a
> contribution to what? The spec or implementation?
I'm asking whether you believe it is sufficient patent protection to
implementers to have the scope of the license (or non-assert) required
by OWF to be only to what you, yourself, contribute?
Contribution-based patent policies are ok when a spec is put together
out of well-defined, large-scale contributions and little group
development. This is the case is more traditional standards bodies
that work by exchange of large documents and votes on formal proposes
to include or exclude certain 'contributions.; However, if a spec is
designed to any extend by the joint efforts of a group of individual
participants, it may often be hard to tell who contributed what. That
leaves the patent picture for implementers potentially murky.
Thoughts?
Danny
Eran Hammer-Lahav
EHL
Jonathan Vanasco
On Aug 4, 11:48 am, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> Spec contributors only promise not to sue people who implement the spec, limited by the scope of the spec. For example, you can implement OAuth freely without an OAuth contributor suing you for the parts detailed in the OAuth spec. However, if your OAuth implementation does other things such as use a special database that I have a patent on, I (as an OAuth contributor) can still sue you for that because it is not part of OAuth. However, if that special database is the only way to get OAuth to work, you can use it freely. This is the part many licenses get really complicated. If something can make your code better, it doesn't make it a requirement (to implement, not talking about spec MUST/SHOULD) and so should not be covered. However, the license should not require you to pay some "reasonable" royalties instead.
In a *perfect* world , people would put their IP in communal pot and
we would all advance as a society. Healthcare, housing, and food
would all be insured too. And there wouldn't be guns or Ms. Pac Man
machines that have faulty quarter slots.
But the world isn't perfect.
I think natural-selection will push fully-open technologies to the top
whenever possible, and whenever best. Often times this is the case,
sometimes its not -- and you'll have a better product by utilizing
some proprietary technology. Having the 'confines of the spec' IPR
truce is a great second-place compromise that deals with reality.
Pushing for licensing and IPR schemes that apply to 'out of
specification' usage reminds me a lot of the debate around GPL --
which turned into less about getting software made than shifting
cultural norms. I can also see a large divide happening because of
that as well -- corporations large and small running away from OWF and
setting up different , similar organizations where the mantra is "get
shit done" and offering certain technologies/contexts up for grab --
and steering clear of the rest.