[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gplv3 files and updates

From: Yoann Vandoorselaere
Subject: Re: gplv3 files and updates
Date: Sun, 08 Jul 2007 16:48:23 +0200

Le vendredi 06 juillet 2007 à 17:33 -0500, Karl Berry a écrit :
> Some library using GnuLib are "GPLv2 or later", but some of the
>     application using these library are "GPLv2 only".
> Um, not to point out the obvious, but
> our goal is not maximize popularity.
> Our goal is to maximize freedom.
> That's why GNU exists.
> So far, no one I have talked to has had objections to GPLv3.  I
> certainly agree with Bruno that it is polite to talk to maintainers who
> might be affected, especially in these early days, but if they refuse to
> switch, that is not something we should cater to.
> Can you write to these application authors and see if they actually
> object to GPLv3?

There are an undefined number of application out there which are GPLv2
only. Whatever being the reason for their choice, I can understand that
some people want to review the new license before applying it to their

Here is the Snort statement (available from

"Version 3 of the GPL is being released today. Sourcefire would like to
notify users of the Snort technology that we have decided not to
transition to GPL v3 pending a review of the full license language and
an analysis of its suitability to the Snort project. Additional language
has been attached to the LICENSE and COPYING files in the source code
distribution for Snort."

I'd like to empathize that there is absolutely no need to urge people
(especially library writers - read ahead) to switch to GPLv3, and I
guess the more you are going to stress them with this issue, the less
they'll be likely to do that switch.

As a library author, and even though I might want to switch to GPLv3, my
goal is to avoid creating incompatibility with software using my
library. Doing the switch right now would just be asking for trouble.
Instead, I'll be waiting for applications to update, and then I'll
perform the change in the library these applications use.

To me, this is the same concern as with software development: you don't
change a public API with every release of your library. Rather, you make
sure that newly added bit of software can be used separately without
breaking application for your user. Then at a later time, you can remove
the old API.

Yoann Vandoorselaere <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]