How can we submit code patches that implement our (pending) patents?

On 4 July 2018 at 08:27, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com

wrote:

Hello,

As I asked at the PGCon developer meeting this year, we'd like to offer
our company's patents and patent applications license to the
PostgreSQL community free of charge. If I heard correctly at that time, we
could continue this discussion during the unconference, but I missed that
opportunity (I'm sorry). So, please let me continue the consultation
here. If some other mailing list is appropriate such as pgsql-core, let me
know (but I hope open discussion will lead to better and fair ideas and
conclusion.)

There are three ideas. Is there any effective idea?

My big hesitation with all those approaches is that they seem to exclude
derivative and transformative works.

PostgreSQL is BSD-licensed. Knowingly implementing patented work with a
patent grant scoped to PostgreSQL would effectively change that license,
require that derivatives identify and remove the patented parts, or require
that derivatives license them.

I'm assuming you don't want to offer a grant that lets anyone use them for
anything. But if you have a really broad grant to PostgreSQL, all someone
would have to do to inherit the grant is re-use some part of PostgreSQL.

I guess there's a middle ground somewhere that protects substantial
derivatives and extracts but stops you using some Pg code snippets as a
freebie license.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

From: Craig Ringer [mailto:craig@2ndquadrant.com]

I'm assuming you don't want to offer a grant that lets anyone use them for
anything. But if you have a really broad grant to PostgreSQL, all someone
would have to do to inherit the grant is re-use some part of PostgreSQL.

Your assumption is right. No scope is the same as no patent; it won't help to defend PostgreSQL community against rival companies/communities of other DBMSs. Or, I think we can set the scope to what OIN states. Fortunately, anyone can join OIN free of charge.

I guess there's a middle ground somewhere that protects substantial
derivatives and extracts but stops you using some Pg code snippets as a
freebie license.

Are you assuming that developers want to use PG code snippets for non-PostgreSQL or even non-DBMS software? I believe that accepting patented code from companies would be practically more useful for PostgreSQL enhancement and growth. PostgreSQL is now a mature software, and it can be more corporate-friendly like other software under Apache License.

Regards
Takayuki Tsunakawa

On 4 July 2018 at 21:15, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com

wrote:

From: Craig Ringer [mailto:craig@2ndquadrant.com]

I'm assuming you don't want to offer a grant that lets anyone use them

for

anything. But if you have a really broad grant to PostgreSQL, all someone
would have to do to inherit the grant is re-use some part of PostgreSQL.

Your assumption is right. No scope is the same as no patent; it won't
help to defend PostgreSQL community against rival companies/communities of
other DBMSs. Or, I think we can set the scope to what OIN states.
Fortunately, anyone can join OIN free of charge.

I guess there's a middle ground somewhere that protects substantial
derivatives and extracts but stops you using some Pg code snippets as a
freebie license.

Are you assuming that developers want to use PG code snippets for
non-PostgreSQL or even non-DBMS software? I believe that accepting
patented code from companies would be practically more useful for
PostgreSQL enhancement and growth. PostgreSQL is now a mature software,
and it can be more corporate-friendly like other software under Apache
License.

Certainly there is history of people using PG code for non-PostgreSQL or

at least commercial derivative work. Greenplum for example.

Dave Cramer

davec@postgresintl.com
www.postgresintl.com

On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote:

From: Craig Ringer [mailto:craig@2ndquadrant.com]

I'm assuming you don't want to offer a grant that lets anyone use
them for anything. But if you have a really broad grant to
PostgreSQL, all someone would have to do to inherit the grant is
re-use some part of PostgreSQL.

Your assumption is right. No scope is the same as no patent; it
won't help to defend PostgreSQL community against rival
companies/communities of other DBMSs. Or, I think we can set the
scope to what OIN states. Fortunately, anyone can join OIN free of
charge.

I guess there's a middle ground somewhere that protects
substantial derivatives and extracts but stops you using some Pg
code snippets as a freebie license.

Are you assuming that developers want to use PG code snippets for
non-PostgreSQL or even non-DBMS software?

Our license very specifically permits all types of derivative
software.

I believe that accepting patented code from companies would be
practically more useful for PostgreSQL enhancement and growth.
PostgreSQL is now a mature software, and it can be more
corporate-friendly like other software under Apache License.

The Apache license is "friendly" to the patent holder, not so much to
the aspiring maker of derivative proprietary software.

We went with a very liberal license from the outset for what we
believed were good reasons, and that's served us well over the
decades. If you're proposing a change of this magnitude, it's going
to have to be a lot more convincing than, "it would be convenient for
my company this year."

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Hi,

On 2018-07-07 19:12:58 +0200, David Fetter wrote:

On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote:

I believe that accepting patented code from companies would be
practically more useful for PostgreSQL enhancement and growth.
PostgreSQL is now a mature software, and it can be more
corporate-friendly like other software under Apache License.

The Apache license is "friendly" to the patent holder, not so much to
the aspiring maker of derivative proprietary software.

I don't think that's a true characterization. There's no meaningful
reduction in freedoms to make derivative proprietary software in of
apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are
you talking about the retaliatory clause? If so, that only cancel the
patent license, not the entire license.

We went with a very liberal license from the outset for what we
believed were good reasons, and that's served us well over the
decades. If you're proposing a change of this magnitude, it's going
to have to be a lot more convincing than, "it would be convenient for
my company this year."

It's entirely possible to dual license contributions and everything. Why
are you making such aggressive statements about a, so far, apparently
good faith engagement?

Greetings,

Andres Freund

On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:

Hi,
On 2018-07-07 19:12:58 +0200, David Fetter wrote:

On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote:

I believe that accepting patented code from companies would be
practically more useful for PostgreSQL enhancement and growth.
PostgreSQL is now a mature software, and it can be more
corporate-friendly like other software under Apache License.

The Apache license is "friendly" to the patent holder, not so much to
the aspiring maker of derivative proprietary software.

I don't think that's a true characterization. There's no meaningful
reduction in freedoms to make derivative proprietary software in of
apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are
you talking about the retaliatory clause? If so, that only cancel the
patent license, not the entire license.

There is according to IP attorneys I've spoken to on the matter, and
this is frequently reflected in the open source policies companies
have. For liberal licenses, which are enumerated and do not include
the Apache license, the process is, as a rule, brief and perfunctory.
For all other licenses, the process ranges from cumbersome to not
worth doing.

We went with a very liberal license from the outset for what we
believed were good reasons, and that's served us well over the
decades. If you're proposing a change of this magnitude, it's
going to have to be a lot more convincing than, "it would be
convenient for my company this year."

It's entirely possible to dual license contributions and everything.
Why are you making such aggressive statements about a, so far,
apparently good faith engagement?

We went out of our way to excise code that the PostgreSQL license
doesn't cover some years back. I think that was done for good reasons,
which obtain to this day. While the introduction of code someone else
ultimately owns may seem harmless or even beneficial today, owners
change, as do their motivations. When we have nothing of this kind in
the project, we expose our future users to none of that risk.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On 2018-07-07 19:37:45 +0200, David Fetter wrote:

On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:

Hi,
On 2018-07-07 19:12:58 +0200, David Fetter wrote:

On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote:

I believe that accepting patented code from companies would be
practically more useful for PostgreSQL enhancement and growth.
PostgreSQL is now a mature software, and it can be more
corporate-friendly like other software under Apache License.

The Apache license is "friendly" to the patent holder, not so much to
the aspiring maker of derivative proprietary software.

I don't think that's a true characterization. There's no meaningful
reduction in freedoms to make derivative proprietary software in of
apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are
you talking about the retaliatory clause? If so, that only cancel the
patent license, not the entire license.

There is according to IP attorneys I've spoken to on the matter, and
this is frequently reflected in the open source policies companies
have. For liberal licenses, which are enumerated and do not include
the Apache license, the process is, as a rule, brief and perfunctory.
For all other licenses, the process ranges from cumbersome to not
worth doing.

You're talking about usage or contribution rules? I have a *very* hard
to belief this for the former. Note how vast amounts of recent widely
used open source projects are licensed under apache 2.0. For the
latter, yes, it can be a bit more complicated: But usually only in the
cases where we *want* contributor's companies to make explicit IP policy
decisions anyway.

We went with a very liberal license from the outset for what we
believed were good reasons, and that's served us well over the
decades. If you're proposing a change of this magnitude, it's
going to have to be a lot more convincing than, "it would be
convenient for my company this year."

It's entirely possible to dual license contributions and everything.
Why are you making such aggressive statements about a, so far,
apparently good faith engagement?

We went out of our way to excise code that the PostgreSQL license
doesn't cover some years back. I think that was done for good reasons,
which obtain to this day. While the introduction of code someone else
ultimately owns may seem harmless or even beneficial today, owners
change, as do their motivations. When we have nothing of this kind in
the project, we expose our future users to none of that risk.

I explicitly said *dual license*. And we definitely have code that's
not just under the PG license, but compatibly licensed (mostly various
BSD licenses). We even have a few pices (just build-time) of solely GPL
licensed code (e.g. ax_pthread.m4).

Greetings,

Andres Freund

On Sat, Jul 07, 2018 at 11:05:48AM -0700, Andres Freund wrote:

On 2018-07-07 19:37:45 +0200, David Fetter wrote:

On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:

Hi,
On 2018-07-07 19:12:58 +0200, David Fetter wrote:

On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote:

I believe that accepting patented code from companies would be
practically more useful for PostgreSQL enhancement and growth.
PostgreSQL is now a mature software, and it can be more
corporate-friendly like other software under Apache License.

The Apache license is "friendly" to the patent holder, not so much to
the aspiring maker of derivative proprietary software.

I don't think that's a true characterization. There's no meaningful
reduction in freedoms to make derivative proprietary software in of
apache 2 vs BSD/MIT like licenses. It gives you additional rights. Are
you talking about the retaliatory clause? If so, that only cancel the
patent license, not the entire license.

There is according to IP attorneys I've spoken to on the matter, and
this is frequently reflected in the open source policies companies
have. For liberal licenses, which are enumerated and do not include
the Apache license, the process is, as a rule, brief and perfunctory.
For all other licenses, the process ranges from cumbersome to not
worth doing.

You're talking about usage or contribution rules?

Usage rules, where "usage" is defined here to mean something that
might be modified. Sadly, these aren't usually published, so there's
not a great way to compare them even if you're an IP attorney so
inclined.

We went with a very liberal license from the outset for what
we believed were good reasons, and that's served us well over
the decades. If you're proposing a change of this magnitude,
it's going to have to be a lot more convincing than, "it would
be convenient for my company this year."

It's entirely possible to dual license contributions and
everything. Why are you making such aggressive statements about
a, so far, apparently good faith engagement?

We went out of our way to excise code that the PostgreSQL license
doesn't cover some years back. I think that was done for good
reasons, which obtain to this day. While the introduction of code
someone else ultimately owns may seem harmless or even beneficial
today, owners change, as do their motivations. When we have
nothing of this kind in the project, we expose our future users to
none of that risk.

I explicitly said *dual license*. And we definitely have code
that's not just under the PG license, but compatibly licensed
(mostly various BSD licenses). We even have a few pices (just
build-time) of solely GPL licensed code (e.g. ax_pthread.m4).

In none of these cases is someone going to be able to claim
proprietary rights to the derived code.

As to "dual license," that's another legal thicket in which we've been
wise not to involve ourselves. "Dual licensing" is generally used to
assert proprietary rights followed immediately by a demand for
payment. This is a thing we don't want to do, and it's not a thing we
should be enabling others to do as part of our project. If they wish
to do that, they're welcome to do it without our imprimatur.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Hi,

On 2018-07-07 20:51:56 +0200, David Fetter wrote:

As to "dual license," that's another legal thicket in which we've been
wise not to involve ourselves. "Dual licensing" is generally used to
assert proprietary rights followed immediately by a demand for
payment. This is a thing we don't want to do, and it's not a thing we
should be enabling others to do as part of our project. If they wish
to do that, they're welcome to do it without our imprimatur.

This is pure FUD. Obviously potential results of dual licensing depends
on the license chosen. None of what you describe has anything to do with
potential pieces of dual PG License / Apache 2.0 licensed code in PG, or
anything similar. You could at any time choose to only use /
redistribute postgres, including derivatives, under the rights either
license permits.

I think there's fair arguments to be made that we do not want to go fo
for dual licensing with apache 2.0. Biggest among them that the current
situation is the established practice. But let's have the arguments be
real, not FUD.

Andres

On Sat, Jul 07, 2018 at 12:01:10PM -0700, Andres Freund wrote:

Hi,

On 2018-07-07 20:51:56 +0200, David Fetter wrote:

As to "dual license," that's another legal thicket in which we've been
wise not to involve ourselves. "Dual licensing" is generally used to
assert proprietary rights followed immediately by a demand for
payment. This is a thing we don't want to do, and it's not a thing we
should be enabling others to do as part of our project. If they wish
to do that, they're welcome to do it without our imprimatur.

This is pure FUD. Obviously potential results of dual licensing depends
on the license chosen. None of what you describe has anything to do with
potential pieces of dual PG License / Apache 2.0 licensed code in PG, or
anything similar. You could at any time choose to only use /
redistribute postgres, including derivatives, under the rights either
license permits.

I think there's fair arguments to be made that we do not want to go fo
for dual licensing with apache 2.0. Biggest among them that the current
situation is the established practice. But let's have the arguments be
real, not FUD.

If they have no plans to exercise any proprietary rights, our usual
process where people submit things and agree to have us label them
with the PGDG copyright and publish them under TPL would be the
simplest way to accomplish it.

Any deviation from that process requires an explanation, which has not
thus far been proffered.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On 2018-Jul-07, David Fetter wrote:

If they have no plans to exercise any proprietary rights, our usual
process where people submit things and agree to have us label them
with the PGDG copyright and publish them under TPL would be the
simplest way to accomplish it.

Eh, but if the submitting company has patents, would it not be dishonest
to publish as PGDG copyright & license with no attached patent grant?
Some other company deriving a proprietary fork from Postgres could later
be sued by the submitting company, because there is no legal standing
for them to use the patented code.

TBH I don't understand how can we dual-license the code in a manner that
protects those proprietary forks. Can you (Andres) explain what is the
idea?

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hi,

On 2018-07-08 11:46:51 -0400, Alvaro Herrera wrote:

On 2018-Jul-07, David Fetter wrote:

If they have no plans to exercise any proprietary rights, our usual
process where people submit things and agree to have us label them
with the PGDG copyright and publish them under TPL would be the
simplest way to accomplish it.

Eh, but if the submitting company has patents, would it not be dishonest
to publish as PGDG copyright & license with no attached patent grant?
Some other company deriving a proprietary fork from Postgres could later
be sued by the submitting company, because there is no legal standing
for them to use the patented code.

Yep. And even if the original submitter has good intent, it's not
unlikely for companies to go bancrupt and their assets sold off.

TBH I don't understand how can we dual-license the code in a manner that
protects those proprietary forks. Can you (Andres) explain what is the
idea?

https://www.apache.org/licenses/LICENSE-2.0 grants roughly the same
rights as our license. But 3) additionally grants a patent license. That
license is *not* restricted to the code in unmodified form. By
requiring future contributions to be both under the pg license and
apache 2, downstream users, including proprietary forks, can safely use
code contributed in the future, without risk of patent mines.

There are arguments made that TPL (and BSD, MIT etc) already includes an
implicit patent grant, but while a longstanding theory, it's to my
knowledge not legally been tested.

IANAL etc.

Greetings,

Andres Freund

David,

On 07/07/2018 09:52 PM, David Fetter wrote:

Any deviation from that process requires an explanation, which has not
thus far been proffered.

Takayuki-san is *offering* a patent grant. That's something the TPL
clearly doesn't cover.

If they would follow the standard procedure, as you seem to propose,
they'd have every right to sue not only users of derivatives, but even
Postgres users for violation of their patent.

You seem to have experience with different licences and dual licensing.
What would you recommend Takayuki-san to do?

Kind Regards

Markus

--
Markus Wanner - http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of

Dave Cramer
Certainly there is history of people using PG code for non-PostgreSQL or
at least commercial derivative work. Greenplum for example.

Yes, we would be glad if companies in the PostgreSQL community, including Greenplum, could utilize our patents and prosper with no charge. We just want to use our (future) patents to make PostgreSQL a more wonderful DBMS, and to protect PostgreSQL against patent lawsuits by companies outside PostgreSQL community.

Regards
Takayuki Tsunakawa

On 9 July 2018 at 15:51, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com

wrote:

From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of

Dave Cramer
Certainly there is history of people using PG code for non-PostgreSQL or
at least commercial derivative work. Greenplum for example.

Yes, we would be glad if companies in the PostgreSQL community, including
Greenplum, could utilize our patents and prosper with no charge. We just
want to use our (future) patents to make PostgreSQL a more wonderful DBMS,
and to protect PostgreSQL against patent lawsuits by companies outside
PostgreSQL community.

I can't speak for my employer, but to me it seems like a broad patent grant
that follows the code and derivatives would be reasonable.

A grant just for "PostgreSQL", not so much.

I'm not sure how much practical protection/benefit that'd offer unless it
came with a retaliation clause, though, and how it'd differ from an
unrestricted grant of rights for everyone. I mentioned that earlier. If you
can take a few snippets of PostgreSQL code and add them to your product to
inherit the patent grant, then in practice the patent grant is universal,
not specific to PostgreSQL and derivatives. But if you start requiring
"substantial" derivatives, etc, it gets messy and complicated.

I'm not sure how grants with retaliation clauses would be received by
others here. I lack the expertise to have much of an opinion myself. Is
that what you propose?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

From: David Fetter [mailto:david@fetter.org]

We went out of our way to excise code that the PostgreSQL license
doesn't cover some years back. I think that was done for good reasons,
which obtain to this day. While the introduction of code someone else
ultimately owns may seem harmless or even beneficial today, owners
change, as do their motivations. When we have nothing of this kind in
the project, we expose our future users to none of that risk.

From: Andres Freund [mailto:andres@anarazel.de]

Yep. And even if the original submitter has good intent, it's not
unlikely for companies to go bancrupt and their assets sold off.

Thank you for supporting me, Andres. And please don't mind, David. I don't think you are attacking me. I understand your concern and that you are also trying to protect PostgreSQL.

On the other hand, I think TPL seems less defensive. I read in some report that Apache License and some other open source licenses were created partly due to lack of patent description in BSD and GPLv2.

How can we assure you? How about attaching something like the following to relevant patches or on our web site?

[Excerpt from Red Hat Patent Promise]
Red Hat intends Our Promise to be irrevocable (except as stated herein), and binding and enforceable against Red Hat and assignees of, or successors to, Red Hat’s patents (and any patents directly or indirectly issuing from Red Hat’s patent applications). As part of Our Promise, if Red Hat sells, exclusively licenses, or otherwise assigns or transfers patents or patent applications to a party, we will require the party to agree in writing to be bound to Our Promise for those patents and for patents directly or indirectly issuing on those patent applications. We will also require the party to agree in writing to so bind its own assignees, transferees, and exclusive licensees.

TBH I don't understand how can we dual-license the code in a manner that
protects those proprietary forks. Can you (Andres) explain what is the
idea?

https://www.apache.org/licenses/LICENSE-2.0 grants roughly the same
rights as our license. But 3) additionally grants a patent license. That
license is *not* restricted to the code in unmodified form. By
requiring future contributions to be both under the pg license and
apache 2, downstream users, including proprietary forks, can safely use
code contributed in the future, without risk of patent mines.

There are arguments made that TPL (and BSD, MIT etc) already includes an
implicit patent grant, but while a longstanding theory, it's to my
knowledge not legally been tested.

When we find a reasonable consensus here, I'd like to have our legal department write a patent grant statement, and then have it reviewed in this ML. Is the above statement of Red Hat's enough?

Regards
Takayuki Tsunakawa

On Thu, Jul 05, 2018 at 01:15:15AM +0000, Tsunakawa, Takayuki wrote:

From: Craig Ringer [mailto:craig@2ndquadrant.com]

I'm assuming you don't want to offer a grant that lets anyone use them for
anything. But if you have a really broad grant to PostgreSQL, all someone
would have to do to inherit the grant is re-use some part of PostgreSQL.

Your assumption is right. No scope is the same as no patent; it won't help to defend PostgreSQL community against rival companies/communities of other DBMSs. Or, I think we can set the scope to what OIN states. Fortunately, anyone can join OIN free of charge.

I guess there's a middle ground somewhere that protects substantial
derivatives and extracts but stops you using some Pg code snippets as a
freebie license.

Are you assuming that developers want to use PG code snippets for
non-PostgreSQL or even non-DBMS software? I believe that accepting
patented code from companies would be practically more useful for
PostgreSQL enhancement and growth. PostgreSQL is now a mature
software, and it can be more corporate-friendly like other software
under Apache License.

Suppose I have my own patches, not yet contributed to PG, and that I'm
using them in production. Can I use my patched version of PG with your
functionality?

Suppose I am developing my own PostgreSQL derivative, with my own secret
sauce perhaps, and perhaps I'm using it to build a proprietary cloud DB
service. Can I use my patched version of PG with your functionality?

I suspect your answer to the latter would be "absolutely not".

Maybe the first one would be OK if you can somehow distinguish it from
the latter?

Anyways, as a user of PG and occasinal hacker of PG, I would have to
insist on a ./configure way to exclude all functionality not licensed to
me for my use cases, and I would have to insist on all such code being
very well segregated (I don't want to look at your code!), and I would
insist too on any free configuration being highly tested.

If I were a core developer I would have to think long and hard about
whether I could meet user requirements and still have your code in-tree,
and I'm not sure I could do both of those.

Nico
--

On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:

It's entirely possible to dual license contributions and everything. Why
are you making such aggressive statements about a, so far, apparently
good faith engagement?

One problem is that many contributors would not want to be tainted by
knowledge of the patents in question (since that leads to triple
damages).

How would you protect contributors and core developers from tainting?

One possible answer is that you wouldn't. But that might reduce the
size of the community, or lead to a fork.

Dual licensing does not get you out of these issues.

Nico
--

On Mon, Jul 09, 2018 at 08:29:08AM +0000, Tsunakawa, Takayuki wrote:

There are arguments made that TPL (and BSD, MIT etc) already includes an
implicit patent grant, but while a longstanding theory, it's to my
knowledge not legally been tested.

When we find a reasonable consensus here, I'd like to have our legal
department write a patent grant statement, and then have it reviewed
in this ML. Is the above statement of Red Hat's enough?

You're acting as a go-between between your legal department and
executive directors on the one hand, and the PG community on the other.
That's not going to be an efficient conversation unless your legal
department understands open source communities and is willing to tailor
their patent grants to suit.

Also, these are *business* decisions that should be made by your
directors, not by your legal department. So really, this should be a
discussion between an authorized director at your company and the
community, with all discussions with your legal department being
internal to your company.

Also, your legal department will almost certainly default to the most
restrictive patent grants. That will contribute to making this
conversation unproductive.

My advice is that you relay all of this to your legal department and
your executives, and ask them make the most liberal patent grant
possible such that the PG community can live with it.

Also, I would advise you that patents can be the kiss of death for
software technologies. For example, in the world of cryptography, we
always look for patent-free alternatives and build them from scratch if
need be, leading to the non-use of patented algorithms/protocols in many
cases. Your best bet is to make a grant so liberal that the only
remaining business use of your patents is defensive against legal
attacks on the holder.

(IMO software patent lifetimes should be commensurate with the effort it
takes to come up with and develop an idea for the field -- five to eight
years max, not seventeen or twenty.)

Nico
--