4 ms·

It's true that we don't have any definitive data on this. But I buy the article's argument that upstreaming a patch once is simply cheaper than maintaining you

It's true that we don't have any definitive data on this. But I buy the article's argument that upstreaming a patch once is simply cheaper than maintaining your own proprietary fork forever. It externalizes the efforts of maintaining it in the future. This means that public, community-maintained, permissively-licenced projects are a good deal for companies, and should win from the economic / game theory POV

ltbarcly3 1y ago
If this is correct then the lgpl would be ideal? Also, it depends how much value-add they see their modifications having. For small tweaks and bug fixes they'll contribute it. If they invest a lot of money into something, they'll be loath to hand that value over to their competitors. There is some tipping point where the competitive value (or more realistically the jealous urge not to share) of their efforts exceeds the utility of easy tracking with upstream changes.
- Expurple 1y ago
  Ideal for whom? It's still not ideal for downstream proprietary developers. The requirement to provide some means to relink the project is extra headache that can be avoided by using permissive dependencies, reinforcing the point of the article. Also, in theory, I can imagine a situation where a proprierary developer strongly needs to make a change, and for some reason is strongly against open-sourcing it, and is strongly law-abiding. And thus, a proprietary rewrite is born. Sometimes, instead of a complete rewrite, that's going to be a fork of a permissive project, boosting its usage and reinforcing the point of the article. For library authors, LGPL/MPL is often a good tradeoff, indeed. You still get all the modifications back, while also having more users then you would have with GPL. Although, as seen in this thread, enabling proprieraty dependents is actually a downside for some authors, due to their beliefs. To me, it looks like LGPL/MPL become irrelevant in the "longer" run too. --- I agree with you regarding the "tipping point". There's nothing we can do about this. In a similar vein, when considering a massive investment into a GPL project, they are going to conclude that they are better off invesing a similar amount into a proprietary rewrite and keeping the added value to themselves.
  - ltbarcly3 1y ago
    They might decide to rewrite an lgpl project, but there is a massive sunk cost. At the point they make the decision the gpl project is less tempting to bring fully in house. (L)GPL: - Investing $3M to extend. - Would cost $17M and 3 years to re implement to baseline and then extend. - Lose all community development inputs because new solution is fully in house. Permissive: - Investing $3M to extend. - Would cost $0 and 0 years to keep in house and still extend - Keep 100% of community development inputs initially and potentially forever if they are able to extend in a way that avoids conflicts. Can port most community developed features with some effort. Corporations make decisions 1 quarter and at most 1 year ahead. It's a very hard sell to say "we need to take 3 years and a huge investment to get to where we already are at". It could happen for some very specific, high value technologies where someone at the Sr. Director or VP level is taking a long view , but it would be extremely rare.
    - Expurple 1y ago
      Ok, I have thought more about the topic. You're right. LGPL/MPL have amazing survival characteristics. Probably better than those of permissive licenses. See my other comment: https://news.ycombinator.com/item?id=44657017 https://news.ycombinator.com/item?id=44657017
ColonelPhantom 1y ago
I feel like a massive counterexample here is embedded. Hardware companies tend to laugh at maintenance (it's expensive and extends the life of their products, so you don't have to give them money as often). If Linux was not GPL, many embedded platforms like routers or smartphones would not have kernel code available.
- Expurple 1y ago
  That's a good counterexample! If you don't need to maintain the code, then a proprietary fork has no maintenance cost and will be preferred. I guess, the atricle still stands where you need to maintain the code.

ltbarcly3 1y ago

If this is correct then the lgpl would be ideal? Also, it depends how much value-add they see their modifications having. For small tweaks and bug fixes they'll contribute it. If they invest a lot of money into something, they'll be loath to hand that value over to their competitors. There is some tipping point where the competitive value (or more realistically the jealous urge not to share) of their efforts exceeds the utility of easy tracking with upstream changes.

Expurple 1y ago
Ideal for whom? It's still not ideal for downstream proprietary developers. The requirement to provide some means to relink the project is extra headache that can be avoided by using permissive dependencies, reinforcing the point of the article. Also, in theory, I can imagine a situation where a proprierary developer strongly needs to make a change, and for some reason is strongly against open-sourcing it, and is strongly law-abiding. And thus, a proprietary rewrite is born. Sometimes, instead of a complete rewrite, that's going to be a fork of a permissive project, boosting its usage and reinforcing the point of the article. For library authors, LGPL/MPL is often a good tradeoff, indeed. You still get all the modifications back, while also having more users then you would have with GPL. Although, as seen in this thread, enabling proprieraty dependents is actually a downside for some authors, due to their beliefs. To me, it looks like LGPL/MPL become irrelevant in the "longer" run too. --- I agree with you regarding the "tipping point". There's nothing we can do about this. In a similar vein, when considering a massive investment into a GPL project, they are going to conclude that they are better off invesing a similar amount into a proprietary rewrite and keeping the added value to themselves.
- ltbarcly3 1y ago
  They might decide to rewrite an lgpl project, but there is a massive sunk cost. At the point they make the decision the gpl project is less tempting to bring fully in house. (L)GPL: - Investing $3M to extend. - Would cost $17M and 3 years to re implement to baseline and then extend. - Lose all community development inputs because new solution is fully in house. Permissive: - Investing $3M to extend. - Would cost $0 and 0 years to keep in house and still extend - Keep 100% of community development inputs initially and potentially forever if they are able to extend in a way that avoids conflicts. Can port most community developed features with some effort. Corporations make decisions 1 quarter and at most 1 year ahead. It's a very hard sell to say "we need to take 3 years and a huge investment to get to where we already are at". It could happen for some very specific, high value technologies where someone at the Sr. Director or VP level is taking a long view , but it would be extremely rare.
  - Expurple 1y ago
    Ok, I have thought more about the topic. You're right. LGPL/MPL have amazing survival characteristics. Probably better than those of permissive licenses. See my other comment: https://news.ycombinator.com/item?id=44657017 https://news.ycombinator.com/item?id=44657017

ColonelPhantom 1y ago

I feel like a massive counterexample here is embedded. Hardware companies tend to laugh at maintenance (it's expensive and extends the life of their products, so you don't have to give them money as often). If Linux was not GPL, many embedded platforms like routers or smartphones would not have kernel code available.

Expurple 1y ago
That's a good counterexample! If you don't need to maintain the code, then a proprietary fork has no maintenance cost and will be preferred. I guess, the atricle still stands where you need to maintain the code.