On 8/19/07, Christopher Murtagh <..hidden..> wrote:
On Sunday 19 August 2007 04:48:55 Chris Travers wrote:
> On 8/18/07, Christopher Murtagh <..hidden..> wrote:
> > On Saturday 18 August 2007 13:47:32 Joshua D. Drake wrote:
> > > As a core member, if it were up to me, we would ditch GPL all together.
> >
> > Fortunately IMO, we're not able to do so without a total re-write of the
> > software.
>
> On the other hand, we *could* go LGPL and make it entirely LGPL at 2.0.
> The work as a whole would be GPL until the last GPL code would be out.
> Since we are beginning a rewrite anyway....
Sure, but I don't really see the much of an advantage in our case to change
licenses (to v3 or LGPL). At the moment, I don't see the current license
causing any problems or confusion with anyone. Changing licenses makes people
leery though.
Actually on umpteenth reading of the GPL v3 and second reading of the LGPL
2.1, it doesn't solve any of our problems. LGPL 2.1 code can't be "deriative" (whatever that means in your jurisdiction) of GPL v3 code without also releasing it under the GPL v3. So we still would have the dependency problem.
Actually, it might b worth considering moving portions of our application (such as the stored procs) into LGPL licenses so that interop with applications under other non-compatible OSI-approved licenses. Alternatively we could add a "linking" exception to those areas to OSI-approved licenses.
> The GPL v2 license was a good license for many purposes. The GPL v3
> undermines that pretty substantially though I would not be opposed to doing
> new code as GPL v2-only if we could be assured that dependencies wouldn't
> move on us.
Even if we kept it 'GPL v2 or greater' what impact would it have on us?
My concern is what happens when dependencies start to move. We may find that we have to either move with them or engineer around the dependency.
If
someone wants to fork LSMB and create a GPL 3 project out of it, I don't see
a problem with it.
We wouldn't be able to use their changes. Not that this is the end of the world.
> > I'm a big fan of the GPL for these exact same reasons. The GPL is the
> > reason
> > why there is so much corporate support for the Linux kernel.
>
> I used to think so. I now think it is because BSD was always pretty
> fragmented and political while Linus was very good at getting community
> involvement.
I've been talking to some folks at these companies now, and at first their
lawyers didn't really get the GPL at all, and in companies like IBM, the idea
of giving away IP went against their core existence. This has changed greatly
though, the SCO case really brought this to the lawyers attention as well as
to the upper crust of these companies. I guess we have SCO to thank for that.
Interestingly, even before SCO, IBM was releasing code under a variety of licenses from the Apache license to the GPL, to the IBM public license (which had an initially very controversial patent protection clause which eventually made it into the Apache and GPL licenses).
Now, they definitely see the GPL as a way of releasing code for their core
infrastructure that customers or OEMs can change to suit their needs, without
it being used against them by the competition.
The GPL provides some protection for slow-moving projects, and lowers the initial community bar necessary for a commercial entity to donate code without being the competition's free lunch. Note that it doesn't provide any fundamental changes, just slants the playing field a little bit.
The issue is this: If a project's pace of development is rapid, nobody wants to hold onto their code if they can get it into the official distribution (under any OSI-approved license). Nobody wants to take on that maintenance job. This is no different under GPL or BSD licenses. The GPL provides a shield for projects with slow development, small communities, etc.
> > If the kernel was using the BSD license for example, IBM, HP, SGI, etc.
> > would all have to worry that one of their competitors would come up with
> > the 'Next big thing' (tm) and be able to run away with the milk, the cows
> > and the farm to boot.
>
> Funny. Tell this to the PostgreSQL community or the Apache community. IBM
> does contribute code back to Apache iirc.
Yes, but IBM does not put any of its core business in either of these.
Really? Cloudscape? Improvements made to Apache HTTPD in the course of developing Websphere? Oh wait, IBM's core business is now entirely services ;-).
The
amount of work and effort IBM puts into Linux easily dwarfs anything it does
in PostgresSQL and Apache combined. IBM's got DB2, and Websphere. There's no
indication that IBM is dumping DB2 for Postgres.
Cloudscape/Derby? This is closer to the core business of DB2 than a lot of people realize. Prior to the release under the Apache license, Cloudscape was basically a light-weight DB2-like RDBMS specially for Java/Websphere apps designed with upselling DB2 in mind. It was basically their equivalent of MSDE or Oracle Express Edition. Now, it is something entirely different thanks to the heavy involvement of Sun. While IBM will probably never dump DB2 in favor of either Cloudscape or PostgreSQL, Cloudscape development is going in directions which are likely to substantially reduce the midmarket appeal of DB2.
However, AIX is on its way
to getting mothballed in favour of Linux and that's *big*.
The difference
between these applications and Linux is that IBM needs the drivers it writes
for its hardware to work in competitors hardware, if the competitors change
their hardware, they won't be able to adapt the IBM drivers without releasing
this code. Linux is a great way to get your foot in the door and the GPL a
great equalizer.
I still don't think the license has as big an impact for rapidly advancing applications as you suggest. If you look at companies like EnterpriseDB, Command Prompt, Green Plum, and others, they almost always contribute everything back to the core PostgreSQL distribution that a) the community wants and b) does not define their core market strategy. THe reason: everyone wants to get as many *other* people to maintain their code as possible so that they can cut their costs.
I am sure* that the equation for releasing something like the Mammoth replicator would be different if it were to be maintained as part of the PostgreSQL core distribution than if it were to be released separately. Under the former case, there is probably no reason to consider the permissive nature of the BSD license to be a problem. However, if it were stand alone, there would be more of a concern of competitors using it to subsidize their R&D at the original contributor's expense.
* Josh D-- correct me if I am wrong :-)
> Reference implementations *should* be BSD licensed.
I don't see why making it BSD vs GPL has any real benefit to the users, but
that's an entirely different philosophical discussion. Here, have some of
this fruit drink, and we'll talk... ;-)
No, but *reference implementations" by definition are designed to be sample implementations of a standard that anyone can use to build interoperable products. The GPL as a license choice would more or less keep it from being a "reference implementation" because it substantially prevents an implementation from being used as a reference by placing all sorts of conditions on derivative implemetnations.
> If we go with the GPL v3, I would like to suggest we have further
> discussions relating to what other permissions we might need to add for
> portions of the code.
Again, I don't see any advantage or need to move to GPL 3 at the moment.
Sure, it makes for an interesting, if not heated discussion, but other than
that what does it bring to us or our users? If it ain't broke...
Agreed. But it might be a good time to start looking at issues such as:
1) Do we want to eventually upgrade the license (it would take something major for me to say yes to this).
2) Do we want to discuss potential interop issues and license implications? I.e. suppose someone integrates PostBooks and LedgerSMB using stored procedures-- do we think this is OK (not allowed under the GPL due to license incompatibility between the MPL and the GPL, though both are OSI-approved)? Should we add a license exception? Should we move some areas into LGPL?
On the second questions, I guess my suggestion is that, for the new framework we may want to add a broad license exception to "link" the stored procedures and Perl API to components written in other OSI-approved licenses.
We can deal with license headache issues on a case-by-case basis when they arrive.
Best Wishes,
Chris Travers