Hacker News Reader

Comment by cwp | Hacker News Reader

No, that's not the goal of open source, obviously. In my case, the goal is to let as many people as possible benefit from my labour. I have no problem with businesses using my code to make money and not paying me a dime. It's happened a few times. The end consumers got better software as a result. It wouldn't have been possible with the GPL, which is why I use MIT.

I get that the FSF sees it differently, but honestly I don't see how the GPL helped anyone in the case of Apple and bash. It's not like Apple was making significant changes to bash, refusing to contribute them back and making a fortune on the backs of the FSF. Are contributors to the zsh project being exploited by Apple's evil plan to put their work in the hands of many more users? If I find a bug in my Apple-supplied copy of zsh, am I prevented from fixing it like RMS and the printer driver? No.

View on HN

> In my case, the goal is to let as many people as possible benefit from my labour ... The end consumers got better software as a result

That is your prerogative for your own software. FSF's goal, likely shared by the author when they picked the license, is not and has never been the maximal popularity of their own software. You may not like their goal or see it as valuable, which is a reasonable question of values, but that does not make their strategy poor for achieving what they care about, which, I repeat, is not "popularity," nor even "better software for end users," strictly speaking. Confusion arises when people subconsciously project their own goals/values on FSF and then evaluate FSF's strategy under that pretense. GPL is a very effective tool for accomplishing what FSF wants, and the trade-off with popularity is very much deliberate, not some surprising side effect.

> No, that's not the goal of open source,

That is the goal of FSF opensource projects - protect the rights of the developers and users to review and modify code.

> The end consumers got better software as a result.

I disagree. If they don't have access to the accompanying source code, it is an inferior product.

> I don't see how the GPL helped anyone in the case of Apple and bash.

Thanks to FSF license, any user can ask the distributor to provide the source code of an FSF licensed app. In our example, that's Apple and they cannot refuse to give you the source code of bash along with the modifications they have made. Which brings me back to the point that needs to be emphasised - GPL and other FSF license was not designed to help businesses and corporates. It's aim is to ensure the freedom of developers and user to review and modify code is preserved.

> If I find a bug in my Apple-supplied copy of zsh, am I prevented from fixing it like RMS and the printer driver? No.

Yes, if Apple refuses to give you the source code of their customised zsh, then you are indeed being prevented from fixing any bug or adding any new feature! I hope you finally understand - FSF license ensures that Apple (or anyone else) cannot refuse you the source code. Other opensource license don't come with such guarantees.

> If they don't have access to the accompanying source code, it is an inferior product.

I agree with the overarching preference for GPL over MIT, but this point is one of the most insular HN-bubble comments I've seen since the Dropbox comment. Most users – hell, most developers – do not give a toss about having the source code for software that's shipped with MacOS. I have never spoken to anyone who's wanted or needed the source code for Bash or Zsh.

There's a big difference between wanting personal access to the source code and wanting to know that the source code is available should the need or desire ever arise.

I've been developing FLOSS for several decades now, but I rarely compile stuff from source anymore (except my own projects). However, the availability of the source code for the tools I use is very important to me, even if I never exercise it myself.

In addition, general access to the source code is important as a learning tool for programmers, if only "to see how it's done". You may never build such code, but being able to take a look at it can be an important foundation in the continuing education of software developers.

Like I said to the other commenter, the source code for the software being discussed already is available - by definition - and much more easily than if you had to go searching through /usr/lib. It's an absolutely moot point[0] whether Apple bundles the source code for Bash into their operating systems, for 99.99999% of intents and purposes and users.

We're not discussing whether the source code for XNU/Darwin/Mach/MacOS itself ought to be open, which is another question entirely. (Obviously everyone would sooner it be open than not open, in a first-order analysis, but, as with medical patents and the like, a proper analysis would have to ask whether it would even have existed if its source code were to be open.)

[0] Or rather a non-moot point, for the pedants.

>[ ... ] as with medical patents and the like, a proper analysis would have to ask whether it would even have existed if its source code were to be open.

The overwhelming majority of XNU/Mach was created as open source. It is quite unlikely that macOS would exist today if those components had not been created under an open source license.

> Like I said to the other commenter, the source code for the software being discussed already is available

I was replying to this remark:

> Most users – hell, most developers – do not give a toss about having the source code for software that's shipped with MacOS.

> but this point is one of the most insular HN-bubble comments I've seen...I have never spoken to anyone who's wanted or needed the source code for Bash or Zsh.

It might be in-bubble, but "I have never spoken to anyone who..." is a poor heuristic for evaluating the superiority/inferiority of a product.

I have also never spoken to anyone who needed a repair manual for a truck, but I can probably agree with the statement that truck companies that publish comprehensive repair manuals are better than truck companies that don't.

Similarly, I can guess having the source for bash or zsh probably helps people who work with them more closely than I do.

> It might be in-bubble, but "I have never spoken to anyone who..." is a poor heuristic for evaluating the superiority/inferiority of a product.

∃x→¬P(x) is a poor response to ∃x→P(x), but a good response to ∀x→P(x). In this case, the parent commenter was claiming - in context - that all end users need or benefit from having the source code to their software, so it is relevant to say that that statement is true of absolutely nobody I know.

If he were making the abstract statement that publishing the source code might benefit some people, that would be another thing. In reality, I don't think it makes any difference whether Apple bundles the source code to these programs, when the source code, by definition, is openly available, and can be accessed much more easily by Googling it much more quickly and easily than by searching for it somewhere in /usr/lib.

It'd be really great for the Nix project if up-to-date sources for what comes on macOS were available. Probably for MacPorts, too, and maybe even Homebrew.

If source code were available for the end-user applications that come with macOS, I'd give them a try, too.

My reasoning is simple - access to the source code preserves your right to repair. Since closed-source application deny that, they are inferior.

Reply on news.ycombinator.com