[throwaway2048]

One should keep in mind, this is true of basicly any software whatsoever. It ALL infringes on patents, nearly without exception.

There is always legal risk in open sourcing code. Infact there is legal risk from pretty much any action whatsoever. Good, responsible companies don't let that become a barrier to doing the right thing.

If ARM really cared, GPU stuff would be open source. The fact it isn't pretty strong indication they don't. Don't just accept it when lawyers say no.

After all AMD and Intel both have full open source graphics stacks, and the world hasnt exploded yet.

Should also be noted, keeping stuff closed source is not very strong protection against reverse engineering, if it was DRM would actually work, and it never really has, dispite decades of effort. So its doubtful that keeping stuff closed is much protection against patent lawsuits.

[simonh]

GPUs are hardware, not software. The patent situation there is much clearer. Critical hardware features of GPUs belong to different companies and the licenses for using those features often include highly restrictive licences for the code that drives them, or contractual obligations to use and not publish such code because doing so would reveal internal details of the hardware implementation of those features, which are trade secrets. Many drivers also load proprietary microcode into the CPU. AMD's 'Open Source' drivers do this.

Put simply, the GPU vendors do not actually own all the rights to their own driver software. AMD had a project to improve the state of their drivers on Linux, but the approach they took was to try and rewrite and open source the code implementing the public API to the closed binary blobs inside the drivers, to make it easier to maintain the stability of the drivers across kernel versions. Open sourcing the blobs wasn't possible for AMD because the code in them just doesn't belong to AMD.

>Don't just accept it when lawyers say no.

Which lawyers though? It's not necessarily ARM lawyers that are the problem. You'd need to get agreement from the dozens of patent holders of various bits of the technology, most of whom are unknown as their identities are confidential.

[scarface74]

Good, responsible companies don't let that become a barrier to doing the right thing.

Despite what Stallman would have you believe, open sourcing your own code is neither right nor wrong. It's just a choice.

[throwaway2048]

Its most definitely a quantifiable, collective wrong when that choice leads to a total security disaster like the embedded ARM situation. It might not be so bad if they bothered to update their drivers, but they dont even let other people try to do so.

[eridius]

Open source software has plenty of high profile security disasters too. Pretending otherwise is either ignorant or disengenuous.

[wolfgke]

Unluckily this is true. But there is a central difference: If such a security bug occurs in an open source software, you can in principle look for the bug source yourself to fix it to secure your computer to against attacks. If it is closed source, this is hardly possible or often such a self-defense is even illegal.

[scarface74]

In theory yes, but just to take one well known example, the HeartBleed SSL bug was introduced in 2012 but wasn't found until 2014.

[throwaway2048]

At least it can be patched, if the equivilent bug occured in a closed source arm SoC driver, it would NEVER be patched.

[jordskott]

Open sourcing commercial products like hardware architecture and algorithms to the public is not exactly an easy thing to do.

There are millions of registered patents and the chances that your clean-slate ideas were already invented and patented are really high.

Open sourcing means exposing patent infringements to the public (even if you are not really aware that you are infringing anything), which means that you need to invest on a strong legal team in order to go through all possible patents and to deal with all possible litigations you might face.

In order words, open source requires much more than ideals, it also requires butt loads of money.

[ajross]

Why has open source been so successful on the CPU then? Branch prediction, say, is no less a patent minefield than GPU framebuffer tiling. Yet gcc and LLVM have no trouble shopping optimizers.

This is an excuse, basically. They just don't want to because they fear revenue lost to compatible implementations.

[flamedoge]

Those are compilers. What open source CPU is there?

[ajross]

Uh... the GPU drivers we're talking about in this subthread are precisely "compilers" for the shader architecture (and configuration generators for the texture units and framebuffer layouts, etc...). In fact for architectures other than NVIDIA's the hardware-facing part of the linux driver already is open source.

The only secrets left are the bits responsible for turning OpenGL (or Vulkan now, I guess) calls into programs to run on the GPU.

[ethbro]

Wouldn't it be fair to say that GPU architectures (at least thus far) tend to change a helluva faster than CPU ones?

I can think of AMD adopting and then ditching VLIW for one.

[andor]

OpenSPARC T1 and T2 are open source and don't have out-of-order execution.

[sweden]

That's completely different, there is interest to expose your CPU architecture in order to help people write better compilers and better programs.

But on a GPU, the whole interaction between the GPU and the application is abstracted by APIs like OpenGL and Vulkan and you own the driver, you own the compiler, you own the implementation and you own the architecture. So companies tend to protect their "secrets" since they own the whole product.

If you are asking me why is it different... Ask these patent trolls instead:

- https://techcrunch.com/2014/09/04/nvidia-sues-samsung-and-qu...

- http://www.anandtech.com/show/11101/amd-files-patent-complai...

It's not an excuse, it's the sad reality.

[ajross]

And there is no interest in exposing your GPU architecture in order to help people write better compilers and programs?

Just as on a GPU, the whole interaction between the CPU and the application is abstracted by APIs[1] like C and Python.

[1] Yeah, we don't call them APIs. But then we don't call GLSL a "API" either. They're all languages.

[chinhodado]

> If ARM really cared, GPU stuff would be open source. The fact it isn't pretty strong indication they don't. Don't just accept it when lawyers say no.

Easy for you to say, harder when millions to hundreds of millions are at stake.

[throwaway2048]

Its always easier to be an armchair critic, but I bet there are more than hundreds of millions waiting for whoever can de-crappify the embedded ARM driver ecosystem.

Especially when this crap is at the root of why virtually every embedded linux product has serious security flaws that never get fixed. You cant update the kernel if you cant update the drivers.

[jordskott]

If there is a reason on why ARM's GPU drivers are not updated on your device, it's hardly ARM's fault. ARM doesn't ship the SoC or the device directly to you, it ships it to the OEM. And it's the OEM who states the agreements.

If you want to blame someone, starting by blaming the OEM.

[throwaway2048]

ARM still writes the drivers for the chip and then dosent update or open them up. Not much OEMs can do about that.

[jordskott]

But ARM cannot, and won't, officially support the OEM's devices and start releasing updates for them. The process is a bit more complex than you might be imagining.

[throwaway2048]

It still has to start at the top, and if they did update their drivers at least open source projects could then update on said platforms instead of being stuck on a 5 year old kernel till the end of time.

[dogma1138]

ARM has a reference design which includes drivers. The OEM is responsible for the final design and validation. ARM cannot take responsibility for validating 1000s of implementations that vary in both hardware and software configurations and validate them for billions of devices. Neither can the FOSS community. For the handful of boards which are popular enough to have sufficient tracking for the FOSS community to take the wheel if an open source driver was available the OEM has sufficient incentive to support their platform. For the other 4,999,999,990 LowHo NiHao industries unbranded boards it wouldn't matter in the first place.

[FireBeyond]

> but I bet there are more than hundreds of millions waiting for whoever can de-crappify the embedded ARM driver ecosystem.

Hyperbole much? 7 billion people on the planet, and "more than hundreds of millions" of them are waiting with bated breath for the "de-crappification of the embedded ARM driver ecosystem"?!?

[tux1968]

I think you'll find the hundreds of millions in question were dollars, not people.

[FireBeyond]

You're almost certainly right. Oops!