 |
The first public release of RackTables was made before the publication of the final edition of GPLv3. The open-jaw version clause from then-default GPLv2 template didn't seem to serve the purpose, which was to stick with a known-good license once and to forget about it for as long as possible. After GPLv3 became final its difference from GPLv2 as applied to RackTables didn't seem to justify a switch to GPLv3, so everything just remained as it was. As far as I understand the FAQ above, GPLv2/GPLv3 incompatibility only gets in the way of combining source code together, not distributing existing software. Within a typical operating system GPLv2 and GPLv3 software can and do co-exist. If you think the current way of licensing gets in the way of development, please explain in which practical way. |
 |
I foresee a problem such as the following: someone writes an extension (in racktables-contrib) that relies on a GLPv3+ library. This is allowed, but it is not allowed to distribute the combination. Even not when they are distributed as two packages that are dynamically linked. At least Debian is rather keen on sticking to these rules (I've seen a few other distros being a bit more lenient). (FYI: something along these lines happened to me about 10 years ago, where encrypted passwords were disabled in a daemon; the linked OpenSSL library has an incompatible license. I'm a bit touchy about license issues since that time). |
|
|
Thank you for the explanation. So long as such GPL2+GPL3 combination can become an issue in theory, it makes most sense not to change anything until there is such new GPL3 code around and the issue can be seen in practice. In that case I will be happy to resolve it with the change you have explained. |
- Anonymous
