Just a few minor points :-)
On 8/19/07, Christopher Murtagh <[EMAIL PROTECTED]> wrote:
>
> On Sunday 19 August 2007 04:48:55 Chris Travers wrote:
> > On 8/18/07, Christopher Murtagh <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
