Hacker News Reader

Comment by peschu | Hacker News Reader

I don't know if your underlying assumption holds at all.

In the end the GPL resolves these issues and enforces stuff. Obviously most companies don't want that for different reasons.

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?

The key to open source is when governments develop policies for using open source instead of paying licenses for proprietary software and maybe pressure from customers to companies which use open source software.

But average people don't know and don't care at all about open source ... :(

View on HN

> 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.

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.

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

This is simply not true.

> 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...

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.

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.)

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.

> 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).

You can do that with GPL too.

maybe not about OSS, but they know and care about freedom, and I think we are gonna have to really understand how open source and free software are connected as a matter of principle; beyond their origin stories.

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

this is the essence of the issue;

we gotta understand why society is often seen through such adversarial lenses?

this question ("why adversarial thinking?") though asked rhetorically, has a good answer which is important to understand, as well as a bad answer which is also important to understand.

I've chosen to consider this question without fully answering; but by thinking about the notion of 'identity', what makes me be in this or in that group such that 'who are our competitors?' is not so simple to answer.

The GPL doesn't enforce stuff, only large amounts of lawyers fees can do that. Plenty of companies violate the GPL with zero consequences. Same goes for permissive licenses TBH.

Reply on news.ycombinator.com