5 ms·

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

by throwaway2048 10y ago

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.

chinhodado 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
      ARM still writes the drivers for the chip and then dosent update or open them up. Not much OEMs can do about that.
      - jordskott 10y ago
        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 10y ago
        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 10y ago
        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 10y ago
    > 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 10y ago
      I think you'll find the hundreds of millions in question were dollars, not people.
      - FireBeyond 10y ago
        You're almost certainly right. Oops!
scarface74 10y ago
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 10y ago
  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 10y ago
    Open source software has plenty of high profile security disasters too. Pretending otherwise is either ignorant or disengenuous.
    - wolfgke 10y ago
      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 10y ago
        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 10y ago
        At least it can be patched, if the equivilent bug occured in a closed source arm SoC driver, it would NEVER be patched.
simonh 10y ago
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.
jordskott 10y ago
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 10y ago
  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 10y ago
    Those are compilers. What open source CPU is there?
    - ajross 10y ago
      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 10y ago
        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.

chinhodado 10y ago

> 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 10y ago
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 10y ago
  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 10y ago
    ARM still writes the drivers for the chip and then dosent update or open them up. Not much OEMs can do about that.
    - jordskott 10y ago
      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 10y ago
        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 10y ago
      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 10y ago
  > 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 10y ago
    I think you'll find the hundreds of millions in question were dollars, not people.
    - FireBeyond 10y ago
      You're almost certainly right. Oops!

scarface74 10y ago

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 10y ago
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 10y ago
  Open source software has plenty of high profile security disasters too. Pretending otherwise is either ignorant or disengenuous.
  - wolfgke 10y ago
    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 10y ago
      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 10y ago
        At least it can be patched, if the equivilent bug occured in a closed source arm SoC driver, it would NEVER be patched.

simonh 10y ago

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.

jordskott 10y ago

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 10y ago
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 10y ago
  Those are compilers. What open source CPU is there?
  - ajross 10y ago
    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 10y ago
      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.