There is an example of 2 projects that started around the same time, one of which used the GPL and one of which used the BSD license. Almost 30 years after the projects started, the one one using the GPL is vibrate and healthy, while the other project using the BSD license has trouble getting companies to contribute their changes back and barely has enough developers participating in the community to survive.
This is the tale of Linux vs FreeBSD. Companies like Juniper that made heavy use of FreeBSD as the basis for JunOS have an atrocious history of failing to contribute their changes back to the community, and Juniper isn't the only one engaging in this behaviour. Sure there are other reasons that Linux took off and FreeBSD didn't, but license is a major factor in how their respective communities behave.
Yes, there are times when copying BSD licensed code is easier if you don't want to publish your source, but it isn't too difficult to adapt business processes to this constraint for the vast majority of applications. Look at what happened in the wireless router market. Early in the 2000s many products made use of the various vendors' Linux based SDKs and weren't compliant at publishing their source. Today OpenWRT is vibrant and most vendors offer GPL archive downloads on their websites. Personally, I don't think this would have happened if Linux wasn't GPLed and there wasn't the pressure the GPL afforded on vendors to open up their code.
I understand and respect John Carmack's position, and the GPL isn't for everyone, but people need to understand that license can result in significant differences in the viability of a community built around a software project on the longer term scales of 10-20 years.
Many companies using FreeBSD, including Juniper, NetApp, Netflix, Netgate (pfSense), iXsystems (TrueNAS), Dell (Isilon) contribute significant code to FreeBSD. It's very expensive to maintain long-lived changes from upstream, so there's a large incentive not to do so. Code that's "not contributed back" is largely code that isn't suitable for upstream anyhow - because it is incomplete, limited in scope, etc.
Looking at "Sponsored by" tags on the last 6 months of commits to FreeBSD I see the following:
The FreeBSD Foundation
Netflix
Rubicon Communications, LLC ("Netgate")
Chelsio Communications
NetApp, Inc.
Mellanox Technologies // NVIDIA Networking
Innovate UK
Klara, Inc.
Diablotin Systems
Dell EMC Isilon
iXsystems, Inc.
Citrix Systems R&D
Axcient
Netflix, Inc.
DARPA
Alstom Group
Eldorado Research Institute (eldorado.org.br)
Ampere Computing
Marvell
Stormshield
Amazon, Inc.
(and a long list of entries with one or two commits each)
There's a backlog of work that contributors would like to get into FreeBSD; a limiting factor is availability of mentor and reviewer time to guide contributors through the process and iterating on bringing the code into a committable state.
Linux isn't purely GPL; it's GPL with an exception carved out for system calls.
I think that's an important distribution, because the userspace equivalent would be GPL with an exception carved out for dynamic linking (i.e. the LGPL).
This is the tale of Linux vs FreeBSD. Companies like Juniper that made heavy use of FreeBSD as the basis for JunOS have an atrocious history of failing to contribute their changes back to the community, and Juniper isn't the only one engaging in this behaviour. Sure there are other reasons that Linux took off and FreeBSD didn't, but license is a major factor in how their respective communities behave.
Yes, there are times when copying BSD licensed code is easier if you don't want to publish your source, but it isn't too difficult to adapt business processes to this constraint for the vast majority of applications. Look at what happened in the wireless router market. Early in the 2000s many products made use of the various vendors' Linux based SDKs and weren't compliant at publishing their source. Today OpenWRT is vibrant and most vendors offer GPL archive downloads on their websites. Personally, I don't think this would have happened if Linux wasn't GPLed and there wasn't the pressure the GPL afforded on vendors to open up their code.
I understand and respect John Carmack's position, and the GPL isn't for everyone, but people need to understand that license can result in significant differences in the viability of a community built around a software project on the longer term scales of 10-20 years.