Announcement

Collapse
No announcement yet.

Microsoft Keynoting LinuxCon, Continues Talking Up Linux/OSS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by Inopia View Post
    So NVIDIA has multiple layers of protection to cover their ass from the GPL.
    Yep. That same trickery has to be done on any project that mixes closed source and GPL, or the ones making the GPL project can start a legal battle.
    That's why most companies go with permissive licenses unless they are linux-only companies (like RedHat or SUSE), and have nothing to fear.

    Canonical is actually shipping ZFS as a complied module and argues there is no problem as it ZFS isn't a derivative work. I guess we'll wait and see if kernel devs do anything about it.
    kernel devs don't care. It's the companies that have contributed to kernel development that could go omnomnomnomnom on anyone that uses it if they feel like it would provide a benefit.

    Given that Canonical is:
    -always broke (never made a profit)
    -a MS sockpuppet (this is obvious to everyone)

    the risk of such legal issues are limited, there is little money to be had, and there is the risk of waking a giant on the sidelines.

    Oracle should have no problem as Canonical isn't claiming that they're relicensing ZFS.
    The violation is on the GPL side, ZFS license isn't broken.

    That said, Oracle does contribute to linux kernel development, so yeah they or anyone else can still pull an omnomnomnomnom like Oracle pulled with Google about Android Java apis. Did they do it straight away?

    Nope.

    They waited until it was the right time before attacking.

    Don't think that because companies cooperate on Linux they have any kind of morals. If they see profit in a legal battle, they will start it.

    Leave a comment:


  • Inopia
    replied
    Originally posted by starshipeleven View Post
    The real meat of NVIDIA's blob is the userspace blob that does what Mesa does for open drivers (providing OpenGL and other APIs to userspace), not the hardware driver that exposes the hardware at a low level.
    This blob only interfaces with the hardware driver, so it can be (and is) shipped as a blob without violating anything.
    So NVIDIA has multiple layers of protection to cover their ass from the GPL.

    Canonical is actually shipping ZFS as a complied module and argues there is no problem as it ZFS isn't a derivative work. I guess we'll wait and see if kernel devs do anything about it.

    Oracle should have no problem as Canonical isn't claiming that they're relicensing ZFS.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Inopia View Post
    If the driver was specifically written for Linux and had no other uses outside Linux the situation would be different.
    The nvidia blob needs to interface with kernel. It's that part that would theoretically violate GPL because it is a Linux kernel module (i.e. it becomes "part of the Program").
    And so it is compiled in the user's system, that part should theoretically become GPL according to license, and since it is never distributed in compiled form there is very little to claim violations.

    The real meat of NVIDIA's blob is the userspace blob that does what Mesa does for open drivers (providing OpenGL and other APIs to userspace), not the hardware driver that exposes the hardware at a low level.
    This blob only interfaces with the hardware driver, so it can be (and is) shipped as a blob without violating anything.

    Frankly I doubt there is enough for a honest legal battle. Sure if you have infinite cash you can try it and see what science-fictional bs the lawyers can fashion to get you to win vs the science-fictional bs NVIDIA lawyers fashion to protect NVIDIA.

    Leave a comment:


  • Inopia
    replied
    Originally posted by inopia
    Besides, is NVIDIA driver a derived work of the Linux kernel?
    Originally posted by ssokolow View Post
    In the eyes of the authors of the GPL, yes. The GPL was explicitly written with the intent that, unless your plugin/plugin-like code runs as a separate process, it's a derived work and must be released under a GPL-compatible license.
    Well they should've written it into the license then. The actual GPLv2 scope is limited to the Program and its derivative works. There is no mention about processes, plugins or address spaces even though they are usually used when talking about the GPL.

    Originally posted by GPLv2
    0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
    Originally posted by Wikipedia
    In copyright law, a derivative work is an expressive creation that includes major copyright-protected elements of an original, previously created first work (the underlying work).
    IANAL but it would seem very easy for NVIDIA to argue that their driver which works on multiple OSes and wasn't originally written for Linux isn't derived from the Linux kernel if anyone tried to take them into court. If the driver was specifically written for Linux and had no other uses outside Linux the situation would be different.

    It's also worth noting that Canonical uses this same interpretation to distribute ZFS+Linux as ZFS is self contained module which works on many OSes and was originally written for Solaris.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ssokolow View Post
    That's not EEE any more than it's EEE that I choose to build my VPS images using Linux rather than FreeBSD. It's just "Distros want certain features and lennartp offers the best of a bunch of shitty options". (And the "systemd gobbles everything up" is just a case of "almost nobody wants to work on this piece of the stack and the few people who do see working with systemd as a net positive.")
    Yes, I'm not a systemd hater, I was just pointing out that that is still pretty much a soft EEE, where they offer better alternatives, the alternatives get used (because they are better duh!), whatever was used before is abandoned.
    Sure being GPLv3 you can't really vendor-lock hard and ask for $$$ gangsta-style like MS would do, but they are still the main developers, so they still do have more power on where everyone is going (which does translate in more publicity/compatibility/$$$ for them and their stuff), as anyone that does not like what they make must pay $$$ to develop yet another shim or alternative.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by starshipeleven View Post
    And I said that GPL can be sidestepped easily enough for an EEE to work anyway. Hell, if you are hardcore enough you can pull a EEE with GPLed stuff alone like for example all the fuss with systemd or pulseaudio or even with Mir/Wayland (if they had more devs anyway).
    That's not EEE any more than it's EEE that I choose to build my VPS images using Linux rather than FreeBSD. It's just "Distros want certain features and lennartp offers the best of a bunch of shitty options". (And the "systemd gobbles everything up" is just a case of "almost nobody wants to work on this piece of the stack and the few people who do see working with systemd as a net positive.")

    See also "apulse" (exposes PulseAudio's API on top of ALSA for things like Skype) and "eudev" (Gentoo's systemd-less fork of udev).

    Originally posted by starshipeleven View Post
    I think the reason they don't GPL stuff is what I said above. They need to be able to integrate that software in closed-source stuff NOW and using GPL would make that a pain in the ass, and any mistake would risk forcing them to opensource other stuff too.
    I'll agree with you there.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ssokolow View Post
    As I remember, this all began with "Why doesn't Microsoft GPL anything?". What I've been saying is that the GPL was explicitly designed to enforce "software freedom", which is only compatible with EEE if Microsoft does a Canonical-style CLA setup where all contributors have to assign copyright so Microsoft can exempt their binaries from the GPL's "any GPL in it means it all must be GPL-compatible" provision. (The aspect that Ballmer called "viral", prompting people to then counter with "not viral, hereditary")
    And I said that GPL can be sidestepped easily enough for an EEE to work anyway. Hell, if you are hardcore enough you can pull a EEE with GPLed stuff alone like for example all the fuss with systemd or pulseaudio or even with Mir/Wayland (if they had more devs anyway).

    I think the reason they don't GPL stuff is what I said above. They need to be able to integrate that software in closed-source stuff NOW and using GPL would make that a pain in the ass, and any mistake would risk forcing them to opensource other stuff too.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Inopia View Post
    Besides, is NVIDIA driver a derived work of the Linux kernel?
    In the eyes of the authors of the GPL, yes. The GPL was explicitly written with the intent that, unless your plugin/plugin-like code runs as a separate process, it's a derived work and must be released under a GPL-compatible license.
    ​​​​
    Remember, this is the license designed by Richard Stallman, the man who believes it's wrong to run any non-libre (open-source being a less strict term) code at all unless it's explicitly for the purpose of reverse-engineering it to create a free software replacement and who founded the Free Software Foundation, and organization which has developed a prototype system where your browser can apply NoScript-like JavaScript controls based on whether an acceptable license header is detected on the JavaScript.

    Originally posted by starshipeleven View Post
    none of this is a major issue for a EEE. The thing that catalyzes the transformation is a plugin, an extension, not a whole new program.
    As I remember, this all began with "Why doesn't Microsoft GPL anything?". What I've been saying is that the GPL was explicitly designed to enforce "software freedom", which is only compatible with EEE if Microsoft does a Canonical-style CLA setup where all contributors have to assign copyright so Microsoft can exempt their binaries from the GPL's "any GPL in it means it all must be GPL-compatible" provision. (The aspect that Ballmer called "viral", prompting people to then counter with "not viral, hereditary")

    Leave a comment:


  • Guest
    Guest replied
    I haven't used Windows in almost a decade an a half now and I've been using Linux since the late 90s.
    But I would like to see Microsoft contribute to the Linux desktop. They won't but I would have liked to see them contribute.
    I don't buy into all the Linux fanboism and internet nonsense. It was only Microsoft management that attacked Linux. Plenty of Microsoft developers used Koffice and OpenOffice back in the days.
    I just believe Linux is a better platform than Windows.
    A large vendor such as Microsoft getting involved in Linux is good in my opinion.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ssokolow View Post
    The issue being that nVidia's workaround is technically a violation of the intended meaning of the text of the GPL... it's just that nobody cares enough to take them to court over it. Using that workaround more would increase the chances that someone would get taken to court.

    As for the subprocess approach, the issue there is performance. Even if you go with the idealized zero-copy, minimal context-switching IPC that kdbus wanted to be, you're still incurring a non-trivial amount of context switching... not to mention incurring possibly severe constraints on how your software is architected.
    none of this is a major issue for a EEE. The thing that catalyzes the transformation is a plugin, an extension, not a whole new program.

    Leave a comment:

Working...
X