Hacker News Reader

Comment by noorkersz | Hacker News Reader

step one: shift the focus from free software (liberty minded software) on to "open source" software. i.e. software which you can look but not touch.

step two: profit

View on HN

step one: promote BSD and MIT licenses over more copyleft licenses such as GPL

step two: profit from people willing to code for enterprises for free

There has to be some reason that Google released PyTorch under BSD-3 by Meta and TensorFlow being released under Apache by Google.

You forgot step 1.5: make contributing to open-source an unwritten rule to getting a job in the industry

Full disclosure: I got my current job before I had contributed anything to open source but I was asked a lot about it while applying to companies like it's expected that you work in your free time

I think in my entire time working I haven't met anyone who has significantly contributed to open source (aside from "let me fix some bug that's annoying me in a library"), so I'm not sure how required it really is

It varies on focus area. Most big OSS projects are infrastructural in nature, and so if you're working in that space there's actually a lot of engineers who you meet with OSS experience beyond fixing random bugs. Even then, for every OSS engineer doing big OSS contributions, there are many who never do, it's just the nature of the business. I know of just one hiring decision (out of hundreds and hundreds) that was made because of OSS contributions, and I know no interviewers who routinely checked OSS contributions beyond surface level.

open-source using permissive licenses + pressure to contribute = unpaid labor

No wonder Microsoft loves it.

Ah, this is a bit of a false one. (A)GPL's pretty great for things that look like applications (or alternatively, pretty much anything GNU's ever made), but for anything looking like a library that is designed to be both free as in speech and free as in beer (Qt is the former but not the latter - want commercial usage? Pay us for a differently licensed edition!) it's a complete non-starter because it says that any usage of a library is a derivative work and infects. This is always going to be poisonous to any commercial use, and PyTorch and Tensorflow only gained the traction they have because they could be used commercially - they wouldn't have been successful if GPL'd.

Even LGPL is super challenging here due to requiring dynamic linking. This is fine in Java (unless you use Graal AOT compilation) and Python, impossible in Go, and at best discouraged in other compiled languages like Rust and C++.

I think there's likely a copyleft middle ground - something like the Mozilla public license seems about right, where it copylefts improvements without infecting users. I don't know why Google chose Apache 2.0 over MPL or the like - for something like Android it makes sense, for something like Guava it's not clearcut. But, when people talk copyleft, they're rarely, rarely talking MPL.

I think it's unlikely that Google opensourced Tensorflow with a view to getting some free dev hours, they're doing it to push their OSS agenda, to wield influence over how everyone else does work.

This is entirely correct. Open sourcing tensorflow was about getting the world to use Google's stuff so that that stuff became more valuable / remained valuable / was possible to hire people with experience in it, not about getting people to work on it for free. The ratio of external to internal contributions is extremely small.

Google saw what happened with other of their technologies like map reduce (not open sourced, the world reinvented in Hadoop and the progress started happening there instead of in MR) and wanted to avoid becoming the bit player in a space they pioneered in. It's a reasonable strategy. (The risk is that you're giving away something that could be a competitive advantage.)

(worked on tensorflow at Google for four years.)

K8s another example. Kind of amazing that Google effectively owns the now-standard deployment solution off of 'we don't really use K8s but want you to build your applications like us and K8s is a bit like something we do use'. At least Tensorflow's actually what Google runs internally (to best of my knowledge)!

And what about Fuchsia? The primary value I see for it is that it looks like the un-Linux, especially in the license space.

Google really hates copyleft and the GPL.

I mean if Fuchsia ever starts getting used for production at some point by anyone, anywhere. Seems like more of a way to do systems research by Google than something designed for real world use.

If that was the case (an academic exercise in systems research, nothing for the real world), then arguably a strong copyleft license such as GPL would have been even better.

Nice to see MPL mentioned. I always find it strange MPL isn't used more, it's such a reasonable middle ground between AGPL and MIT/BSD.

Enterprises are (slower than I’d hoped) learning the value of contributing to the open source projects they use. More companies are establishing Open Source Program Offices and I expect the rate of contribution to go up. Most contribution from companies will go to software licensed under MIT/BSD/Apache.

US government policy is that software developed with public funding is a public good. Current policy encourages government software to released under the most permissive license possible (ideally Public Domain, but practically permissive licenses like MIT/BSD). GPL is farther from the Public Domain than licenses like MIT/BSD. To enter the rabbit hole of material on this topic start at https://code.gov/about/overview/introduction/.

Side note… the most interesting thing I learned today is that DoD (and probably other agencies) consider “Open Source Software” to be “Commercial Software”. This is a great development and likely means it will be much simpler to include OSS in make/buy trade studies. See “Is Open Source Software Commercial Software”, https://dodcio.defense.gov/Open-Source-Software-FAQ/#q-is-os...

> "open source" software. i.e. software which you can look but not touch

That's not remotely consistent with the way that term is used in practice...

> software which you can look but not touch.

This is "source available".

Open source software and free software are philosophically different but refer to mostly the set of programs (with two different but equivalent definitions [1,2]).

[1] https://opensource.org/definition

[2] https://www.gnu.org/philosophy/free-sw.html.en#fs-definition

> step one: shift the focus from free software (liberty minded software) on to "open source" software. i.e. software which you can look but not touch

I’m pretty sure when you say “look but not touch,” you’re talking about project governance, where outside contributors have limited input into the direction of the project. If that’s the case, I don’t like this conflation of governance and “freedom”. Google’s open source software is free software by all definitions (including FSF).

For a project to be open source or free software, users need to have the “four essential freedoms”. The ability to get your changes merged upstream is not one of those freedoms.

It is totally valid to criticize the corporate governance model of open source software. But it’s best not to confuse our already overloaded definitions by saying that corporate software with a free license isn’t really “free.”

Reply on news.ycombinator.com