Re: Steering committee responce to Great Bridge LLC

"Ross J. Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu> writes:
> Now we will see the real world test of the (occasional) license debates
> that have occured in the postgres community. One of the major points made
> by the Berkeley/X license proponents is that these licenses are more
> acceptable to commerical enterprises, since they allow the commercial
> concerns to keep their changes private. The major complaint from the
> GPL crowd has been that that these licenses allow commerical concerns
> to take the existing code private, along with their changes.

Yes. BSD-style licensing is clearly more acceptable to businesses
than GPL-style, as the Postgres community understood all along.
I think GB's choice of Postgres as the database they wanted to work
with is not unrelated to that.

BTW, while we're mentioning licenses: one of the interesting things
that's emerged from core's discussions with Landmark/GB is some
suggestions from their corporate legal counsel for clarifying the
language of the Postgres license, and in particular bringing it into
sync with the realities of copyright law under the Berne convention,
which are (if I understood him correctly) that the copyright is actually
distributed among all the contributors. This is something that people
have expressed concern about repeatedly on pghackers, so it seems to me
that listening to a real lawyer on the subject will be a very good thing
to do. I do *not* want to get into that discussion today, just let
folks know that there will be an upcoming thread about it pretty soon.
We wanted to postpone the discussion until Great Bridge was out in the
open and could allow Rusty Friddell, their counsel, to answer questions
about his suggestions directly. (And just to defuse any fears
beforehand, there will be no license changes without full discussion
and consensus from the pghackers community. This decision is not
core's to make, but the community's.)

> Will GB follow the RedHat model, and commit to releasing code to any
> changes they make? (Note that RedHat has no choice in this for the Linux
> kernel) Or will there be a 'GreatBridge' version of pgsql, perhaps with
> extended features? I hope GB realizes that trying to take on the 'big
> boys' with proprietary extensions is unlikely to be a winning strategy.

Ned should probably answer this directly, but I will say that I believe
that GB is building itself on the assumption that open-source
development is better than proprietary development. They'd be fools to
go up against Oracle with a proprietary system and try to play Oracle's
game on Oracle's turf. They're not fools.

> Here lies the potentially most exiting, but also most dangerous part,
> for the pgsql public at large: the core team has done amazing work,
> in their spare time. Imagine how productive they'd be working on pgsql
> full time! However, the big fear is: will GB take pgsql effectively
> private, by hiring away key developers?

This is something that core has agonized over since the start of this
affair. How can we open up the project to (more) commercial
participation, without destroying the open-source dynamics that have
made the project successful in the first place? We don't have all the
answers, and maybe not any. One thing we have agreed to is that there
must not be an unseemly fraction of core members working for the same
company. With six people on core, probably about two working at the
same company would be a reasonable limit.

> Even if GB commits to making all the code they develop available under the
> existing license, this has a more subtle downside: schedule pressure. As
> an avocation, pgsql benefits from the 'inspirational' effect: when the
> developers are inspired by a good idea, they work long and hard. If
> the creative juices run dry, it can be put aside. As vocation, there's
> always deadline pressure.

Yes, this concerns us too. We do not want to see a large fraction of
the development effort coming from any one company, even if they do
contribute all their work back to the project, because their company
priorities might cause them to take shortcuts that shouldn't have been
taken. Core will have an even greater responsibility in future to review
incoming patches and work proposals to make sure that the project moves
forward with consistent goals and design practices. This might mean
that the core committee needs to be enlarged further, or that we need to
have an almost-inner-circle group of secondary reviewers who can help.

I think that Postgres is now starting a new phase of life, as it moves
further into business acceptance. Our challenge is to keep the project
alive and dynamic, and not sacrifice the ideals that have brought it so
far. It will not be easy, but the alternative to growth is stagnation.
We must be optimistic that we can meet the challenge.

regards, tom lane