>Well, the GPL mandates the right to use the application, and that a redistributor cannot restrict it (section 0, preambule and section 6, IIRC); that right is not guaranteed by MIT, BSD, MPL or Apache.
Yeah, and because of the additional restrictions of GPL, big companies are simply avoiding it or writing software to replace it.
See: CLANG/LLVM. GCC used to be the king of the compiler heap; now it's well on its way to becoming an historical footnote.
It's far better to convince people to help you by being trusting and generous than by coercion. The GPL uses coercion.
Yes, some companies use BSD/MIT software and lock it up, never to send improvements back upstream. But they ultimately are harming themselves, as they can't trivially update to new versions of the the software, because they're now maintaining a fork, and the longer their code diverges, the harder it will be to maintain. So they are motivated to send improvements upstream. And many (most?) big companies do.
When there's another game in town, people will play the one where they're more welcome. Open source software benefits by many eyes and many hands; the GPL (especially GPLv3) cuts off access to just about everyone in big companies, which means the size of the potential user base is a fraction of what it can be.
Linux is a notable exception, obviously. But with Linux there's a clear way to use it that doesn't risk your proprietary code. Most other software, not so much.
I'd go further and say it's not just big companies. I've worked for big companies and small, and they have all avoided GPL as much as possible.
It is worse, though, in larger companies. There is generally several layers more of bureaucracy to get through to be able to use GPL licensed software.
To be clear, I'm speaking of my role as a developer and using GPL software in developing proprietary software.
I've worked for a small company and we had similar problems. It's not that you have to convince six layers of bureaucrats who have no idea what GPL is but they read in eWeek that it's scary -- it's simply that, when you're that small, long-winded consulting services from IP lawyers is not the kind of stuff you want to spend money on.
> Yes, some companies use BSD/MIT software and lock it up, never to send improvements back upstream. But they ultimately are harming themselves, as they can't trivially update to new versions of the the software, because they're now maintaining a fork, and the longer their code diverges, the harder it will be to maintain. So they are motivated to send improvements upstream. And many (most?) big companies do.
Could you provide some supporting arguments / evidence for this statement - "GCC used to be the king of the compiler heap; now it's well on its way to becoming an historical footnote." ?
* As pointed out by another commenter, Apple switched away from GCC as the default to CLANG.
* Microsoft is supporting CLANG.
* Android switched from GCC default to CLANG default.
* The CLANG development community, combined with the LLVM development community, are both extremely robust.
* GCC used to have full time commercial developer contributors working for Google and Apple and other large companies; most such companies have migrated almost entirely to CLANG/LLVM support.
* Because of better management and the army of full time commercial developers contributing to it, CLANG is better in practically every conceivable way at this point than GCC. If GCC weren't GPL, CLANG would likely be (at most) a fork of GCC, and may have been merged back into trunk by now (this happened to GCC once before).
CLANG is also an excellent example of how a completely permissive license can be sufficient to encourage big companies to contribute their changes back to the commons. All of the GPL fearmongering would have you believe that CLANG couldn't exist, and yet it thrives.
And printer drivers are still almost all proprietary [1]. So GPL didn't even achieve the objective that inspired it.
GPL did prove that open source CAN work, and it jumpstarted the open source movement. But its time has past; enough people understand the benefits of contributing to open source that the coercion is no longer necessary, and in fact is harmful.
[1] Some printer drivers have been reverse-engineered for Linux, certainly. But modern printers frequently leave so much processing for the host that their drivers are nontrivial, and even when there exists "free" drivers for Linux, they pale in comparison feature-wise to the proprietary drivers. I'm sure there are exceptions.
LLVM was not created as reaction against the licensing model of GCC. It was created as a research project exploring: "transparent, lifelong program analysis and transformation for arbitrary programs."[1] GCC and other compilers were not setup to do this. They needed to build an intermediate representation of a kind that was highly unusual for the time. That is where it originated, as pure research. Trying to build a better mouse trap. Not to become a GCC competitor. It did become one because it turned out they had some rather good ideas!
The GPL is not harmful and I encourage you to utilize it when appropriate for it protects you (the original author) and your target users far more than BSD or other similar licenses.
> It was created as a research project exploring: "transparent, lifelong program analysis and transformation for arbitrary programs."[1] GCC and other compilers were not setup to do this.
gcc was in fact set up to explicitly not be able to do this.
The developers of gcc made understanding the intermediate forms as well as creating plugins as hard as possible specifically so that you couldn't get around the GPL.
clang a direct result of attempting to coerce people with real money with the GPL.
> > It was created as a research project exploring: "transparent, lifelong program analysis and transformation for arbitrary programs."[1] GCC and other compilers were not setup to do this.
> gcc was in fact set up to explicitly not be able to do this.
GCC was originally very difficult to integrate with so that non-free programs could not be built on top of it. However, the creation of LLVM does not reduce to: "GCC was difficult to work with so we made this." There had been many attempts to make "Universal Compiler IRs". These attempts had not gone well. LLVM instead chose to do something at a unique level of abstraction that wasn't good for everything but was very good for its particular niche. Once again, read the paper, LLVM really wasn't created as a reaction against GCC.
I feel like the GPL-ness of gcc was less material than the fact that it's developers were afraid of closed source frontends benefiting from their work, and obfuscating the front end so that it was hard to use without pulling in the rest of the codebase.
And the reason I switched was because Clang had better error messages.
Like other commenters, I think GPL had little to do with switch to Clang/LLVM. I liked it for its better, versatile design with a community turning it into the program analysis/transformation baseline to beat them all (minus Semantic Design stuff maybe). However, I think your overall point is supported by the fact that many virtualization solutions in embedded space are marketing GPL isolation as a benefit worth buying them. They probably wouldn't be saying it unless they had lots of customers talking about that problem.
Interesting point about the virtualization. MANY companies are scared of GPL, for certain.
Thinking about Clang, its better design didn't evolve in a vacuum. Clang was primarily developed by Apple [1] so that they would have (with LLVM) a full compiler toolchain that didn't include GPL code (and as others have mentioned, Clang is designed to integrate with editors for parsing, while GCC is explicitly designed to be HARD to integrate that way so that it can't be snuck into a proprietary project).
YOUR choice to change to Clang may not have been about licensing, but licensing and design choices in support of that license philosophy are what caused Clang to exist.
This gives the worrying possibiltiy that Apple can benefit from an open source Clang and LLVM now, and in future can make thecomponents required to compile code to their platforms (mainly thinking iOS) proprietary.
They're already moving to encourage / require iOS devs to ship them LLVM IR code - the most logical reason for this is so that they can keep the last part of compilation entirely proprietary in future, taking further freedoms from users and developers.
They design and fab their own ARM chips already, so this is plausible.
Exactly. They did that sort of thing with Mac OS and iOS on Darwin. They're doing it with Clang. They always do it. It's how they make billions of dollars. Not sure why you worry whether a particular company might scheme: simply don't buy their stuff.
See how that works? And despite Google's BS, I have plenty of ways to keep Android devices largely under my control. On that side of the fence, people stopped worrying and started modding en masse. :)
Further, mobile security vendors such as OK Labs w/ OKL4 let us isolate that mess while programming directly on the kernel or a custom runtime (think MirageOS for mobile). So, we have plenty of options because we aligned with a company doing open-source mobile with little lock-in. Align with closed-source and lock-in loving companies then you get what you had coming. ;)
My choice was about licensing and design but 90+% design given GCC was a pain to work with. Your link shows two paragraphs of text talking about design issues with one sentence on licensing. So, it seems Apple's justifications were more similar to my own than different.
The best part is that so many have jumped on the LLVM bandwagon. There's even a formal semantics to get formal verification work going. Mainstream coders, tool developers, and high assurance people all under the same roof contributing a bit to the same tool. Lots of potential there.
Thanks for writing this up, you make some excellent points. Could you comment on why the BSD's (FreeBSD / OpenBSD / NetBSD) has so far not made inroads against Linux which happens to be GPL2 licensed?
First of all, BSD, in the form of OS X and iOS, is more than holding its own.
On the desktop, I believe that BSD was (a) hamstrung by the AT&T / BSDI lawsuit at a critical time and (b) suffered from fragmentation brought about more by incompatible forceful personalities than by technical issues.
Still shares some userland, but this is irrelevant.
I would say that for most people, the API matters far more than the kernel implementing it.
not open sourced
http://www.opensource.apple.com has the kernel sources under "xnu". I don't think that substantially less is open sourced than e.g. for Android.
look at how well their open sourced Darwin OS project is doing in terms of update and support
The updates are fairly current (10.10.1 corresponds to the version of OS X shipped last fall), though there doesn't seem to be a very large community building on it.
> First of all, BSD, in the form of OS X and iOS, is more than holding its own.
Those are proprietary forms. I think we were talking about whether the decision to be BSD-licensed has been good for the health and contribution of the *BSD projects that OS X and iOS originated from. Then we can draw a conclusion (but hopefully after gathering more data) on whether releasing your codebase GPL or BSD is more likely to lead to long-term health for that open source codebase.
A more accurate statement would be that gcc ceded an entire market to Clang. Clang made a big deal about static analysis and tooling for C++ programs, in effect bringing advances in software engineering and tooling made for Java/C# to C/C++. The hostility to making gcc's parsers be more usable by other applications (GCC plugins only very barely made it into the tree) makes Clang the de facto solution; given differences between ASTs, there's also a strong network effect--if you start using Clang, you'll find it hard to switch to gcc and vice versa.
I dont know if licensing was the only reason why GCC missed out on this market. Using parts of the compiler as a library to aid tool building, refactoring and analysis is one of those great ideas that seems obvious in retrospect. To the credit of LLVM's early authors they had a larger vision of what a compiler ought to be than other compilers at the time. I dont recall gcc or any of the other commercial compilers having this expansionary vision of a compiler stack back in the 2000s. Once LLVM was able to move the goalposts on what users expect from a compiler stack, I can see that the license could have eased the decision for the likes of Google and Apple to come on board. It would be interesting if someone from Google / Apple / Microsoft commented on what the thought process was regarding moving to LLVM / Clang and if licensing played a role.
Evidence, not so much, but I've got anecdata, if that's any help:
I used to work for a company which produced a game-playing virtual machine. We had a toolchain that allowed building C and C++ programs for it. The toolchain was based on LLVM and gcc (because clang wasn't around at the time).
Integrating gcc into our toolchain was appallingly hard, solely due to GPL restrictions. The extra work in dividing everything into GPL and non-GPL parts, interfacing between the two, producing split packaging and distribution etc was basically half a full time job.
If the company had survived long enough for clang to have become stable --- which, sigh, it didn't --- we would have switched to it like a shot.
Clang is not a good example... It was adopted by Apple for its technical merits over gcc rather than its license. And, in fact, Apple tried to license clang/llvm under the GPL as a contribution to gcc but was rejected:
No, his point was exactly why I don't believe that permissive licenses are any worse at perpetuating user freedom than coercive licenses like the GPL: when one feels coerced by a license, the option is to just not take it at all. Whereas with a permissive license, one is far more likely to take it initially, and then perhaps share alike afterwards.
Those who wouldn't share under a permissive license wouldn't accept the GPL to start with, so what additional user freedom can the GPL possibly create in the world that's not already there with permissive licenses?
You are speaking of feelings, I speak about facts and what's actually written in the license: the GPL forbids restricting the freedom to use, even when redistributing; the other licenses don't. This is a clear user freedom that is guaranteed by the GPL.
>This is a clear user freedom that is guaranteed by the GPL.
Yes, and that freedom is being guaranteed to fewer and fewer end users of GPLed software because of those feelings you're dismissing.
Linux is probably the success story for GPL, and even in that case Google has bundled it with proprietary software (Android now outnumbers all other operating system installs, IIRC). Yes people can make their own distributions, but they're for the most part irrelevant to 99% of users of Android devices. Probably 99.99% if you include people who never install Google proprietary apps (the Play Store; Google Maps; etc.) on their devices.
The point of GPL wasn't to serve the 1%, but to expand software freedoms to everyone. To start a revolution in software, and to supplant closed source and restrictive licenses. Look around, though; most people are ignoring what freedoms they are offered and basking in proprietary software options.
Open source is beautiful when it works. But freedom to redistribute something without value is about as relevant as debating whether a tree falling alone in a forest makes a noise.
> but is totally besides what I was saying, or the parent.
No, it's not.
GPL is only relevant if it can grant freedom to modify software that's relevant. Freedom to modify something you don't really want to use has no value.
The parents speaks about USER freedom, not about developers or redistributors. You argue that freedom of developers is more important, and that's fine. But don't say that the GPL does not guarantee more user freedom.
I think you're talking past each other. The GPL only guarantees user freedoms if you're a user of software licensed under the GPL. If you're using non-GPL software, then the GPL's protections don't matter. If GPL software isn't as good as non-GPL software (for many different, sometimes conflicting definitions of good), it will have fewer users and thus the GPL will provide freedoms to fewer users.
OpenStack is one of the biggest permissively-licensed free software projects out there:
"""
Everyone I know who is deploying OpenStack has forked. Not publicly, but they have. No one can run the mainline code, it’s a disaster, and OpenStack politics of the “Big Tent” are going to make that problem a lot worse. Because everyone has their own fork, very little code is making it back upstream.
"""
Yeah, and because of the additional restrictions of GPL, big companies are simply avoiding it or writing software to replace it.
See: CLANG/LLVM. GCC used to be the king of the compiler heap; now it's well on its way to becoming an historical footnote.
It's far better to convince people to help you by being trusting and generous than by coercion. The GPL uses coercion.
Yes, some companies use BSD/MIT software and lock it up, never to send improvements back upstream. But they ultimately are harming themselves, as they can't trivially update to new versions of the the software, because they're now maintaining a fork, and the longer their code diverges, the harder it will be to maintain. So they are motivated to send improvements upstream. And many (most?) big companies do.
When there's another game in town, people will play the one where they're more welcome. Open source software benefits by many eyes and many hands; the GPL (especially GPLv3) cuts off access to just about everyone in big companies, which means the size of the potential user base is a fraction of what it can be.
Linux is a notable exception, obviously. But with Linux there's a clear way to use it that doesn't risk your proprietary code. Most other software, not so much.