[tsimionescu]

> Without GPL, as a company you take the code and if neccessary at some point, you employ somebody to further develop it in house (when maintainer gives up or something).

> Why pay and share and give that advantage to your competitors?

What companies have actually found is that collaborating on OSS infrastructure projects is extremely beneficial, essentially outsourcing some of the work to focus more on their unique selling points. This has happened more or less the same for GPL and more permissively-licensed projects.

Linux is the top example of a GPL project that has nurtured this type of commercial collaboration. Clang&LLVM is the top example of a non-GPL project which has achieved the same. Kubernetes is probably the second contender, and also non-GPL.

Ultimately I believe the GPL was an important step forward in getting companies to realize this type of business model can work. But it is much more of a hindrance today, since it brings about an awful lot of bureaucracy and ceremony when you need to combine it with proprietary code. So, I expect most collaborative OSS projects will continue to stay away from the GPL moving forward.

[throw0101b]

> What companies have actually found is that collaborating on OSS infrastructure projects is extremely beneficial, essentially outsourcing some of the work to focus more on their unique selling points.

I think there are examples of this in FreeBSD: after a company effectively forked the project, FreeBSD kept rolling forward—with bug fixes, updated drivers, etc. The company(s) had to maintain larger and larger internal diffs to get all of these improvements.

At some point they tended to just start giving back whatever wasn't their secret sauce and keep their own code as self-contained as possible. I think a popular workflow nowadays is to just track -CURRENT [1], and maybe branch when they cut a release of their own product.

[1] https://klarasystems.com/articles/evaluating-freebsd-current...

[ghaff]

A common take on this for a while has been that the GPL discourages certain types of freeloading while permissive licenses make (commercial, in particular) collaboration easier.

Linux, as you say, does provide an example of mass collaboration happening with a GPL license but it's unique in so many ways that I'm not sure it provides a very useful study point.

[goodpoint]

> while permissive licenses make (commercial, in particular) collaboration easier.

This is simply not true.

[mcdonje]

If GPL was a stepping stone, I'm curious where the possible future(s) of OSS licensing are. I only know the basics when it comes to licenses.

Forcing derivatives to be open source seems on the surface like a good way to provide a project with some protection against market forces while also helping to keep knowledge and development accessible to humanity.

Genuinely curious about pitfalls and other options.

[ghaff]

As I mentioned in another comment, permissive licenses (MIT, Apache, BSD) are generally seen as making collaboration, especially among commercial entities easier. There are fewer gotchas to merging products and otherwise pulling in code from different places. As a matter of policy, companies are generally more comfortable making use of permissively licensed code in their own software, even if it's intended for internal use.

So you're right that the GPL provides some safeguards about code being reworked into a proprietary product and kept closed. But a lot of the industry has come to see that the flexibility associated with more permissive licenses can outweigh that. (And there's been a general shift towards more permissive licensing. Most everything in the cloud-native open source space is permissively licensed. I believe the CNCF even requires this for projects under its umbrella.)

[pjmlp]

Sony contributions to FreeBSD shows how well it works, or the various compiler vendors thar now have clang forks, yet clang is now 3rd place in ISO C++ support.