Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Jul 13, 2007, Nicholas Nethercote <[EMAIL PROTECTED]> wrote: > > > One way to view it: the license is a feature. Therefore changing the > > license is changing a feature. > > Every release of GCC in the past decade (and then some) was GPLv2+. > GPLv3 has always been one of the options. > > Anyone who had their heads in the sand for the past 18 months when > GPLv3 was being publicly discussed and developed, or wasn't at the GCC > Summit last year when I mentioned that the FSF would most certainly > want to upgrade the license of every project whose copyright it held > as soon as GPLv3 was ready, may indeed consider the license upgrade as > a surprising new feature.
Speaking as an individual developer who nonetheless needs to follow his company's policies on licensing, I need it to be *absolutely clear* whether a piece of software can be used under GPLv2 or not. If there's a situation where 'silent' license upgrades can occur, where even just one file in a release might be GPLv3, or any other situation where the license is not clear, then to me that software is unusable. This applies to subversion as well to releases in tarballs. So I would ask the SC to ensure that any piece of software that might not be licensable under GPLv2 is clearly marked as such, in a single obvious place, as prominently as possible. A new distinctive version number (eg. 4.3.0 or 5.0.0, or 4.3.3, or 4.3.1.4.1.6) would help a lot in this regard. (I would also like every other possible means of notification: updating COPYING, release notes, gcc.gnu.org front page, gcc-announce, skywriting...) As far as surprises go, I would point out that the new C++ front-end was not a surprise to anyone following GCC development, but that doesn't mean that everyone was ready to use it on their code the day that 4.0.0 was released. In fact I think not everyone is ready to use it even today, two years after the release, and that's the kind of timescale to be thinking about when considering GPLv3 adoption.
