3 ms·

Great. I'm even more likely to use GPL now (which is a complete 180 from my early days where I would only consider BSD or MIT).

dralley 4y ago
So pretty much every line of code I've written in my professional career has been GPL licensed (I work for an open source software company), but I understand why some people - even those that are strong supporters of free software - take issue with the GPL and similar licenses. For me, the biggest problems are: 1) Strong copyleft licenses often end up being incompatible with other free software licenses, especially other strong copyleft licenses. GPLv2(not +) and GPLv3 are incompatible, GPLv2 is incompatible with Apache 2.0, etc. Proliferation of strong copyleft licenses can therefore create serious interoperability challenges even within the free/libre software ecosystem. 2) LGPL is deeply tied to the technical specifics of how libraries and executables are linked together. This might have been reasonable when 90% of software on Linux was written in C and most developers could be expected to deeply understand those concepts, but it is no longer a reasonable expectation. Understanding how to comply with LGPL when it comes to C++ with templates, or Rust, or Go, or C with LTO techniques and inlining, is now an incredible headache when compared to licenses like MPLv2 that are approximately similar in scope but much simpler to understand. 3) The definition of "derivative work" is too broad. The FSF considers that re-implementing a library in an entirely different language would be a "derivative work" [0] Perhaps that's fair enough - if the translation is basically identical. But what if it's not? Where does the line between derivative and non-derivative work lie? If I was a very active contributor to some GPL project, and years later I decide to write a vaguely-similar-but-different program in some entirely different language, is that a derivative work? Do I need to walk a lawyer through every line of code? These incompatibilities and chilling effects do come with a cost to free software as a whole. I still think GPL can be good for many types of software but in some respects it really can get in the way of proliferating free software. [0] https://www.gnu.org/licenses/gpl-faq.html#TranslateCode https://www.gnu.org/licenses/gpl-faq.html#TranslateCode
- StayTrue 4y ago
  I'm not wed to GPL specifically but I feel better if the license is tested rather than theoretical so cases like this are a step forward. Without getting into details, I've released BSD-licensed software that has been used in commercial products and integrated into the surveillance apparatus (without my knowledge or consent). A copyleft license would have made that more difficult so the stronger the better IMO.

dralley 4y ago

So pretty much every line of code I've written in my professional career has been GPL licensed (I work for an open source software company), but I understand why some people - even those that are strong supporters of free software - take issue with the GPL and similar licenses. For me, the biggest problems are: 1) Strong copyleft licenses often end up being incompatible with other free software licenses, especially other strong copyleft licenses. GPLv2(not +) and GPLv3 are incompatible, GPLv2 is incompatible with Apache 2.0, etc. Proliferation of strong copyleft licenses can therefore create serious interoperability challenges even within the free/libre software ecosystem. 2) LGPL is deeply tied to the technical specifics of how libraries and executables are linked together. This might have been reasonable when 90% of software on Linux was written in C and most developers could be expected to deeply understand those concepts, but it is no longer a reasonable expectation. Understanding how to comply with LGPL when it comes to C++ with templates, or Rust, or Go, or C with LTO techniques and inlining, is now an incredible headache when compared to licenses like MPLv2 that are approximately similar in scope but much simpler to understand. 3) The definition of "derivative work" is too broad. The FSF considers that re-implementing a library in an entirely different language would be a "derivative work" [0] Perhaps that's fair enough - if the translation is basically identical. But what if it's not? Where does the line between derivative and non-derivative work lie? If I was a very active contributor to some GPL project, and years later I decide to write a vaguely-similar-but-different program in some entirely different language, is that a derivative work? Do I need to walk a lawyer through every line of code? These incompatibilities and chilling effects do come with a cost to free software as a whole. I still think GPL can be good for many types of software but in some respects it really can get in the way of proliferating free software. [0] https://www.gnu.org/licenses/gpl-faq.html#TranslateCode https://www.gnu.org/licenses/gpl-faq.html#TranslateCode

StayTrue 4y ago
I'm not wed to GPL specifically but I feel better if the license is tested rather than theoretical so cases like this are a step forward. Without getting into details, I've released BSD-licensed software that has been used in commercial products and integrated into the surveillance apparatus (without my knowledge or consent). A copyleft license would have made that more difficult so the stronger the better IMO.