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 software. Here is the Snort statement (available from http://www.snort.org/pub-bin/snortnews.cgi#664): "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 <[EMAIL PROTECTED]>
