Second thing is that's its much easier to ask open source aware HN reader for $50 than a huge megacorp hive mind for 50c. Not to mention every 'end user dollar' is worth much more for the foundation given the regulations, where to keep the tax status we need to show up numbers supporting in people, rather than businesses.

And finally, many of these companies do give us money and code, some in the open, some anonymously due to the reasons known only to them.

Just a food for thought for you when you'll be thinking about these donations :)

I do donate to FreeBSD regularly - in fact, I have a matching paycheck donation set up. But that's because I personally use it in my projects. When it comes to Netflix, I already pay for Netflix, so the notion that I should also pay to FreeBSD because it makes Netflix possible is kinda ridiculous.

https://openconnect.netflix.com/en/software/ "All code improvements, feature additions, and bug fixes are contributed directly back to the open source community via the FreeBSD committers on our team. We also strive to stay at the front of the FreeBSD development process, allowing us to have a tight feedback loop with other community and partner developers."

WhatsApp has also contributed monetarily and with software. You need to know that Facebook only recently bought WhatsApp.

Coming up on almost 4 years now since the WhatsApp acquisition was announced (Feb 2014) and over 3 years since the acquisition closed (Oct 2014). [1] [2]

I wouldn't call either date "recently"

[1] http://money.cnn.com/2014/02/19/technology/social/facebook-w...

[2] https://www.bloomberg.com/news/articles/2014-10-28/facebook-...

[1] https://www.freebsdfoundation.org/donors/

[2] https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf

That's the free rider problem, one that the GPL (and the AGPL) was designed to avoid.

It's true that many of those companies which use FreeBSD wouldn't touch a GPL codebase (and all the more so an AGPL codebase), but that't the point - while some chose FreeBSD because it's fast/stable (NF and WhatsApp), others chose it because they don't have to contribute back.

All of this free, open, etc. software works in part because of a "pay it forward" approach to the community. If people shame big users for not "paying back" enough, rather than finding more productive means of encouragement, the whole system of free tools becomes less tenable because future users will pick other tools that don't have PR risk attached.

Nothing they've built in their stack would translate to an Xorg driver, beyond the kernel shim (the smallest and simplest portion of the code, in most video drivers).

There is nothing wrong with porting from Linux.

We have a compatibility layer for Linux drivers in the kernel (LinuxKPI), so the GPU drivers are not modified that much. A lot of work on LinuxKPI has been sponsored by Mellanox, by the way :) since it's also used for their network drivers (mlx4/5).

And it works fine, I'm currently writing this from a PC with an RX 480 running FreeBSD 12-CURRENT. DRI3, Wayland, Vulkan — everything works.

Also, the Sony driver would've been completely irrelevant to desktop systems. It supports one specific GPU model, Sony proprietary APIs, probably nothing in terms of KMS/DRM/GBM/EGL!

One is that the users of *BSD's aren't donating to the development, despite enjoying its fruits. GPL will never help here.

The other is about not having to give your changes to the project itself back (bug fixes or features). GPL helps here. However, your examples do not apply to this bucket: Sony's fancy graphics driver can just be a closed-source out-of-tree driver, which would be perfectly compliant with GPL. This is why we have closed-source graphics drivers on Linux.

I personally love open source, and greatly dislike GPL. I prefer the Apache licenses (open but legally explicit), but am completely okay with BSD/MIT.

This is a loophole with the GPL, not the way it is intended to be used. It is far from clear if this is even legal. The Linux developers are split on the issue, but no one seems to care enough to press charges.

If having GPL-licensed code execute non-GPL binary components violates the license, then it would be a license violation to execute any binary that is not GPL-licensed on such an operating system running a GPL-licensed kernel. Such a limitation would be absurd.

From a high-level, project-agnostic perspective, there is no difference between a kernel module and an application binary—they are both external binary blobs with the intention to extend the functionality of the initial project (in this case the Linux kernel). The differences are low-level and kernel-specific (kernel- vs. user-mode, API availability, intended functionality). The GPL does not distinguish between a printer driver or a calculator application.

Another aspect would be the use of a GPL-licensed header file. However, coming to the conclusion that using an untouched header-file (which usually only contains an API surface) from a GPL-licensed project taint code to require GPL-license for compliance would have huge consequences. Many projects would be rendered in violation overnight. This would likely hurt GPL.

And yet, having Linux being GPL must have given incentive at some point to give code back since nowadays both Intel and AMD have very good GPL'ed drivers.

Having open source drivers grant Intel and AMD at least the following:

1. Free work on their drivers. Who wouldn't benefit from bug fixes and improvements to the graphics drivers of extremely popular graphics cards? In other words, it reduces cost.

2. Good marketing. There is only a very small group of people who are twisted enough to think that open source is a bad thing. There is a much larger group that see it as a positive thing (and then there's the group that doesn't care at all). In other words, it increases sales.

3. Greater ability to mold the Linux kernel to better accommodate their drivers and needs. Even though a company can send patches to the kernel that would help their closed-source drivers, if they only help closed-source drivers, they are very unlikely to be accepted. On the other hand, any sane change that would help an in-tree driver would be accepted without question. In other words, it increases flexibility.

None of this relates to GPL (the drivers are probably only GPL because GPL forces the in-tree drivers to be GPL), and the same logic applies to *BSD's. The reason we don't have good graphics drivers on BSD is likely because it takes a lot of effort to write one. If it isn't going to affect revenue, Intel and AMD are unlikely to care.

By the way, amdgpu does not appear to be GPL, just GPL compatible. https://github.com/wkennington/linux-firmware/blob/master/LI...

I am a Free Software Foundation (FSF) member because I believe that end-user freedoms are becoming increasingly under threat as of late and they appear to be among the few that are taking the problem seriously.

The relevance of the original code can be taken away, for example by hijacking a standard or through control of APIs and/or hardware. Will anyone be able to buy hardware in 10 years time that will not be under the full control of a corporation?