We are talking lgpl, not gpl, here. You would still be free to use the
driver or parts of it unaltered in your applications. You can modify it
for your own purposes if you don't sell them. What you can't do is use
modified versions of the driver in stuff you sell without making the
changes public. AFAIK, this would be satisfied by publishing a patch on
the sourceforge patch tracker. To me this is developer friendly, since it
keeps people from taking advantage of each other.

If we change the license do you want us to remove your code contributions?
I don't think we are obligated to because the original license allows its
use under lgpl, and your original contribution will still be available
under dual license, but I would rather not do something with your code that
you are unhappy with.

Thanks
david jencks

On 2002.08.23 07:19:44 -0400 Ken Richard wrote:
> I have contributed code (very little, but some) and as a commercial
> developer I do not feel comfortable with the GPL/LGPL because I would
> like to use parts of the driver in my own application. I am also not a
> legal expert, but I believe that the IPL license is more friendly
> towards commercial software developers who want to use the code.
>
> -Ken
>
> -----Original Message-----
> From: William L. Thomson Jr. [mailto:support@...]
> Sent: Thursday, August 22, 2002 10:17 PM
> To: Firebird-Java
> Subject: Re: [Firebird-Java] Change firebirdsql license to lgpl only?
> and,lets release next version.
>
> To all,
>
> I have not contributed code yet, but would like to at some
> point. I am
> learning about the C API at the moment at the same time I am creating a
> C++ wrapper like IBPP but designed like a JDBC driver. So there are
> classes such as Connection, Statement, PreparedStatement and ResultSet.
> So far so good, but it's mostly for my current needs, so will require
> lots of work to be as useful as IBPP to others. However Java people
> using a JDBC driver and then needing to use C++ will love it.
>
> While most of my experience is in Java, I need to learn C/C++
> for some
> internal apps that I am developing. I am not using Java due to
> deployment time of the app. I do not want to have to install JRE on each
> machine my apps will run on. Plus I prefer the speed of C/C++ over Java.
> Not to mention using less system resources in the process, if I
> design/code the apps properly.
>
> To the point, I think migrating to lgpl is better than the
> current
> licensing scheme. I am still trying to understand all the different
> licenses out there. From my understanding so far, if any part of a gpl
> app is using a license that is not gpl compatible it makes the whole app
> non gpl compatible. According to
>
> http://www.gnu.org/licenses/license-list.html
>
> So the current license scheme really screws things up. So I
> would
> recommend go with one or the other and do not mix them. At the same time
> I am not to sure how many people will be building gpl compatible apps
> with the driver. So it may be a mood issue, but from a legal standpoint
> it really should be one or the other. They are two different licenses
> mpl/lgpl. MPL is not GPL compatible.
>
> Now on the release front, I would definitely stick with RC1 if
> anything. I feel the driver needs a bit more work before going to the
> final release stage with a 1.0 version number or something.
>
> There are still some quirks here and there, one of which I still
> need
> to make a sample app to demonstrate. I am getting ready to go on
> vacation and will see if I have some spare time to slap a test app
> together. But I mentioned the problem and the fix a while back, but the
> CVS code does not seem to reflect this change. The problem I ran into
> was an uncatchable exception being thrown when selecting a empty blob
> column/row. The past threads with the details are in the list archive.
>
> Anyway outside of the few quirks here and there, the biggest
> thing I
> would like to see addressed in some manor is the speed of the driver.
> The current driver seems a bit sluggish compared to InterClient. I have
> had some clients complain, and ask why I switched drivers.
>
> For performance reasons and some others like the blob issue I
> should
> have stuck with InterClient. Although in doing so I would not be helping
> the development on the new JCA-JDBC driver. While I have not contributed
> code, I feel feedback and testing in the real world is almost as
> important. So my dropping InterClient for the JCA-JDBC driver was to
> help out in what ever way I can. So the JCA-JDBC driver can be all it
> can be.
>
> If there is anything I can do/contribute, testing wise or
> anything else
> I am happy to like others, as I have time to. When I build my general
> understanding of working with FB on the low level I do plan to join the
> project and contribute code if I can. By project I mean the JCA-JDBC
> project, not so much the Firebird project. That's still out of my
> league.
>
> That's my four cents. :)
>
> --
> Sincerely,
> William L. Thomson Jr.
> Support Group
> Obsidian-Studios Inc.
> 439 Amber Way
> Petaluma, Ca. 94952
> Phone 707.766.9509
> Fax 707.766.8989
> http://www.obsidian-studios.com
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>