Why is FreeBSD deprecating GCC in favor of Clang/LLVM?(unix.stackexchange.com)
unix.stackexchange.com
Why is FreeBSD deprecating GCC in favor of Clang/LLVM?
http://unix.stackexchange.com/questions/49906/why-is-freebsd-deprecating-gcc-in-favor-of-clang-llvm
162 comments
>as Apple refused to continue work on gcc due to the licensing changes
This. As stated in the accepted answer in the linked article, licensing issues are the real reason. Technical differences are ephemeral. The competition between GCC and LLVM has a habit of inducing improvments in both projects. By all means, at any given point in time one project can have an edge over another in this niche or that edge case. But fundamentally this is a philosophical divide between Free Software and Open Source Software.
This. As stated in the accepted answer in the linked article, licensing issues are the real reason. Technical differences are ephemeral. The competition between GCC and LLVM has a habit of inducing improvments in both projects. By all means, at any given point in time one project can have an edge over another in this niche or that edge case. But fundamentally this is a philosophical divide between Free Software and Open Source Software.
This is a licensing debate, but please don't conflate that with a divide between "Free Software" and "Open Source". Both GCC and LLVM/clang qualify as both Free Software and Open Source software. Both terms encompass both copyleft and non-copyleft (all-permissive) licensing.
GCC uses a copyleft license; LLVM/clang uses an all-permissive license. FreeBSD prefers to avoid dependencies on copyleft code, especially in their core; thus, they naturally prefer LLVM/clang.
GCC uses a copyleft license; LLVM/clang uses an all-permissive license. FreeBSD prefers to avoid dependencies on copyleft code, especially in their core; thus, they naturally prefer LLVM/clang.
Apologies. That is a better comparison: A divide between copyleft licensing and permissive licensing.
Then again, copyleft licensing is idiomatic of free software, and permissive licensing is idiomatic of open source software.
This essay covers the essential differences:
http://www.linfo.org/open_source.html
This essay covers the essential differences:
http://www.linfo.org/open_source.html
No, it's really not in anything but an inaccurate tribal sense. The FSF has recognized BSD/MIT-style licenses as "free software" since before the Free Software Definition was published. The Open Source Definition recognized copyleft licenses in its very first drafts too.
What you're thinking about is the fact that the "Open Source Movement" (and its formalization in OSI) were created largely to decouple the FSF (really RMS specifically) from the broader movement and remove his status as a default evangelist. Whether this is a good or bad idea is a flame war for another day (and it's been had more times than needed over the past 15 years), but it has absolutely nothing to do with the content of the licenses.
What you're thinking about is the fact that the "Open Source Movement" (and its formalization in OSI) were created largely to decouple the FSF (really RMS specifically) from the broader movement and remove his status as a default evangelist. Whether this is a good or bad idea is a flame war for another day (and it's been had more times than needed over the past 15 years), but it has absolutely nothing to do with the content of the licenses.
I did mean the tribal sense, yes. It's more likely that someone talking about free software is a proponent of copyleft, and someone talking about open source software is a proponent of permissive licensing. Then again, there is open source code out there that is not free (in the RMS / FSF "four freedoms" sense) due to patents, tivoization, and the absence of a requirement that end users get access to modifications, e.g. you can run a website with open source software but I'm not guaranteed access to your changes.
That's a very misleading essay.
"It is that, whereas free software is always also open source, open source software does not necessarily have to be free software. That is, software can be open source without granting its users the additional freedoms that free software guarantees."
This is incorrect, and the example given was incorrect. The terms are identical in meaning. Open source was coined to be a trademark for free software.
"It is that, whereas free software is always also open source, open source software does not necessarily have to be free software. That is, software can be open source without granting its users the additional freedoms that free software guarantees."
This is incorrect, and the example given was incorrect. The terms are identical in meaning. Open source was coined to be a trademark for free software.
If I give you Tivoized BSD code, this is open source but not free software, at least since GPLv3.
First of all, creating a new free software license does not alter the freeness of any software/license. GPLv3 incompatibility does not make software non-free, otherwise Linux kernel would not be free anymore.
Second, the Tivoised BSD code is free software. The fact that a piece of hardware exists that refuses to run a modified version of some BSD licensed code, does not make the code non-free.
Second, the Tivoised BSD code is free software. The fact that a piece of hardware exists that refuses to run a modified version of some BSD licensed code, does not make the code non-free.
Well, I'm going to take the FSF as the authority on what freedom means with respect to software, since it's their term. They clearly view GPLv2 code as less free than GPLv3.
https://www.gnu.org/licenses/rms-why-gplv3.html
Quoting the relevant bits about tivoization:
> The manufacturers of these computers take advantage of the freedom that free software provides, but they don't let you do likewise... Freedom means you control what your software does, not merely that you can beg or threaten someone else who decides for you.
https://www.gnu.org/licenses/rms-why-gplv3.html
Quoting the relevant bits about tivoization:
> The manufacturers of these computers take advantage of the freedom that free software provides, but they don't let you do likewise... Freedom means you control what your software does, not merely that you can beg or threaten someone else who decides for you.
I don't think this thread is worth continuing.
- GPLv2 is free software https://www.gnu.org/licenses/license-list.html#GPLv2
- If I take the Linux kernel 3.10.6 and create a piece of hardware that refuses to boot up any other version, Linux kernel 3.10.6 is still free software.
- GPLv2 is free software https://www.gnu.org/licenses/license-list.html#GPLv2
- If I take the Linux kernel 3.10.6 and create a piece of hardware that refuses to boot up any other version, Linux kernel 3.10.6 is still free software.
The FSF defines freedom in terms of the four freedoms: use, modify, copy, distribute. When people started abusing the GPLv2 in ways they didn't think about, they came out with the GPLv3 to protect these freedoms.
I think your argument is really with the FSF. There was no shortage of drama when Linus refused to upgrade the Linux license to GPLv3.
Tivoization removes the freedom to modify your software (and still have it run). Again, quoting the FSF about tivoization:
https://www.gnu.org/philosophy/free-sw.html
> Freedom 1 includes the freedom to use your changed version in place of the original. If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours — a practice known as “tivoization” or “lockdown”, or (in its practitioners' perverse terminology) as “secure boot” — freedom 1 becomes a theoretical fiction rather than a practical freedom. This is not sufficient. In other words, these binaries are not free software even if the source code they are compiled from is free.
I don't know what else to say. The FSF writes, "these binaries are not free software". They're referring to Tivoized Linux binaries. They get to make up the rules here. That includes changing their mind about freedom such that something that was formerly totally free is now less free.
FWIW, I'm not advocating for or against GPL software.
I think your argument is really with the FSF. There was no shortage of drama when Linus refused to upgrade the Linux license to GPLv3.
Tivoization removes the freedom to modify your software (and still have it run). Again, quoting the FSF about tivoization:
https://www.gnu.org/philosophy/free-sw.html
> Freedom 1 includes the freedom to use your changed version in place of the original. If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours — a practice known as “tivoization” or “lockdown”, or (in its practitioners' perverse terminology) as “secure boot” — freedom 1 becomes a theoretical fiction rather than a practical freedom. This is not sufficient. In other words, these binaries are not free software even if the source code they are compiled from is free.
I don't know what else to say. The FSF writes, "these binaries are not free software". They're referring to Tivoized Linux binaries. They get to make up the rules here. That includes changing their mind about freedom such that something that was formerly totally free is now less free.
FWIW, I'm not advocating for or against GPL software.
> Well, I'm going to take the FSF as the authority on what freedom means with respect to software, since it's their term.
No, it's not "their" term. They didn't invent and trademark term "Free". People were always using this word in context of software to mean that something is free of charge, and that is still the major usage of the term if you go asking users of the actual software.
I don't care about FSF at all, but it bothers me when people assume that "free" could only possibly mean "Free (tm) (c) FSF". The term existed long before FSF with completely different meaning, which is still retained by >90% of the users.
It's only the developers (and lawyers) that argue whether GPL, BSD, MIT or any other software is "free", free or not free. The users call it free if they can use it without paying for it, and that's all that matters to them.
</rant>
No, it's not "their" term. They didn't invent and trademark term "Free". People were always using this word in context of software to mean that something is free of charge, and that is still the major usage of the term if you go asking users of the actual software.
I don't care about FSF at all, but it bothers me when people assume that "free" could only possibly mean "Free (tm) (c) FSF". The term existed long before FSF with completely different meaning, which is still retained by >90% of the users.
It's only the developers (and lawyers) that argue whether GPL, BSD, MIT or any other software is "free", free or not free. The users call it free if they can use it without paying for it, and that's all that matters to them.
</rant>
We have two perfectly fine terms 'free software' and 'freeware' to denote programs that are distributed under a license compatible with the ideals of the free software movement and for software that's distributed free of charge.
Of course the free software movement doesn't own the term 'free', but context matters.
Of course the free software movement doesn't own the term 'free', but context matters.
Just fyi, the Linux kernel is under GPLv2, not GPLv3, afaik.
This is a licensing debate, but please don't conflate that with a divide between "Free Software" and "Open Source".
Personally I'd call it a divide between "Free" Software and Free Software. The GPL's style of bringing freedom to the world reminds me of Operation Iraqi Freedom...
Personally I'd call it a divide between "Free" Software and Free Software. The GPL's style of bringing freedom to the world reminds me of Operation Iraqi Freedom...
Well the GPL technique is used elsewhere, in far more places that OIF...
For instance, there are laws constraining doctors from releasing sensitive medical information about persons for the greater good of society at large (since people should therefore not have to worry about their doctor leaking news of their embarrassing disease they are being treated for).
Something as simple as everyone paying taxes to provide for things such as air quality testing so we don't end up like Beijing are another example, along with mandating carbon controls so that we can at least try to arrest runaway greenhouse effect that would cause global warming down the road.
Sometimes long-term freedom does require constraint on permissible action. Sometimes it doesn't. But it's not sporting to compare someone who tries the former route to invading a country IMHO, even if you personally feel the latter is better.
For instance, there are laws constraining doctors from releasing sensitive medical information about persons for the greater good of society at large (since people should therefore not have to worry about their doctor leaking news of their embarrassing disease they are being treated for).
Something as simple as everyone paying taxes to provide for things such as air quality testing so we don't end up like Beijing are another example, along with mandating carbon controls so that we can at least try to arrest runaway greenhouse effect that would cause global warming down the road.
Sometimes long-term freedom does require constraint on permissible action. Sometimes it doesn't. But it's not sporting to compare someone who tries the former route to invading a country IMHO, even if you personally feel the latter is better.
> Sometimes long-term freedom does require constraint on permissible action.
mpyne nailed it. If anyone is looking for further discussion of this concept check out "Social Contract Theory."[1][2]
[1] https://en.wikipedia.org/wiki/Social_contract
[2] http://www.iep.utm.edu/soc-cont/
Sidebar: It doesn't hurt that you get to say cheeky things like "Before the GPL life was nasty, brutish and short."
mpyne nailed it. If anyone is looking for further discussion of this concept check out "Social Contract Theory."[1][2]
[1] https://en.wikipedia.org/wiki/Social_contract
[2] http://www.iep.utm.edu/soc-cont/
Sidebar: It doesn't hurt that you get to say cheeky things like "Before the GPL life was nasty, brutish and short."
Before the GPL life was nasty, brutish and short.
... never mind that GNU was around for 6 years, and BSD was around for 12 years before the GPL was published.
... never mind that GNU was around for 6 years, and BSD was around for 12 years before the GPL was published.
BSD was around, but the BSD license was directly inspired by the GPL. Prior to the Net/2 release, and the AT&T lawsuit, running BSD required paying multi-kilobuck prices for a UNIX source license.
>the BSD license was directly inspired by the GPL.
The BSD license clearly derives from the MIT X license (1985 at the latest) rather than the GPL.
Berkeley's code in 4.3-Tahoe (1998) used the BSD license (with slightly different formatting).
The BSD license clearly derives from the MIT X license (1985 at the latest) rather than the GPL.
Berkeley's code in 4.3-Tahoe (1998) used the BSD license (with slightly different formatting).
running BSD required paying multi-kilobuck prices for a UNIX source license.
How is that relevant? Running linux requires paying multi-dollar prices to buy a computer; does that make the software any less free?
How is that relevant? Running linux requires paying multi-dollar prices to buy a computer; does that make the software any less free?
Just to be clear, the BSD license did not exist previous to net/2 it was not open source or free software in any meaningful way.
Well, you can sell GPL'd software today for "multi kilobuck" prices too, if you wish, without affecting how Free the end product is.
I am not trying to be difficult; but I do not understand what your point is? Yes, things happened prior to the social contract. That experience is the whole point of contracting out of the state of nature.
Maybe I misunderstood. Were you intending to imply that 12 or more years of freely licensed software constitutes "nasty, brutish, and short"?
You misunderstood, but no worries. If you missed the reference I imagine many others did as well. "Nasty, brutish and short" is the Hobbes quote about the state of nature. Here is a little teaser from WP:
Thomas Hobbes famously said that in a "state of nature" human life would be "solitary, poor, nasty, brutish, and short". In the absence of political order and law, everyone would have unlimited natural freedoms, including the "right to all things" and thus the freedom to plunder, rape, and murder; there would be an endless "war of all against all" (bellum omnium contra omnes). To avoid this, free men contract with each other to establish political community i.e. civil society through a social contract in which they all gain security in return for subjecting themselves to an absolute Sovereign, preferably (for Hobbes) a monarch. [1]
Hobbes/Locke/Rousseau's social contract is similar to mpyne's "Sometimes long-term freedom does require constraint on permissible action."[2]
[1] https://en.wikipedia.org/wiki/Social_contract#Overview
[2] At least in my reading of his comment, it is entirely possible that he thinks I am a crackpot and completely missing the point.
Thomas Hobbes famously said that in a "state of nature" human life would be "solitary, poor, nasty, brutish, and short". In the absence of political order and law, everyone would have unlimited natural freedoms, including the "right to all things" and thus the freedom to plunder, rape, and murder; there would be an endless "war of all against all" (bellum omnium contra omnes). To avoid this, free men contract with each other to establish political community i.e. civil society through a social contract in which they all gain security in return for subjecting themselves to an absolute Sovereign, preferably (for Hobbes) a monarch. [1]
Hobbes/Locke/Rousseau's social contract is similar to mpyne's "Sometimes long-term freedom does require constraint on permissible action."[2]
[1] https://en.wikipedia.org/wiki/Social_contract#Overview
[2] At least in my reading of his comment, it is entirely possible that he thinks I am a crackpot and completely missing the point.
No, you're pretty much right on point.
Sometimes I like to think of it as the problem with local minima/maxima preventing an optimization algorithm from achieving the global minima/maxima, except applied at large.
Put in the context of computer software licenses, one should simply imagine a world where all software were BSD-licensed and then see if open-source as we know it could feasibly continue. Certainly it would in some areas, but eventually if a given open-source project were consistently out-competing a proprietary product, the business being disadvantaged could fork the whole thing at once and turbocharge its now-proprietary development for long enough to supplant the old, open version.
Witness what Nokia did with Qt. They poured tons of money into it and turned it in a short time into a mobile-class toolkit that was even more the "Best of Breed". They had so much resource investment that they were able to relicense the whole thing from GPL/QPL to LGPL/QPL. That particular case has turned out alright, but it should be illustrative of the danger of a world with a weak F/OSS ecosystem.
Given all the problems we still have with software patents and other IP shenanigans I simply can't rest on the idea that the mere technical superiority of development "in the open" must necessarily and inevitably lead to a world where software is open and available to the users who would need it, without the judicious use of copyleft licenses in the mix along with BSD/MIT-style licenses. They both have their place.
Sometimes I like to think of it as the problem with local minima/maxima preventing an optimization algorithm from achieving the global minima/maxima, except applied at large.
Put in the context of computer software licenses, one should simply imagine a world where all software were BSD-licensed and then see if open-source as we know it could feasibly continue. Certainly it would in some areas, but eventually if a given open-source project were consistently out-competing a proprietary product, the business being disadvantaged could fork the whole thing at once and turbocharge its now-proprietary development for long enough to supplant the old, open version.
Witness what Nokia did with Qt. They poured tons of money into it and turned it in a short time into a mobile-class toolkit that was even more the "Best of Breed". They had so much resource investment that they were able to relicense the whole thing from GPL/QPL to LGPL/QPL. That particular case has turned out alright, but it should be illustrative of the danger of a world with a weak F/OSS ecosystem.
Given all the problems we still have with software patents and other IP shenanigans I simply can't rest on the idea that the mere technical superiority of development "in the open" must necessarily and inevitably lead to a world where software is open and available to the users who would need it, without the judicious use of copyleft licenses in the mix along with BSD/MIT-style licenses. They both have their place.
I caught the Hobbes reference, I just can't see any sane reason for applying it to the GPL.
I can't see any sane reason how anyone can possible miss the connection. GPL provides a social contract that say: If you give away software and tell people that they are free to distribute copies, you can't come back a few days later and sue all their friends for patent infringement. You told him that he could give copies freely to his friend, and by suing, you are stabbing him in the back. This is behavior, even if it might infringe on developers "unlimited natural freedoms" of stabbing people in the back.
I agree with the policies you mention, and I'd say that they serve the greater good of society. I would not, however, try to claim that they are "freedom policies" -- to the contrary, I'd say they're examples of how our quality of life can be enhanced by giving up some freedoms.
The notion of "freedom" is complex and context sensitive. Some people (whom I largely disagree with, as I think this usage of terminology is itself context sensitive; it is, however, useful as a first approximation to get the ball rolling) look at the difference between "freedom to" and "freedom from"; by taking away my "freedom" to own other people, chaining them and forcing them to work for me by force, other people obtain the freedom from being slaves, and now have the freedom to run their own lives. The "freedoms" being looked at here are simply being given to different people: the GPL restricts freedoms of developers working with th software to provide and guarantee freedoms among the end users f that software; on the opposite side, BSD-licensed software tends to give developers more freedom, but the freedoms they are given are specifically for and really narrowly able to be used with the one purpose of later restricting freedoms of others. The question, thereby, comes down to which freedoms are more important and how many of each kind of consumer there are, in an attempt to define which philosophy provides more freedom. Advocates of GPL would say that there will always be more end users than developers, and that their freedoms are porbably more important anyway, so the GPL provides more essential "freedom", even as it is actively defined in a way that "restricts freedom", in the same way as we usually like to think the emancipation proclamation brought "freedom" even though it really was stating that slave owners had to give up some freedom: its all about perspective.
The tradeoff you are suggesting in this case is not valid. BSD-licensed software does not become any less free the moment someone uses it in a non-free project. It is only the changes to the code by the non-free project that are non-free, but none of the original code is affected.
Whether those changes would have been made free if the original code was GPL-licensed is highly debatable, and there are plenty of examples on both sides. Notably, there was more or less no way MacOSX would have been built on GPL code. Conversely, many router projects have been forced to release source code due to being based on GPL-licensed Linux code.
Whether those changes would have been made free if the original code was GPL-licensed is highly debatable, and there are plenty of examples on both sides. Notably, there was more or less no way MacOSX would have been built on GPL code. Conversely, many router projects have been forced to release source code due to being based on GPL-licensed Linux code.
No: the source code being available does not provide freedom to the user if one cannot replace the code being used with a differently-modified copy. To the user, it does not matter in the slightest that the full and complete source code for something is available if they cannot use that source code to affect the binary versions of the code they am working with by changing and recompiling the code. What the various versions of GPL provide is that freedom as it applies to binaries, and thereby when people care too much about source code my contention is that they are a developer, not a user.
When a library is under BSD, for example, and is compiled into a program statically, it does not matter at all whether the developer using it was kind enough to provide the source code to all of their modifications: from the perspective of the user of the binary the freedom to change the software they are using has been lost, even if they are a developer. This is what the LGPL guarantees: not directly that the source code is available (though it does), but that any binary distribution that uses the library also provides the means required to replace the binary of the code with a modified version based on the source.
Moving to the full GPL, what is gained is the "viral" guarantee that this ability to get the source of a binary is maintained as people attempt to use the benefits of the licensed work in a larger binary. The license, philosophically and legally, is not about a property of the source code: it is a property of the binary being distributed; the result is that people who rely on the works of others in their binaries have to make the entire binary open and modifiable to end users. That's what makes GPL so interesting: it is a license about binaries and what the rules are surrounding how people can modify those binaries, and is only tangentially related to source code as the means by which these binaries will be modified.
Of course, as TiVo taught mainstream, there is a loophole: you can comply with GPL2 fully and yet users are able to lose these guaranteed freedoms if the binary software is verified by some kind of hardware lock: Android being open source is academically interesting, but provides no value to the owner of a device with a locked bootloader; GPL2 required the binaries to relate to source code in ways that failed to take into account cryptographic verification by unmodifiable firmware. This is why the GPL3 exists: to provide this freedom of modification to the binaries sitting on my hardware devices, and effectively moves the freedoms being guaranteed from the "binaries" all the way to the product itself.
When a library is under BSD, for example, and is compiled into a program statically, it does not matter at all whether the developer using it was kind enough to provide the source code to all of their modifications: from the perspective of the user of the binary the freedom to change the software they are using has been lost, even if they are a developer. This is what the LGPL guarantees: not directly that the source code is available (though it does), but that any binary distribution that uses the library also provides the means required to replace the binary of the code with a modified version based on the source.
Moving to the full GPL, what is gained is the "viral" guarantee that this ability to get the source of a binary is maintained as people attempt to use the benefits of the licensed work in a larger binary. The license, philosophically and legally, is not about a property of the source code: it is a property of the binary being distributed; the result is that people who rely on the works of others in their binaries have to make the entire binary open and modifiable to end users. That's what makes GPL so interesting: it is a license about binaries and what the rules are surrounding how people can modify those binaries, and is only tangentially related to source code as the means by which these binaries will be modified.
Of course, as TiVo taught mainstream, there is a loophole: you can comply with GPL2 fully and yet users are able to lose these guaranteed freedoms if the binary software is verified by some kind of hardware lock: Android being open source is academically interesting, but provides no value to the owner of a device with a locked bootloader; GPL2 required the binaries to relate to source code in ways that failed to take into account cryptographic verification by unmodifiable firmware. This is why the GPL3 exists: to provide this freedom of modification to the binaries sitting on my hardware devices, and effectively moves the freedoms being guaranteed from the "binaries" all the way to the product itself.
What happens with forks of the code is not relevant. The original code and the original project continue to exist, and so would the community around it. There's no reason why they would abandon the existing, BSD-licensed project for the new proprietary one. The existence of the new project doesn't have any direct adverse effect on the original one.
At the same time, users of the fork still benefit from the original code that exists in the new project, as there is no need to rewrite it. That effort can then be made to make the new project better. There may not be as much of a benefit as there would be if the fork was also open source, but there's clearly still some benefit if users find it useful enough to use it.
Now, an argument can be made that the ability to fork the code may prevent people from contributing to the original project. In practice, maintaining the diffs for any reasonably active project is a lot of work, and it makes sense to contribute as many changes back as possible, leaving out only the 'secret sauce' bits, just to reduce the amount of work necessary to maintain the fork. Those proprietary bits might have made it into the original project if it were using a copyleft license, but they also might not have been made at all.
At the same time, users of the fork still benefit from the original code that exists in the new project, as there is no need to rewrite it. That effort can then be made to make the new project better. There may not be as much of a benefit as there would be if the fork was also open source, but there's clearly still some benefit if users find it useful enough to use it.
Now, an argument can be made that the ability to fork the code may prevent people from contributing to the original project. In practice, maintaining the diffs for any reasonably active project is a lot of work, and it makes sense to contribute as many changes back as possible, leaving out only the 'secret sauce' bits, just to reduce the amount of work necessary to maintain the fork. Those proprietary bits might have made it into the original project if it were using a copyleft license, but they also might not have been made at all.
You continue to be looking at this from the perspective of a developer: the user was given a binary and wants to be able to edit the binary; the practical way to edit the binary is to get the source code for it, modify it, recompile it, and replace the binary... the BSD license model does not guarantee that this is possible, so the user does not have the freedom to modify the actual program they are using: sure they might have the source code (and I think, for sake of this argument, it is most interesting to assume a totally benevolent developer who does provide all of the source code for every open source project they work with, as that neatly and totally destroys any attempt to argue about source code), but it is now likely statically linked with a bunch of stuff that they don't have the code for (or worse, is running on a hardware device with cryptographic signatures) and so their modified build is useless.
To the user of this binary, your arguments about potential benefits to an upstream open source project are thereby off-topic (especially if the source code is fully available and no one is hiding any modifications) and your discussion of "forks" is downright nonsensical: given 100% of the source code of the software running on a TiVo, you still have no freedom at all to actually modify that software. The system is "open" in some weird, mostly academic fashion, in that you can easily find out how it works, and maybe you could even build a TiVo competitor based on it, but to the owner of a TiVo--an actual user of the distributed binaries--the source code is worthless. The GPL's purpose is to guarantee that a user of a binary will always have the freedom to change the functionality of that binary in the context of their use.
This is a fundamental freedom of the user that requires the developer to give up some freedoms with regards to how they deploy their binaries and has nothing to do with projects and forks or even source code in any direct way. This is a trade off related to a subjective understanding of "freedom" as it applies to different actors in the system, and so to understand why the GPL is interesting you have to be willing to temporarily take off the hat of a project maintainer and put on the hat of a user, as the GPL's purpose (and yes, this is somewhat sadly ironic) is to protect the rights of a different player in the ecosystem than the maintainer whose job it is to choose a license for their project.
To the user of this binary, your arguments about potential benefits to an upstream open source project are thereby off-topic (especially if the source code is fully available and no one is hiding any modifications) and your discussion of "forks" is downright nonsensical: given 100% of the source code of the software running on a TiVo, you still have no freedom at all to actually modify that software. The system is "open" in some weird, mostly academic fashion, in that you can easily find out how it works, and maybe you could even build a TiVo competitor based on it, but to the owner of a TiVo--an actual user of the distributed binaries--the source code is worthless. The GPL's purpose is to guarantee that a user of a binary will always have the freedom to change the functionality of that binary in the context of their use.
This is a fundamental freedom of the user that requires the developer to give up some freedoms with regards to how they deploy their binaries and has nothing to do with projects and forks or even source code in any direct way. This is a trade off related to a subjective understanding of "freedom" as it applies to different actors in the system, and so to understand why the GPL is interesting you have to be willing to temporarily take off the hat of a project maintainer and put on the hat of a user, as the GPL's purpose (and yes, this is somewhat sadly ironic) is to protect the rights of a different player in the ecosystem than the maintainer whose job it is to choose a license for their project.
You continue to underestimate the importance of the original work as a product, and overestimate the importance of the license of the original work.
The GPL doesn't guarantee that a potential derivative work would be open source. The developer that might have based their work on open source might choose not to use the code of the original work in their project so as to avoid having to make their own work open source as well. This is a loss to the world, as the quality of their work would most likely not be as good, either because the code wouldn't be community reviewed or simply because time was spent writing code with functionality that already exists as open source taking away time from other features.
GPL or BSD, somewhere along the line, the developer has to willingly make their work open source. The only case the GPL can force someone to make their work open source is if someone has used GPL code with the intention of violating the license, but are later exposed to have used GPL code and are shamed into open sourcing it.
At the end of the day, the user only has freedoms to the code that the developer chooses to grant. Whether this is by choosing to use GPL code in their project and making it GPL as well, using BSD code in their project and making it BSD as well, or not using GPL code (but possibly BSD code) and not making their work open source.
The GPL doesn't guarantee that a potential derivative work would be open source. The developer that might have based their work on open source might choose not to use the code of the original work in their project so as to avoid having to make their own work open source as well. This is a loss to the world, as the quality of their work would most likely not be as good, either because the code wouldn't be community reviewed or simply because time was spent writing code with functionality that already exists as open source taking away time from other features.
GPL or BSD, somewhere along the line, the developer has to willingly make their work open source. The only case the GPL can force someone to make their work open source is if someone has used GPL code with the intention of violating the license, but are later exposed to have used GPL code and are shamed into open sourcing it.
At the end of the day, the user only has freedoms to the code that the developer chooses to grant. Whether this is by choosing to use GPL code in their project and making it GPL as well, using BSD code in their project and making it BSD as well, or not using GPL code (but possibly BSD code) and not making their work open source.
The concern is not that the old software magically loses its freedom, but that tomorrow's software will, as the software we develop simply gets adopted as the base for proprietary solutions that then strangle their still-"free" parents of that valuable development oxygen.
In that regard I think even GPL advocates would be quite happy to use your example about Darwin, at least as a cautionary tale (though perhaps there was more benefit for the BSD upstreams than I am aware of; we're still waiting for an open release of ARM Darwin...). Likewise Apple's adoption of KJS/KHTML didn't go as well for KDE as we had hoped.
In that regard I think even GPL advocates would be quite happy to use your example about Darwin, at least as a cautionary tale (though perhaps there was more benefit for the BSD upstreams than I am aware of; we're still waiting for an open release of ARM Darwin...). Likewise Apple's adoption of KJS/KHTML didn't go as well for KDE as we had hoped.
That is a ridiculous comparison.
that's a disgusting and misleading comparison, you should be ashamed. developers decide on using the gpl by their own choice. also, the gpl protects the user's freedom which in my opinion is one of the most important things in software land. it is no wonder that apple disagrees.
> Both terms encompass both copyleft and non-copyleft (all-permissive) licensing.
Then what's the difference between the two terms?
I've always thought that they were quite different (RMS vs ESR). Especially when capitalized as pronouns.
Edit: Nevermind. I missed ajross's response.
Then what's the difference between the two terms?
I've always thought that they were quite different (RMS vs ESR). Especially when capitalized as pronouns.
Edit: Nevermind. I missed ajross's response.
There are two answers to that.
The more relevant one for the current discussion: people who use and identify with the term "Free Software" generally care about software freedom as a valuable principle independent of its practical benefits (in other words, software should be free because it's wrong to restrict developers' ability to use, copy, modify, and distribute it), while people who use and identify with the term "Open Source" generally care most about the practical benefits (software should be open because that's the most effective and efficient way to produce software). There's a great deal of overlap between those two communities, but in general those two terms imply a different set of underlying principles held by the speaker. People who want to be all-inclusive sometimes say "Free and Open Source Software" or FOSS.
The origins of that distinction come from the original creation of the term "Open Source", often described as a marketing campaign for Free Software: the term often helps win over people (and businesses) who are unconvinced by software freedom as a principle but highly convinced by the effectiveness of Open Source as a software development model.
In terms of literal definition, Free Software is defined by the Free Software Foundation's "four freedoms" (https://www.gnu.org/philosophy/free-sw.html): use/run, study/modify, redistribute, and redistribute modified versions. Open Source is defined by the Open Source Initiative's Open Source Definition (http://opensource.org/osd), which in turn was derived from the Debian project's "Debian Free Software Guidelines" (DFSG, http://www.debian.org/social_contract). In practice, almost every license that passes one definition passes the other; it's exceedingly rare to find a license that's actually Open Source but not Free Software or vice versa.
Also worth noting: both terms are unfortunately ambiguous, in that "free software" (especially when not capitalized) can be confused with software available for no fee, and "open source" can be confused with software with source available but not under an Open Source license.
The more relevant one for the current discussion: people who use and identify with the term "Free Software" generally care about software freedom as a valuable principle independent of its practical benefits (in other words, software should be free because it's wrong to restrict developers' ability to use, copy, modify, and distribute it), while people who use and identify with the term "Open Source" generally care most about the practical benefits (software should be open because that's the most effective and efficient way to produce software). There's a great deal of overlap between those two communities, but in general those two terms imply a different set of underlying principles held by the speaker. People who want to be all-inclusive sometimes say "Free and Open Source Software" or FOSS.
The origins of that distinction come from the original creation of the term "Open Source", often described as a marketing campaign for Free Software: the term often helps win over people (and businesses) who are unconvinced by software freedom as a principle but highly convinced by the effectiveness of Open Source as a software development model.
In terms of literal definition, Free Software is defined by the Free Software Foundation's "four freedoms" (https://www.gnu.org/philosophy/free-sw.html): use/run, study/modify, redistribute, and redistribute modified versions. Open Source is defined by the Open Source Initiative's Open Source Definition (http://opensource.org/osd), which in turn was derived from the Debian project's "Debian Free Software Guidelines" (DFSG, http://www.debian.org/social_contract). In practice, almost every license that passes one definition passes the other; it's exceedingly rare to find a license that's actually Open Source but not Free Software or vice versa.
Also worth noting: both terms are unfortunately ambiguous, in that "free software" (especially when not capitalized) can be confused with software available for no fee, and "open source" can be confused with software with source available but not under an Open Source license.
I would refine your argument a little. The Free Software movement does not maintain that "software should be free because it's wrong to restrict developers' ability to use, copy, modify, and distribute it". It maintains that 'software should be free because it's wrong to restrict users' ability to use, copy, modify and distribute it'.
There is a subtle distinction. Open Source is generally in favour of developers' freedom, Free Software is generally in favour of users' freedom. These come into conflict when, for example, developers want to lock their users into SaaS walled gardens. Open Source advocates are generally in favour of the developers' freedom to do this. Free Software advocates are generally in favour of the users' freedom to not be locked in (see the AGPL for example).
There is a subtle distinction. Open Source is generally in favour of developers' freedom, Free Software is generally in favour of users' freedom. These come into conflict when, for example, developers want to lock their users into SaaS walled gardens. Open Source advocates are generally in favour of the developers' freedom to do this. Free Software advocates are generally in favour of the users' freedom to not be locked in (see the AGPL for example).
> Technical differences are ephemeral.
Hardly the case when you want to extend/embed your compiler frontend/backend. In this case, LLVM/Clang shine. They are written in fairly clean and comprehensible C++ libraries. Most CLI tools are well under 1k lines! GCC is a real pain to even comprehend, let alone extend/embed!
Hardly the case when you want to extend/embed your compiler frontend/backend. In this case, LLVM/Clang shine. They are written in fairly clean and comprehensible C++ libraries. Most CLI tools are well under 1k lines! GCC is a real pain to even comprehend, let alone extend/embed!
Clang only support a subset of the features that GCC has, so it is naturally easier to comprehend. Reading the user manual, more "tricky" GCC extensions is intentionally not implemented because they would be too hard to implement.
If you think this is good/bad for Clang/GCC, depend if you ever used said features, or if one prefer a smaller compiler which has less features.
If you think this is good/bad for Clang/GCC, depend if you ever used said features, or if one prefer a smaller compiler which has less features.
As I remember, at the time Apple started Clang, GCC wasn't nearly as clean. The various stages (parsing, compiling, optimization, etc) were not cleanly separated/documented so using the compiler's parser for syntax highlighting wasn't really possible. GCC has improved quite a bit since Clang/LLVM showed up in many of these areas.
Even if GCC had very clean separation between the steps, the FSF's interpretation is that you couldn't use the GCC parser for something like highlighting/suggestions the way Apple does in XCode without making all of XCode GPL.
It's a perfectly fair interpretation. I think making the opposite case would be quite difficult. But it shouldn't be surprising that Apple wouldn't want to open up all of XCode. I also don't blame Apple for not wanting to continue to re-implement parts of GCC and try to stay bug-for-bug on parsing when the only reason you can't re-use the same code is licensing.
Even if GCC had very clean separation between the steps, the FSF's interpretation is that you couldn't use the GCC parser for something like highlighting/suggestions the way Apple does in XCode without making all of XCode GPL.
It's a perfectly fair interpretation. I think making the opposite case would be quite difficult. But it shouldn't be surprising that Apple wouldn't want to open up all of XCode. I also don't blame Apple for not wanting to continue to re-implement parts of GCC and try to stay bug-for-bug on parsing when the only reason you can't re-use the same code is licensing.
> Even if GCC had very clean separation between the steps, the FSF's interpretation is that you couldn't use the GCC parser for something like highlighting/suggestions the way Apple does in XCode without making all of XCode GPL.
Only in this one technical implementation you've imagined. Interacting with GPLd tools via basically any method expect actually linking it into your code (e.g. pipes) doesn't infect your code with GPL obligations. Presumably just piping the entire code to gcc -fdump-tree-original every keystroke would be too slow but you could probably get it working nicely if you had the sort of engineer time Apple do.
Only in this one technical implementation you've imagined. Interacting with GPLd tools via basically any method expect actually linking it into your code (e.g. pipes) doesn't infect your code with GPL obligations. Presumably just piping the entire code to gcc -fdump-tree-original every keystroke would be too slow but you could probably get it working nicely if you had the sort of engineer time Apple do.
It's not really more/less features so much as it is a tradeoff. LLVM is extremely powerful in that it lets you write front-ends for many different languages without worrying about the complexities of native code gen. Likewise, it lets you write backends for other target platforms (i.e. JavaScript), allowing you to gain the ability to port those languages to new platforms easily. Thirdly, you can write optimizers for LLVM's intermediate representation and gain the benefit across most/all front-end languages and back-end platforms.
GCC, on the other hand, seems to have a much narrower focus but with a lot more optimizations and weird extensions.
GCC, on the other hand, seems to have a much narrower focus but with a lot more optimizations and weird extensions.
This is exactly GCC's architecture as well, where front-ends are transpiled into a generic language, which is then compiled into native code for a given platform.
That's how GCC works internally, but neither the front-ends nor the back-ends are available to use individually. Indeed, RMS specifically avoided having a flexible architecture similar to llvm, because he was afraid such flexibility would be used for non-GPL "plugins".
GCC supports external dynamically loaded plugins since 4.5.0 (3 years ago)
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
The wiki has links to some plugins too http://gcc.gnu.org/wiki/plugins
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
The wiki has links to some plugins too http://gcc.gnu.org/wiki/plugins
Sure, but what about the inverse? With LLVM you can use frontends as libraries for integrating into an (possibly non-free) IDE for completion, syntax highlighting, refactoring etc. This is especially powerful because you can avoid serialization and just keep the ASTs in memory. I'm not aware of this being possible with GCC, but I could be wrong.
If you can dump or generate the IR you can use the front or back ends as you please, no? You might have to write something that reads in the IR.
Thats a lot of work for what you get out of the box with clang. There is a whole community of tooling around llvm for these types of use case, so why use gcc?
Sure, I was just arguing possibility, not feasibility.
I'm not sure the bigger number of nonstandard and noncompliant extensions is really a desirable attribute when comparing the merits of C compilers.
This might change though, now that GCC has some stiff open source competition.
I heard GCC is partly a bit of a hairball to prevent GPL loopholes. They wanted to ensure you can't wrap it in some kind of RPC framework to get around the GNU GPL. They might clean things up a bit, if there's no longer an incentive for people to want to effectively steal it (since they can just use Clang instead).
In fact, open source projects (even GLP ones) might start switching to Clang, if it has a cleaner API.
So the costs of a hairy API are going to start outweighing the benefits.
I heard GCC is partly a bit of a hairball to prevent GPL loopholes. They wanted to ensure you can't wrap it in some kind of RPC framework to get around the GNU GPL. They might clean things up a bit, if there's no longer an incentive for people to want to effectively steal it (since they can just use Clang instead).
In fact, open source projects (even GLP ones) might start switching to Clang, if it has a cleaner API.
So the costs of a hairy API are going to start outweighing the benefits.
(Right. I think we are in agreement, but to be very clear for others who might only read these comments: the accepted answer is from where I quoted the "most notable" technical benefit.)
> clang's website attempts to demonstrate the superiority of clang by comparing against the error messages from gcc 4.2
Even if it that doesn't hold true anymore, I think it's valid to highlight since it's one of the motivations, probably one of the original creators' pain points with GCC.
The website reads:
Even if it that doesn't hold true anymore, I think it's valid to highlight since it's one of the motivations, probably one of the original creators' pain points with GCC.
The website reads:
Some of the goals for the project include the following:
End-User Features:
- Expressive diagnostics (examples)Clang is targeting specific market - free and non-GPLv3 compiler (with OBJC support).
The sales catchphrase superior error message is still true for the people in the market. And comparison with compiler in GPLv3 is meaningless to them.
You're just out of target.
The sales catchphrase superior error message is still true for the people in the market. And comparison with compiler in GPLv3 is meaningless to them.
You're just out of target.
> clang's website attempts to demonstrate the superiority of clang by comparing against the error messages from gcc 4.2, a version of gcc that wasn't even the most current when that comparison was published.
This is the latest version available by default on MacOS and FreeBSD (for licensing reasons; subsequent versions are GPLv3), the two operating systems where clang sees most use.
This is the latest version available by default on MacOS and FreeBSD (for licensing reasons; subsequent versions are GPLv3), the two operating systems where clang sees most use.
At which point you may as well just point out "clang is maintained; unlike gcc 4.2, which at best will only receive back-ported compilation and security fixes, clang is under active development" ;P. You don't even need to motivate "better": it just needs to be "all least sort of as good". In the end, the only legit reason for this change is licensing, and any references to technical superiority between clang and gcc as a whole are red herrings at best and disingenuous at worst.
Apple certainly has technical reasons for using clang; good luck getting the degree of integration XCode has with clang with GCC (the plugin system added as a response to clang existing would help, but would not be sufficient in itself). BSD has less clear ones, though I would hope that other C/C++ IDEs will start adding similar levels of integration.
Ultimately, clang offers a way forward without having to adopt GPLv3 software, and besides that offers considerable benefit to people making development tools. Its big selling point has never really been speed; that it can generally keep up is enough.
EDIT: You could certainly also make the claim that Clang's far faster compilation is a technical feature, especially for C++ programmers. There are actually people who use clang for development, for the fast compilation and static analysis, then build for production with a newish GCC.
Ultimately, clang offers a way forward without having to adopt GPLv3 software, and besides that offers considerable benefit to people making development tools. Its big selling point has never really been speed; that it can generally keep up is enough.
EDIT: You could certainly also make the claim that Clang's far faster compilation is a technical feature, especially for C++ programmers. There are actually people who use clang for development, for the fast compilation and static analysis, then build for production with a newish GCC.
My comment complains about the error handling comparison and then makes assertions about the "only legit reason for this change" <- "this change", of course, being the one to FreeBSD. I am not quite certain how issues Apple runs into with Xcode are relevant (and talking about hypothetical future IDEs, which certainly would not be FreeBSD-specific and which would treat clang as any other library to depend on, doesn't make the motivation any more clear to me).
To address your second paragraphs, I am responding to a comment (yours) justifying why clang should spend time on their website making comparisons against gcc 4.2, a stance you defend by stating that that is the version that people are using instead of clang. Now, in your response to my defense against that point, you are bringing up legitimate technical benefits of clang against all versions of gcc...
...but I would never, nor have I so far in this thread, complained that those benefits didn't exist; I especially haven't claimed that those version-independent architecture benefits shouldn't be mentioned on their website. My complaint, remember, is that there are specific nebulous benefits (error output) being touted against gcc 4.2 as the "most notable" (according to the SO answer being discussed) technical be benefit of this project.
That specific benefit only exists because of a licensing decision, as gcc after-4.2 does not have error output this bad (not do I believe it did in 4.3 trunk at the time that website was published). The honest reason, if "error output" is important, as to why clang is better than gcc for FreeBSD is thereby "licensing", as if licensing weren't the real reason that benefit evaporates: it is no better than just pointing out that gcc 4.2 is unmaintained.
However, and again, you are more than welcome to be happy or excited about any other real benefits, either to other parties or the ones in question, but your comments in this context are anticipating complaints I haven't made and in fact is aggressively arguing with me over something I don't even disagree with: it is as if you see anyone complaining about clang and presume "they must just be a hater" and knee-jerk your way through a muscle-memory argument over "why clang is better" (something I have no strong opinion about).
To address your second paragraphs, I am responding to a comment (yours) justifying why clang should spend time on their website making comparisons against gcc 4.2, a stance you defend by stating that that is the version that people are using instead of clang. Now, in your response to my defense against that point, you are bringing up legitimate technical benefits of clang against all versions of gcc...
...but I would never, nor have I so far in this thread, complained that those benefits didn't exist; I especially haven't claimed that those version-independent architecture benefits shouldn't be mentioned on their website. My complaint, remember, is that there are specific nebulous benefits (error output) being touted against gcc 4.2 as the "most notable" (according to the SO answer being discussed) technical be benefit of this project.
That specific benefit only exists because of a licensing decision, as gcc after-4.2 does not have error output this bad (not do I believe it did in 4.3 trunk at the time that website was published). The honest reason, if "error output" is important, as to why clang is better than gcc for FreeBSD is thereby "licensing", as if licensing weren't the real reason that benefit evaporates: it is no better than just pointing out that gcc 4.2 is unmaintained.
However, and again, you are more than welcome to be happy or excited about any other real benefits, either to other parties or the ones in question, but your comments in this context are anticipating complaints I haven't made and in fact is aggressively arguing with me over something I don't even disagree with: it is as if you see anyone complaining about clang and presume "they must just be a hater" and knee-jerk your way through a muscle-memory argument over "why clang is better" (something I have no strong opinion about).
The real disappointment to me is that this decision was made over an irrational licensing issue instead of technical merits. If Clang was superior to GCC in the vast majority of benchmarks, then I would support this decision. But that’s not the case, GCC is still leading in many benchmarks and can be an order of magnitude faster when the commonly used OpenMP library is used.[1] BSD users are the losers here.
[1] http://www.phoronix.com/scan.php?page=article&item=llvm_33sv...
[1] http://www.phoronix.com/scan.php?page=article&item=llvm_33sv...
You could always submit a patch.
talks about the experience provided by the command line compiler, contrasting
-Clang output to GCC 4.2's output in several examples.
+Clang output to that of GCC 4.2 (current when the Clang project began)
+in several examples.
<!--gcc 4.2.1 was the last version to use GPLv2. Later versions switched to GPLv3, which the BSD guys couldn't swallow. From skimming the answer, I think it's pretty clear that the switch wasn't due to technical reasons, but that Clang/LLVM is now "good enough".
It seems reasonable for FreeBSD to favour BSD licensing.
It seems reasonable for FreeBSD to favour BSD licensing.
I am not exactly certain what you are disagreeing with from what I said (as I agree that the only legitimate reason is licensing), so I guess I'll justt point out that the answer you apparently only "skimmed" has a section on "technical benefits" that specifically listed a "most notable" example being improved error messages.
Yes, I read that bit. Your objection seemed to be about the comparison with an older version of gcc, and I was noting why that comparison was legitimate, for them.
EDIT Ah, I see how: you're talking about clang's website, whereas I'm talking about the submitted link, which is about FreeBSD. Note: the same argument also applies to other companies avoiding the GPLv3, which would explain why clang's website uses gcc 4.2 in its comparison. Though people here mentioned the GPLv3, no one noted that 4.2 was when the gcc license switched to it (I checked the HN comments).
FWIW I've seen a GPL project eventually lose out to a BSD-style competitor, and the latter were surprisingly nasty about it, similar to what you're saying. This might be due to commercial interests vigorously supporting the BSD-style version for reasons of MONEY. But apart from nastiness, it makes sense that a more permissive license, being free to a wider audience, will be more popular. OTOH perhaps here, for a compiler, requiring people to give back (GPL) will work better? OTOH2, promising new tech always gets a certain ersatz caché - whether that promise is fulfilled or not.
EDIT Ah, I see how: you're talking about clang's website, whereas I'm talking about the submitted link, which is about FreeBSD. Note: the same argument also applies to other companies avoiding the GPLv3, which would explain why clang's website uses gcc 4.2 in its comparison. Though people here mentioned the GPLv3, no one noted that 4.2 was when the gcc license switched to it (I checked the HN comments).
FWIW I've seen a GPL project eventually lose out to a BSD-style competitor, and the latter were surprisingly nasty about it, similar to what you're saying. This might be due to commercial interests vigorously supporting the BSD-style version for reasons of MONEY. But apart from nastiness, it makes sense that a more permissive license, being free to a wider audience, will be more popular. OTOH perhaps here, for a compiler, requiring people to give back (GPL) will work better? OTOH2, promising new tech always gets a certain ersatz caché - whether that promise is fulfilled or not.
The submitted link has a section on technical benefits to FreeBSD for making this switch which directly links to clang's website for what this submitted link's accepted answer considers the "most notable" technical benefit.
Well, I like the clang error messages better than gcc's, and I use recent versions. And to refer to the major architectural differences between the two as something that could be bridged by a single "patch" is a little silly.
gcc is still better at optimization, though. For now.
[edit: wow, people are really confused here. Guys, LLVM was designed from the start to have a clean separation between passes. You can compile some other language to the LLVM bytecode and then just use the code generator, for example. It even includes a JIT! In contrast, gcc is a huge monolith. The projects are written in different languages, too... C++ versus C.
tl;dr is that when you say that "the only difference is the license," you sound like someone saying "the only difference between Ruby and Java is the file extension." Pointy haired.]
gcc is still better at optimization, though. For now.
[edit: wow, people are really confused here. Guys, LLVM was designed from the start to have a clean separation between passes. You can compile some other language to the LLVM bytecode and then just use the code generator, for example. It even includes a JIT! In contrast, gcc is a huge monolith. The projects are written in different languages, too... C++ versus C.
tl;dr is that when you say that "the only difference is the license," you sound like someone saying "the only difference between Ruby and Java is the file extension." Pointy haired.]
gcc is in C++ for a while now.
gcc has been becoming more modular over previous releases, and is becoming more modular in the future. For example, there are plugins since 2010.
Your information is outdated, so it makes your opinion seem uninformed.
gcc has been becoming more modular over previous releases, and is becoming more modular in the future. For example, there are plugins since 2010.
Your information is outdated, so it makes your opinion seem uninformed.
Most of gcc is still written in C. Only a tiny amount of new code is in C++. In my opinion, that's the worst of both worlds-- inconsistent code, plus C++ overheads.
I work with some fairly recent version of both compilers-- gcc 4.7.2 and clang 3.2. I also know a developer on the LLVM team. clang is way ahead of gcc in many ways, and the gcc devs know it.
We still ship software built with gcc, rather than clang, because gcc is still better at optimization. (gcc also supports more obscure targets, though that's not our biggest concern).
We also make use of llvm's ability to dynamically recompile code on the fly in Cloudera Impala. More information here: http://blog.cloudera.com/blog/2013/02/inside-cloudera-impala...
This would not be possible with gcc no matter how much work we did (license issues-- Impala is Apache 2.0, gcc is GPLv3).
I work with some fairly recent version of both compilers-- gcc 4.7.2 and clang 3.2. I also know a developer on the LLVM team. clang is way ahead of gcc in many ways, and the gcc devs know it.
We still ship software built with gcc, rather than clang, because gcc is still better at optimization. (gcc also supports more obscure targets, though that's not our biggest concern).
We also make use of llvm's ability to dynamically recompile code on the fly in Cloudera Impala. More information here: http://blog.cloudera.com/blog/2013/02/inside-cloudera-impala...
This would not be possible with gcc no matter how much work we did (license issues-- Impala is Apache 2.0, gcc is GPLv3).
When a parse failure occurs, making an educated guess and continuing is not a "major architectural difference". (As for your edit, I now challenge you to tell us how these architecture passed and the JIT help FreeBSD's use cases. That said, my comment you are responding to just expresses bother about the "most notable" technical benefit listed by this SO answer, so I'm not even certain why you feel talking about other things is relevant.)
gcc, for the sake of wanting to make it hard to call it from proprietary front-ends, is architecturally tangled. (See http://comments.gmane.org/gmane.comp.gcc.devel/59296 - the "new methods" mentioned there never emerged). Proposals to refactor it have been vetoed by rms.
As a result, gcc is substantially harder to understand and work on than other compilers of similar scope.
As a result, new development effort, both personal and corporate, is going into clang.
As a result, even if clang is only approximately at parity with gcc now, people expect it to improve faster in future, and therefore to be a better choice now.
All of these contribute to what http://lists.freebsd.org/pipermail/freebsd-questions/2012-Ju... says are non-licence reasons to replace gcc:
As a result, gcc is substantially harder to understand and work on than other compilers of similar scope.
As a result, new development effort, both personal and corporate, is going into clang.
As a result, even if clang is only approximately at parity with gcc now, people expect it to improve faster in future, and therefore to be a better choice now.
All of these contribute to what http://lists.freebsd.org/pipermail/freebsd-questions/2012-Ju... says are non-licence reasons to replace gcc:
1) GCC's continuously increasing propensity to generate "bad code",
2) The inability of GCC mamintainers to fix _long-standing_ bugs, some
have been identified for over a decade, and have not been fixed.
3) The continuously increasing trend of introducing 'non standard' features,
4) The growing need to 'write around' correct/valid code that GCC will not
compile.
5) The fact that the GCC code is 'unmaintainable' -- *NO*ONE* (other than
someone who has been working with GCC internals for "forever" --a decade
at an absolute minimum) has any chance of 'understanding' what it is
doing internally."New methods" did emerge, and the result is GCC plugin. http://gcc.gnu.org/wiki/plugins
GCC plugin needs to be GPL-compatible, and GCC includes a license check similar to Linux kernel module tainting. (Instead of tainting, you can't run plugin at all.) http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html
GCC plugin needs to be GPL-compatible, and GCC includes a license check similar to Linux kernel module tainting. (Instead of tainting, you can't run plugin at all.) http://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html
Would the world be a better place if Apple weren't allowed to Tivoize the iDevices because all the free software in them were licensed under GPLv3? I'd say yes.
We can clearly see that since the move to GPL3, Apple is reimplementing a lot of free software previously licensed under GPL2 (I wonder how long the default shell remains outdated bash. I wonder what they will move to). And unlike clang, not all of their replacements are free software.
Case in point: their SMB stack.
To me this shows that Apple would just not have used (and contributed to) any free software if it was all GPL3. The world would be a worse place. In fact, the world has gotten considerably worse, Apple-wise, when we lost Samba in OSX.
The patent clauses in GPL3 make that license completely unsuitable for any company (with cautious lawyers) that owns significant patents. I can really kind if understand Apple here.
Case in point: their SMB stack.
To me this shows that Apple would just not have used (and contributed to) any free software if it was all GPL3. The world would be a worse place. In fact, the world has gotten considerably worse, Apple-wise, when we lost Samba in OSX.
The patent clauses in GPL3 make that license completely unsuitable for any company (with cautious lawyers) that owns significant patents. I can really kind if understand Apple here.
Just to put it into perspective, the the patent clauses in GPLv3 was initially copied from the apache license almost word for word.
The only significant change that FSF did was adding an additional point regarding patent agreements. They describe that: If you have an expressed permission to practice a patent or covenant not to sue for patent infringement, such agreement is seen as identical as if you were holding the patent yourself.
If you are in a company that has significant amount of patents, and who would prefer keeping a patent rather than gaining benefit from free and open source software, then one need to keep an eye on any software one want to distribute that has apache, GPL or any other licenses with a patent clause in them.
If you are in a company that has significant amount of patent agreements, then one need to keep an eye on any software one want to distribute that got GPLv3 software in it. Apple do have a few such agreements.
The only significant change that FSF did was adding an additional point regarding patent agreements. They describe that: If you have an expressed permission to practice a patent or covenant not to sue for patent infringement, such agreement is seen as identical as if you were holding the patent yourself.
If you are in a company that has significant amount of patents, and who would prefer keeping a patent rather than gaining benefit from free and open source software, then one need to keep an eye on any software one want to distribute that has apache, GPL or any other licenses with a patent clause in them.
If you are in a company that has significant amount of patent agreements, then one need to keep an eye on any software one want to distribute that got GPLv3 software in it. Apple do have a few such agreements.
I'm not sure what you're talking about. You think if the software is GPLv3, Apple won't put restrictions in their hardware in order to be able to shift the software with OSX? More likely they will just not use that software and go write their own (which is, after all, one of the reasons behind their support of the LLVM project in the first place). If all open source software was GPLv3, Apple would ship only proprietary software on their systems, so we'd go from OSX using free software with proprietary modifications, to OSX using completely proprietary software. Hardly much of an improvement.
Who is to say all free software developers want to prevent Tivoization? If all developers wanted to prevent that, they would use GPLv3! Clearly many developers like the MIT/BSD licenses. Are you advocating that these developers switch to GPLv3 or... what is your alternative?
Torvalds himself has said that he things Tivoization should be allowed, but many other big kernel developers disagree.
When describing what an other person has said, please do not slim it down to the point where it losses context.
What he has said is that he personally don't like DRM, but he thinks it outside the scope of the kernel and a software license (see https://groups.google.com/forum/#!topic/fa.linux.kernel/L5NR...)
What he has said is that he personally don't like DRM, but he thinks it outside the scope of the kernel and a software license (see https://groups.google.com/forum/#!topic/fa.linux.kernel/L5NR...)
I've seen an interview with Linus when he actually said just that: GPLv2 is about "if you used/changed my code I want to see it", whereas GPLv3 is about "If you used/changed my code I want to play with your hardware", and that he is not in favor of V3 for that reason as he doesn't feel its demands are "justified".
So MBCook's statement is fairly accurate, to the best of my memory.
So MBCook's statement is fairly accurate, to the best of my memory.
s/your hardware/hardware you sold me/
You are allowed to play with the hardware. You can remove/change chipsets, install anything, take it to skydiving or burn it. Doesn't mean they have to make it easy for you to do it.
...that depends on the license.
But I'm only here to clarify the very important point about who owns the hardware in question, not to call either license better.
But I'm only here to clarify the very important point about who owns the hardware in question, not to call either license better.
What on earth does this have to do with Clang? You realise that Apple adopting GPLv3 GCC wouldn't require all iOS software to be licensed under GPLv3, right?
What's FreeBSD's adoption of llvm/clang got to do with Apple's non-adoption of GPLv3 ? (Linux is a GPLv3 holdout as well btw).
The *BSDs prefer a non-GPL licensed alternative if they can get one.
The *BSDs prefer a non-GPL licensed alternative if they can get one.
Linux is licensed as GPL v2 (only), so a switch to gpl v3 would require concent from all contributors and be practically impossible.
I would say that the license is to a certain degree also a technical reason to use LLVM. Projects, corporations or people can integrate LLVM into their product with less hassle than with GCC. You can't integrate GCC into a product directly, GCC can only be used as an independent binary. I would think that this would make LLVM more enticing to developers. Obviously this depends on the intended use if all you need is a compiler GCC might still be the better choice.
I've been using clang/LLVM in my FreeBSD system for several months now, and I've noticed that clang builds faster than gcc, and I've not had any issues with reliability, so I don't see what the problem is here.
Also, as noted in the comments on StackExchange, BSD licensing vs GPL may be reason enough to discontinue the use of gcc in FreeBSD systems.
Also, as noted in the comments on StackExchange, BSD licensing vs GPL may be reason enough to discontinue the use of gcc in FreeBSD systems.
less-optimizing compilers usually build faster than more-optimizing compilers.
Be glad for the rise of Clang/LLVM. When there is a serious competitor, quality will stay higher and the projects will evolve faster. ie. Clang will force gcc to become better. gcc will force Clang to become better. End result, we all WIN!
or more commonly I see with the big projects:
1. Big open source software project has almost all of the market share for specific task.
2. Userbase gets tired of old/bad/needless/shitty management stuff in the underlying whatever.
3. New hotness(or several) appears on stage
4. One emerges as main successor to (1)
5. Goto 1
Not in the case of big software projects (and your C compiler is undoubtedly a big software project). Its taken about 10 years and millions of man hours to get clang/llvm on a performance parity with gcc.
Any new C compiler has to either just be a C -> optimised C compiler (in which case why not just write an LLVM pass) or duplicate all of the optimisations which exist in LLVM/gcc.
Any new C compiler has to either just be a C -> optimised C compiler (in which case why not just write an LLVM pass) or duplicate all of the optimisations which exist in LLVM/gcc.
I did not understand the 'political' issue: The GPLv3 license does not apply to executable files created by gcc; you can even use gcc to create proprietary products. What is the problem of using gcc 4.7 in order to compile BSD if the license does not apply to the executable - BSD in this case ?
FreeBSD is not just a kernel, it also ships with a userland, which includes a C compiler (obviously).
In other words, FreeBSD ships with a gcc binary, which means FreeBSD is distributing gcc, which means all clauses in the GPLv3 apply to them.
Any group/company/whatever wishing to ship FreeBSD that doesn't strip out the compiler will be affected similarly.
In other words, FreeBSD ships with a gcc binary, which means FreeBSD is distributing gcc, which means all clauses in the GPLv3 apply to them.
Any group/company/whatever wishing to ship FreeBSD that doesn't strip out the compiler will be affected similarly.
While Clang's GCC compatibility is quite good, 12.1% of Debian archive still fails to build with Clang. It is an almost drop-in replacement, but not a drop-in replacement. http://clang.debian.net/
The statistics on that page do a good job of explaining that in many (most?) of the cases clang will never quite be a drop-in replacement, because the failure is in actuality uncovering a bug in either GCC or the software being compiled.
Sylvestre Ledru spent some time on this in particular in his talk at this past FOSDEM[1], taking the above as evidence that clang is now mature enough to support the Debian archive.
[1] https://archive.fosdem.org/2013/schedule/event/debian_clang/
Sylvestre Ledru spent some time on this in particular in his talk at this past FOSDEM[1], taking the above as evidence that clang is now mature enough to support the Debian archive.
[1] https://archive.fosdem.org/2013/schedule/event/debian_clang/
Why would it be drop in? The default for clang is c99, for gcc it is still c89, if this was never specified in makefiles you're in for a world of possible hurt. Most "errors" I see on that page amount to boring differences of how the compilers treat C, or how clang doesn't support some random gcc extension, or how clang differs in its interpretation of implementation defined behavior.
I am just pointing this out because some people on this thread are claiming "I have been using Clang for N months and had no problem". I believe them, but it won't necessarily work for you, because Clang is not a drop-in replacement.
Clang doesn't need to be a drop-in replacement and I think it shouldn't be, but let the buyers beware.
Clang doesn't need to be a drop-in replacement and I think it shouldn't be, but let the buyers beware.
Gotcha, I just notice most problems seem to be of the "clang interprets the standard this way, therefore it must be wrong because gcc compiles it".
I think having multiple different interpretations of undefined behavior a good thing. Means new standards could likely define it. Also shows how much code manages to compile that probably shouldn't. I know i've been surprised with what ambiguous stuff gcc has allowed in my own code.
I think having multiple different interpretations of undefined behavior a good thing. Means new standards could likely define it. Also shows how much code manages to compile that probably shouldn't. I know i've been surprised with what ambiguous stuff gcc has allowed in my own code.
Yeah, this is because many tend to confuse their C or C++ compiler accepts with what the ISO/ANSI standard states.
Any C or C++ developer doing cross platform development, even if only across UNIX platforms, will have lots of war stories to tell about using different compiler vendors across systems.
Any C or C++ developer doing cross platform development, even if only across UNIX platforms, will have lots of war stories to tell about using different compiler vendors across systems.
Politics really does destroy all that is holy. in this case free software. should I be able to extend free software for profit or not? I would say yes... but there are some cases in which I would say no. for a compiler I would say no one should be able to make money off an extension. it just doesn't make since.
I was thinking this as well. I see the GPL, and Copy Left licensing in general, as a sort of regulatory force in free software. If you want to participate the GPL will put constraints on you to play nice with others in the FOSS space.
Given what happened in the financial markets as they were deregulated I am extremely suspicious of the notion that removing the constraints of Copy Left will actually be positive in the long run. I have no doubt that it will help companies like Apple but I don't see the benefit for the wider community of developers.
Given what happened in the financial markets as they were deregulated I am extremely suspicious of the notion that removing the constraints of Copy Left will actually be positive in the long run. I have no doubt that it will help companies like Apple but I don't see the benefit for the wider community of developers.
I'm not sure this is true (anymore?). There are many open source projects who are thriving under non copyleft licenses.
If someone wanted to be a dick about it they could release modified GPL code as one big diff and publish it on some obscure webpage only their customers have access to. Instead we see more and more companies and individuals becoming friendly open source citizens. Perhaps some because the GPL mandates it but I would like to think mainly because they feel it's right thing to do—copyleft or not.
If someone wanted to be a dick about it they could release modified GPL code as one big diff and publish it on some obscure webpage only their customers have access to. Instead we see more and more companies and individuals becoming friendly open source citizens. Perhaps some because the GPL mandates it but I would like to think mainly because they feel it's right thing to do—copyleft or not.
I too share your general optimism about the current state of open source. I really hope that you are correct in your conclusion that the GPL mandate is unnecessary because, as we see here, many projects are trying to get away from it. However, I feel we have a number of historical examples of what happens when constraints are lifted in a space that has a number of very powerful players. None of them look like anything I want the Open Source movement to look like.
Well, whatever the license, here is to a bright future! That a rising tide may lift all boats.
The GPL is supposed to put constraints on you, but I'm still waiting for a source code release from Billion for their router firmware (Busybox) and Philips have removed access to their GPL source trees.
Why do you feel that? There's no benefit to a company in maintaining an ever evolving and complex fork of a project as compared to contributing back the non business essential parts so that their fork can be smaller.
What I don't understand is that the same people who get up in arms about government, and bitch and moan about "rights to the fruit of my labor", don't like the notion that someone else can claim those very rights by putting a gnu license on something. At that point they get all whiney about unfairness to their little business and how they could just make money if the could appropriate someone else's labor against their terms (aka the thing they hate about taxes). It's an odd cognitive dissonance.
Taxation deprives the victim of property. Distributing derivative works of OSS does not deprive the OSS authors of anything. Distributing works that use OSS as a library does not deprive the OSS authors of anything. Running a service which does not distribute OSS but depends on the OSS internally does not deprive the OSS authors of anything.
Of course, people can use whatever license they want. I personally favor licenses that maximize the rights of my users. Hopefully, though, you can now see that the combination of positions you mentioned is a consistent one.
Of course, people can use whatever license they want. I personally favor licenses that maximize the rights of my users. Hopefully, though, you can now see that the combination of positions you mentioned is a consistent one.
Excuse me. I am an existence proof of the falsity of your statement. I don't like government much, and I do think I have a right to the fruit of my labor. And I'm more than happy to use GPL software when it is appropriate, and I'm quite happy to license my own labor out as AGPL3.
Actually, I didn't say "all". Had I said "all", your existence merely forces a modification, and at best your existence doesn't even show incorrectness had I said "vast majority". As it stands my statement could be interpreted as "all", that part was unclear. I merely meant "a lot".
Your statement is a shining example of the fallacy fallacy though... just because one interpretation of what I said on a detail of it is incorrect, that in no way invalidates my statement nor the existence of vocal people like those I describe.
Your statement is a shining example of the fallacy fallacy though... just because one interpretation of what I said on a detail of it is incorrect, that in no way invalidates my statement nor the existence of vocal people like those I describe.
While I've always been happy with GPLv2 and understand why some people like GPLv3 - on the other hand AGPL should have never been accepted as either an open-source or free-software license, because it really isn't and OSI only accepted it to avoid a political conflict.
What part of the Open Source Definition[1] does AGPL not comply with?
[1]: http://opensource.org/osd
[1]: http://opensource.org/osd
Ah so if you think you have the right to the fruit of your labor, I assume that means you're a communist?
That seems pretty in step with the GPL.
That seems pretty in step with the GPL.
No, I'm not. But I think that I have a certain right to what I do with myself; this right allows me to sell my services to employers.
I think that there is a powerful value in sharing, however. On a physical level, the old-fashioned term is "being a good neighbor". The GPL enforces sharing contractually. There's also a powerful value in being able to fix things that you use. And the GPL enables that as well, also contractually.
So I prefer the AGPL3 when possible, because I believe its values align with what I believe to be the best for society.
I think that there is a powerful value in sharing, however. On a physical level, the old-fashioned term is "being a good neighbor". The GPL enforces sharing contractually. There's also a powerful value in being able to fix things that you use. And the GPL enables that as well, also contractually.
So I prefer the AGPL3 when possible, because I believe its values align with what I believe to be the best for society.
> Ah so if you think you have the right to the fruit of your labor, I assume that means you're a communist?
More likely, a libertarian in the contemprary American sense of the term, though the labor theory of property is at least Lockean in vintage.
More likely, a libertarian in the contemprary American sense of the term, though the labor theory of property is at least Lockean in vintage.
the same people who get up in arms about government, and bitch and moan about "rights to the fruit of my labor", don't like the notion that someone else can claim those very rights by putting a gnu license on something
I misread this at first. I think this makes the point more cogent:
the same people who get up in arms about government, and bitch and moan about "rights to the fruit of my labor", don't like the notion that someone can claim "the rights to the fruit of their" labor by putting a gnu license on something
I misread this at first. I think this makes the point more cogent:
the same people who get up in arms about government, and bitch and moan about "rights to the fruit of my labor", don't like the notion that someone can claim "the rights to the fruit of their" labor by putting a gnu license on something
Not sure if you mean for profit and proprietary or just making money in general. For some reason though a lot of people think you can't sell GPL'd software which you absolutely can.
Why would I pay for a copy of some GPL software when I could just wait for someone else to buy it and then get it from them for free?
#1 Support?
#2 Hosting/cloudiness?
#3 Administration?
#4 Custom adaptation?
#5 Privileged early access to updates/content files?
All those different strategies has been used to "sell" GPL software. Even the last one has been used, even if their customers could repackage the update and redistribute it to non-paying customers.
#2 Hosting/cloudiness?
#3 Administration?
#4 Custom adaptation?
#5 Privileged early access to updates/content files?
All those different strategies has been used to "sell" GPL software. Even the last one has been used, even if their customers could repackage the update and redistribute it to non-paying customers.
All of them fail for desktop software, this is why FOSS as business works only for developer tools or SaaS software.
Not necessarily. For example there's the model used by the x264 project (and upcoming x265 project), they offer the encoder as free software under GPL but they also sell licences for using it in proprietary projects and apparnetly they (the developers) make good money this way.
Then there's the recent example of Openshot, a GPL licenced video editor where the author went to kickstarter to gain funding for improving it greatly, the goal was $20.000 and it reached $45,028.
I see a combination of these models as a future popular way of making money out of your open source efforts.
Then there's the recent example of Openshot, a GPL licenced video editor where the author went to kickstarter to gain funding for improving it greatly, the goal was $20.000 and it reached $45,028.
I see a combination of these models as a future popular way of making money out of your open source efforts.
Selling licenses for use in proprietary software is not selling GPL software. In particular, I can not sell you a proprietary x264 license for software that I received under the GPL.
Dual-licensing effectively says, "We'll let you take away user freedoms, but only if you pay the original copyright holders." Which is akin to openly bribing communist party officials.
Dual-licensing effectively says, "We'll let you take away user freedoms, but only if you pay the original copyright holders." Which is akin to openly bribing communist party officials.
Your first example is a developer tool, as mentioned by me.
Kickstarter projects is USA specific, and it seldom works if you need a steady income of money.
Kickstarter projects is USA specific, and it seldom works if you need a steady income of money.
It's a video encoder, hardly a 'developer tool'.
As for steady income of money, true that this type of funding isn't of the steady pay-check variety but if you can continue to add value to your project then it could become a long term income.
Either way I'd say the vast majority of open source desktop software today is done without any compensation and during developers spare-time, things like kickstarter opens up possibilities for them to actually make money while doing what they would likely have done either way, and it can also give them the financial opportunity to work exclusively on the project for a period of time.
As for steady income of money, true that this type of funding isn't of the steady pay-check variety but if you can continue to add value to your project then it could become a long term income.
Either way I'd say the vast majority of open source desktop software today is done without any compensation and during developers spare-time, things like kickstarter opens up possibilities for them to actually make money while doing what they would likely have done either way, and it can also give them the financial opportunity to work exclusively on the project for a period of time.
> It's a video encoder, hardly a 'developer tool'.
Quoting from the VideoLAN web site, > x264 is a free software library and application
That is a developer tool on my language.
Quoting from the VideoLAN web site, > x264 is a free software library and application
That is a developer tool on my language.
[deleted]
Perhaps. But even if no-one would pay money for a direct software download/package, this does not preclude sponsorship of companies to free software projects they wish to be more developed. Indeed, there are many such large projects.
Derivates of GPL software are also GPL licenced. If you use a lot of GPL code in your product you have to provide the source.
The possibility of a dual licence gives the creator a compensation because he waives the rights the GPL gives him for you.
Also: Support contracts. A lot of poeple live in the support ecosystem and adapt GPL/BSD software for costumers.
The possibility of a dual licence gives the creator a compensation because he waives the rights the GPL gives him for you.
Also: Support contracts. A lot of poeple live in the support ecosystem and adapt GPL/BSD software for costumers.
> If you use a lot of GPL code in your product you have to provide the source.
Fixed:
If you use ANY GPL code in your product you have to provide the source.(There are of course exeptions eg LGPL)
Also it isn't simply derivative work that that can be forced to re-license under the GPLv3. If FreeBSD had elected to adopt a GPLv3 compiler and distribute the source(as they do with the compiler) then the FreeBSD kernel itself would become subject to it. In fact, it isn't just gcc which has this restriction. Any GPL v3 code isn't allowed in base.
Further reading:
http://www.freebsdfoundation.org/press/2007Aug-newsletter.sh...
Fixed:
If you use ANY GPL code in your product you have to provide the source.(There are of course exeptions eg LGPL)
Also it isn't simply derivative work that that can be forced to re-license under the GPLv3. If FreeBSD had elected to adopt a GPLv3 compiler and distribute the source(as they do with the compiler) then the FreeBSD kernel itself would become subject to it. In fact, it isn't just gcc which has this restriction. Any GPL v3 code isn't allowed in base.
Further reading:
http://www.freebsdfoundation.org/press/2007Aug-newsletter.sh...
Nonsense. Just putting GCC source code in to the BSD repository wouldn't magically spread the requirement that the entire project become GPL any more than keeping a copy on my hard drive requires I give the FSF the complete contents of my /home directory. What matters is the dependency/linkage.
The GCC 'runtime library exception' firewalls all 'target code' from the GPLv3, and even allows proprietary preprocessors, linkers and assemblers (but nothing that would involve modifying GCC to split what it does in to more granular stages)
The GCC 'runtime library exception' firewalls all 'target code' from the GPLv3, and even allows proprietary preprocessors, linkers and assemblers (but nothing that would involve modifying GCC to split what it does in to more granular stages)
In particular, Apple shipped GCC with Darwin.
If you're going to be a pedant, get it right.
You have to license any code that links with GPL code under the GPL. This does not prevent you from dual-licensing your own portion of the code base, or shipping non-GPL, non-linked code as part of the same product (Although in the case of things like DLL plugins it gets a bit hazy)
You have to license any code that links with GPL code under the GPL. This does not prevent you from dual-licensing your own portion of the code base, or shipping non-GPL, non-linked code as part of the same product (Although in the case of things like DLL plugins it gets a bit hazy)
You have to license any code that links with GPL code under the GPL. This does not prevent you from dual-licensing your own portion of the code base, or shipping non-GPL, non-linked code as part of the same product (Although in the case of things like DLL plugins it gets a bit hazy)
Actually, that's a common, but wrong interpretation. The whole work becomes GPL, but the code that links to GPL code doesn't have to be GPL.
Actually, that's a common, but wrong interpretation. The whole work becomes GPL, but the code that links to GPL code doesn't have to be GPL.
It has to be "GPL-compatible" though, which means whoever you give it to can convert it to the GPL by adding the extra conditions of the GPL to it.
Most commercial GPL software outfits make their money by dual-licensing, or charging for support or bespoke add-ons.
I pointed this out elsewhere, but dual-licensing isn't selling GPL software; it's more like giving away proprietary software under the GPL.
You can sell GPL software. It's just really hard to actually make money :-P
You can put a price on GPL software.
What you shouldn't do is to hope that anyone will pay you.
The first person who pays can offer exactly the same thing for $0.
It's impossible to convince anyone that they should pay you even $1 if exactly the same thing is available for $0 from somewhere else.
The ability to charge for GPL software is purely theoretical. In practice, you can't.
What you shouldn't do is to hope that anyone will pay you.
The first person who pays can offer exactly the same thing for $0.
It's impossible to convince anyone that they should pay you even $1 if exactly the same thing is available for $0 from somewhere else.
The ability to charge for GPL software is purely theoretical. In practice, you can't.
Not true. Just see MySQL for one example. Before Oracle bought MySQL AB (for $1 billion) their revenues on commercial support for their largely GPLv2 software was in the tens of millions. The same may already be true for Monty Program AB who provide commercial support for MariaDB. The closer you get to infrastructure, the more being open source is a competitive advantage.
This is not the case with most open source software.
Actually the majority of corporations are leechers, using it as "free beer", only paying back if they really have to, as many corporations don't use software without support contracts.
Or happen to have some FOSS followers taking business decisions.
Otherwise, I can tell you from my experience working on Fortune 500 consulting projects, very seldom is any money or contribution given back.
Actually the majority of corporations are leechers, using it as "free beer", only paying back if they really have to, as many corporations don't use software without support contracts.
Or happen to have some FOSS followers taking business decisions.
Otherwise, I can tell you from my experience working on Fortune 500 consulting projects, very seldom is any money or contribution given back.
I thought MySQL AB has dual licensing model and that business can pay for commercial non-GPL MySQL.
It's impossible to convince anyone that they should pay you even $1 if exactly the same thing is available for $0 from somewhere else.
Radiohead's In Rainbows, the Humble Bundles and other pay-what-you-want sales disprove that statement. All had average purchase prices well above the minimum. (That doesn't mean such a model is very profitable compared to fixed prices, of course.)
Even in a purely self-interested point of view, there are reasons for paying (e.g. keeping development active).
Radiohead's In Rainbows, the Humble Bundles and other pay-what-you-want sales disprove that statement. All had average purchase prices well above the minimum. (That doesn't mean such a model is very profitable compared to fixed prices, of course.)
Even in a purely self-interested point of view, there are reasons for paying (e.g. keeping development active).
Those are one shot successes, hardly a model to follow for anyone that needs a steady source of income to pay things like mortgage, employees and such.
Those are one shot successes
Maybe so; can you point out those cases where the average payment for a pay-what-you-want sale was no higher than the absolute minimum?
hardly a model to follow for anyone that needs a steady source of income to pay things like mortgage, employees and such.
That's a very different claim from what I was contesting.
But in any case, it may work in when you have modest needs; Joey Hess just got his second year of development of Git-Annex funded[1]. Of course, not everyone is willing to work for $15k/year, even if it comes with few strings attached, particularly obviously talented and experienced developers like him.
[1] https://campaign.joeyh.name/
Maybe so; can you point out those cases where the average payment for a pay-what-you-want sale was no higher than the absolute minimum?
hardly a model to follow for anyone that needs a steady source of income to pay things like mortgage, employees and such.
That's a very different claim from what I was contesting.
But in any case, it may work in when you have modest needs; Joey Hess just got his second year of development of Git-Annex funded[1]. Of course, not everyone is willing to work for $15k/year, even if it comes with few strings attached, particularly obviously talented and experienced developers like him.
[1] https://campaign.joeyh.name/
> Of course, not everyone is willing to work for $15k/year
That is the main point, in Germany you can earn around 5x that on an average consulting job.
That is the main point, in Germany you can earn around 5x that on an average consulting job.
You don't get the freedom he has, though, both in terms of working hours, location, etc.
[deleted]
Redhat seems to make money...
They sell supports. Theorically, they don't even have to contribute to development of Linux at all.
The only thing you have a say in is code that you have copyright on.
In a word - Apple. IOS and OSX borrow heavily from BSD
Apple has made more money form free software than anyone else, and they can pressure FreeBSD to stay away from GPL3
Apple has made more money form free software than anyone else, and they can pressure FreeBSD to stay away from GPL3
> they can pressure FreeBSD to stay away from GPL3
Yes; Apple can pressure the FreeBSD project to stay away from GPLv3, through their evil Apple magic. In fact, they are presumably pressuring the whole world to stay away from GPLv3, as it has seen almost no adoption outside the FSF! Naughty, naughty Apple. If not for mean ol' Apple, the FreeBSD project would no doubt rush to embrace GPLv3, discarding their horrible old BSD license!
Yes; Apple can pressure the FreeBSD project to stay away from GPLv3, through their evil Apple magic. In fact, they are presumably pressuring the whole world to stay away from GPLv3, as it has seen almost no adoption outside the FSF! Naughty, naughty Apple. If not for mean ol' Apple, the FreeBSD project would no doubt rush to embrace GPLv3, discarding their horrible old BSD license!
In a word - no. FreeBSD has been around a lot longer than Apple's switch to Darwin. FreeBSD has a long history of preferring BSD licensed code to GPL licensed code. Apple has just financed clang/llvm. Apple has their reasons for using clang, and FreeBSD has theirs. FreeBSD didn't need any pressure from Apple to make the switch.
In fact, the error messages of the two systems are largely a tradeoff at this point, and in a project I work on that compiles using both gcc and clang (targeting MinGW and OSX) simultaneously, on multiple occasions gcc has returned the more useful error messages (even if you discount the times when clang outright crashes while trying to compile my code, something gcc hasn't done to me in a decade). Even to the extent to which clang is better (which is mostly how it will guess what you meant and then compile the rest of the file under that assumption), it is kind of insulting in an open source context to treat that as a competitive advantage when I'm certain gcc would have loved that patch as a contribution.