5 ms·

Your claim that OSS is effectively proprietary software immediately loses half your audience, because most people in the OSS camp have the opposite experience (

Your claim that OSS is effectively proprietary software immediately loses half your audience, because most people in the OSS camp have the opposite experience (that FSF leads to monopolistic SaaS companies spying on you). I'm not saying either tribe is right, so let's skip past the tribalism. What we need is not new OSS/FSF, what we need is new economic models that are capable of measuring the value of OSS/FSF. Here is an extensive treatise to fix all of this: https://hackernoon.com/wealth-a-new-era-of-economics-ce8acd785441 https://hackernoon.com/wealth-a-new-era-of-economics-ce8acd7...

mindslight 8y ago
I wasn't saying that OSS is itself equal to proprietary software, but that it often ends up affiliated with non-free products. Products which then shamelessly continue using the OSS image to foster goodwill, even though their end users are far from having Freedom. > that FSF leads to monopolistic SaaS companies spying on you Erm, what? Both BSD and GPL software are similarly vulnerable to being transmuted into SaaS. This isn't an argument about specific licenses per se. What I'm calling out is "openwashing" in general. The FSF at least has an intellectual framework to analyze this. You don't need to license your work as GPL, but you do need to think ahead about the users of your software. Imagine using a derivative of your own work, suffering an annoying bug that you know precisely what it is, and yet being unable to fix it because a middleman has prevented you from doing so.
- marknadal 8y ago
  Ah, that makes more sense. Good point, thanks! I think that is a fair concern, but personally I'd much rather give my users unrestricted abilities to use my code, because I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code. I also see the same that any OSS-version would outcompete (a)GPL-version, though I'm sure you disagree?
  - mindslight 8y ago
    Yes, I believe perfectly efficient markets are analogous to P == NP.
  - floe 8y ago
    > I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code I'm worried that you face a forever-uphill climb. Whenever a proprietary group pulls ahead by developing some killer feature or improvement, your OSS group has to duplicate all of their work. Whereas if your OSS group pulls ahead, they can just fork you and put all their energy into pulling ahead again. I think this analysis is a good argument for why you might want to put restrictions on those who would take advantage of your community's work. (Of course, it's important that the restrictions actually work and aren't burdensome to those who don't want to take advantage of you. Whether the GPL or any other license succeeds at that is debatable.)
    - int_19h 8y ago
      When you own the entire vertical, all the way to end user, it makes sense. In practice, the final steps that are necessary to deliver something useful to the user are often considered the most boring and tedious (UI, documentation etc), so many F/OSS projects either don't bother at all, or provide something half-baked. But if the underlying libraries allow for a proprietary derivative, then that might motivate some businesses to come and do all that tedious stuff for $$$. Such businesses might not contribute back much, but they are also unlikely to fork - less code to maintain that way. When that happens, I don't think it's a loss for anybody, really. The open code stays open and can be improved further, and it also gets used by more people in better ways. Some would argue that library developers aren't properly compensated, but the act of voluntarily releasing something under a non-copyleft license is explicit consent to that. In the hypothetical "suffering an annoying bug" scenario, I would, of course, prefer to have the source so that I can fix it. But if the real choice is between having a product with an annoying unfixable bug (but plenty of other added value), and not having one at all, because nobody wants to build my extremely useful GPL'd library into a polished product, the obvious pragmatic choice is the bug.

mindslight 8y ago

I wasn't saying that OSS is itself equal to proprietary software, but that it often ends up affiliated with non-free products. Products which then shamelessly continue using the OSS image to foster goodwill, even though their end users are far from having Freedom. > that FSF leads to monopolistic SaaS companies spying on you Erm, what? Both BSD and GPL software are similarly vulnerable to being transmuted into SaaS. This isn't an argument about specific licenses per se. What I'm calling out is "openwashing" in general. The FSF at least has an intellectual framework to analyze this. You don't need to license your work as GPL, but you do need to think ahead about the users of your software. Imagine using a derivative of your own work, suffering an annoying bug that you know precisely what it is, and yet being unable to fix it because a middleman has prevented you from doing so.

marknadal 8y ago
Ah, that makes more sense. Good point, thanks! I think that is a fair concern, but personally I'd much rather give my users unrestricted abilities to use my code, because I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code. I also see the same that any OSS-version would outcompete (a)GPL-version, though I'm sure you disagree?
- mindslight 8y ago
  Yes, I believe perfectly efficient markets are analogous to P == NP.
- floe 8y ago
  > I believe that any proprietary-tech built on my code will not be able to compete in the end game with any also OSS-tech built on my code I'm worried that you face a forever-uphill climb. Whenever a proprietary group pulls ahead by developing some killer feature or improvement, your OSS group has to duplicate all of their work. Whereas if your OSS group pulls ahead, they can just fork you and put all their energy into pulling ahead again. I think this analysis is a good argument for why you might want to put restrictions on those who would take advantage of your community's work. (Of course, it's important that the restrictions actually work and aren't burdensome to those who don't want to take advantage of you. Whether the GPL or any other license succeeds at that is debatable.)
  - int_19h 8y ago
    When you own the entire vertical, all the way to end user, it makes sense. In practice, the final steps that are necessary to deliver something useful to the user are often considered the most boring and tedious (UI, documentation etc), so many F/OSS projects either don't bother at all, or provide something half-baked. But if the underlying libraries allow for a proprietary derivative, then that might motivate some businesses to come and do all that tedious stuff for $$$. Such businesses might not contribute back much, but they are also unlikely to fork - less code to maintain that way. When that happens, I don't think it's a loss for anybody, really. The open code stays open and can be improved further, and it also gets used by more people in better ways. Some would argue that library developers aren't properly compensated, but the act of voluntarily releasing something under a non-copyleft license is explicit consent to that. In the hypothetical "suffering an annoying bug" scenario, I would, of course, prefer to have the source so that I can fix it. But if the real choice is between having a product with an annoying unfixable bug (but plenty of other added value), and not having one at all, because nobody wants to build my extremely useful GPL'd library into a polished product, the obvious pragmatic choice is the bug.