4 ms·

IIRC, yes; it was the last version under GPLv2.

alerighi 7y ago
What is the problem of using a GPLv3 compiler? Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem. Not only that, but even proprietary software can be built with a GPL compiler, the binaries produced by the compiler are not considered derived work that must be covered by the same GPL license, so if Microsoft wanst to build Windows with GCC for example they can do that, provided that they don't link in the executable produced GPL code (e.g. glibc).
- lazyier 7y ago
  The legal subject of licensing GPLv3 is a lot more nuanced then you are indicating. One example of this is that while the license can explicitly allow proprietary software to link to a library it cannot explicitly deny proprietary software linking to a library. Copyright law defines what is and what isn't derivative works, not licenses. And copyright licenses are fundamentally limited to copyright law. But there are technical reasons to avoid using GCC nowadays as well. The GNU people have built in shitty anti-features into GCC suite, ostensibly to limit the ability of proprietary software to incorporate GCC into their products. LLVM, which is what CLang uses, was partially a response to the artificial technical limitations intentionally imposed on users by the GNU GCC authors.
  - Avamander 7y ago
    I don't see it as an anti-feature.
  - cycloptic 7y ago
    Don't write proprietary compilers. You can thank GCC for mostly eliminating that possibility in the years before clang. Now we are dealing with that again.
  - kick 7y ago
    That's a bit revisionist in every sense. https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
  - nrclark 7y ago
    The main issue with GPLv3 software isn't the linking. You can link stuff using GCC without making sources available to anybody. The main issue with GPLv3 is the so-called Tivoization clause. It basically states that if you have a product that ships with any GPLv3 software, you need to give your users the ability to install a modified version of anything you included that's GPLv3. Which basically means you can't lock down your device. That's a big security risk on an embedded system - both from an IP protection point of view, and also from a botnet/pwning point of view. FreeBSD (and others presumably) don't want their users to need to worry about accidentally installing something from the core system and finding themselves in violation of the GPL.
    - cycloptic 7y ago
      >That's a big security risk on an embedded system - both from an IP protection point of view If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. The OEM's IP situation is also not related to the security of the customer. Maybe it matters to the security of the OEM, but that's different. >and also from a botnet/pwning point of view Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased.
      - nrclark 7y ago
        > If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. That also is not related to the security of the customer at all. Maybe it matters to the security of the OEM, but that's different. I can't speak for other engineers. But at companies I've worked in, a common product model is "embedded Linux with GPLv2 software, and some proprietary secret-sauce binaries". At those companies, they usually do send patches to upstream open-source projects and they try to contribute. Also they usually provide full source-code on request, for everything except the proprietary stuff. The net effect of GPLv3 has been that GNU packages basically don't exist on embedded devices any more. Which means that engineers like me don't have the professional opportunity to contribute features and patches. It sort of isolates GPLv3 projects into a walled garden, which I feel like is the opposite of what GPL was intended to foster. Instead, I can only have the professional opportunity to contribute on GPLv2 or permissive-license projects. > Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased. I sympathize with the intent behind this. There are also just some practical realities that are tough. At my current company, the team working on our next embedded Linux product is pretty small. We don't have infinite time or resources to make sure that our own code is 100% intrusion-resistant - all we can do is try our best. It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead. And if you have access to the filesystem, it's that much easier to comb through it and look for vulnerabilities in our network updater (for example). And it's easier to pick apart the proprietary bits with Ghidra or something. Could you do it anyways, even without our help? Maybe. But it's much harder. Can we design a system that's robust enough to allow you to install whatever you want on your unit? Maybe. Probably. Hopefully we're already there. But I'm not going to risk my company's livelihood on it just to ship GPLv3 software, especially considering that there are almost-as-good alternatives for a lot of it. We just don't have the resources to make sure we cover every security angle on an open-box system.
- throw0101a 7y ago
  > Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem. And what about Dell EMC Isilon OneFS, which uses FreeBSD as the base of their product? Or Panasas or NetApp? Juniper? Sony and their PlayStation 4? Netflix? * https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD https://en.wikipedia.org/wiki/List_of_products_based_on_Free... FreeBSD is not just looking at themselves, but also at their users, which my have issues with GPLv3.

What is the problem of using a GPLv3 compiler? Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem. Not only that, but even proprietary software can be built with a GPL compiler, the binaries produced by the compiler are not considered derived work that must be covered by the same GPL license, so if Microsoft wanst to build Windows with GCC for example they can do that, provided that they don't link in the executable produced GPL code (e.g. glibc).

lazyier 7y ago
The legal subject of licensing GPLv3 is a lot more nuanced then you are indicating. One example of this is that while the license can explicitly allow proprietary software to link to a library it cannot explicitly deny proprietary software linking to a library. Copyright law defines what is and what isn't derivative works, not licenses. And copyright licenses are fundamentally limited to copyright law. But there are technical reasons to avoid using GCC nowadays as well. The GNU people have built in shitty anti-features into GCC suite, ostensibly to limit the ability of proprietary software to incorporate GCC into their products. LLVM, which is what CLang uses, was partially a response to the artificial technical limitations intentionally imposed on users by the GNU GCC authors.
- Avamander 7y ago
  I don't see it as an anti-feature.
- cycloptic 7y ago
  Don't write proprietary compilers. You can thank GCC for mostly eliminating that possibility in the years before clang. Now we are dealing with that again.
- kick 7y ago
  That's a bit revisionist in every sense. https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
- nrclark 7y ago
  The main issue with GPLv3 software isn't the linking. You can link stuff using GCC without making sources available to anybody. The main issue with GPLv3 is the so-called Tivoization clause. It basically states that if you have a product that ships with any GPLv3 software, you need to give your users the ability to install a modified version of anything you included that's GPLv3. Which basically means you can't lock down your device. That's a big security risk on an embedded system - both from an IP protection point of view, and also from a botnet/pwning point of view. FreeBSD (and others presumably) don't want their users to need to worry about accidentally installing something from the core system and finding themselves in violation of the GPL.
  - cycloptic 7y ago
    >That's a big security risk on an embedded system - both from an IP protection point of view If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. The OEM's IP situation is also not related to the security of the customer. Maybe it matters to the security of the OEM, but that's different. >and also from a botnet/pwning point of view Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased.
    - nrclark 7y ago
      > If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. That also is not related to the security of the customer at all. Maybe it matters to the security of the OEM, but that's different. I can't speak for other engineers. But at companies I've worked in, a common product model is "embedded Linux with GPLv2 software, and some proprietary secret-sauce binaries". At those companies, they usually do send patches to upstream open-source projects and they try to contribute. Also they usually provide full source-code on request, for everything except the proprietary stuff. The net effect of GPLv3 has been that GNU packages basically don't exist on embedded devices any more. Which means that engineers like me don't have the professional opportunity to contribute features and patches. It sort of isolates GPLv3 projects into a walled garden, which I feel like is the opposite of what GPL was intended to foster. Instead, I can only have the professional opportunity to contribute on GPLv2 or permissive-license projects. > Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased. I sympathize with the intent behind this. There are also just some practical realities that are tough. At my current company, the team working on our next embedded Linux product is pretty small. We don't have infinite time or resources to make sure that our own code is 100% intrusion-resistant - all we can do is try our best. It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead. And if you have access to the filesystem, it's that much easier to comb through it and look for vulnerabilities in our network updater (for example). And it's easier to pick apart the proprietary bits with Ghidra or something. Could you do it anyways, even without our help? Maybe. But it's much harder. Can we design a system that's robust enough to allow you to install whatever you want on your unit? Maybe. Probably. Hopefully we're already there. But I'm not going to risk my company's livelihood on it just to ship GPLv3 software, especially considering that there are almost-as-good alternatives for a lot of it. We just don't have the resources to make sure we cover every security angle on an open-box system.
throw0101a 7y ago
> Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem. And what about Dell EMC Isilon OneFS, which uses FreeBSD as the base of their product? Or Panasas or NetApp? Juniper? Sony and their PlayStation 4? Netflix? * https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD https://en.wikipedia.org/wiki/List_of_products_based_on_Free... FreeBSD is not just looking at themselves, but also at their users, which my have issues with GPLv3.