Announcement

Collapse
No announcement yet.

Bickering Continues About NVIDIA Using DMA-BUF

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

  • Originally posted by joe_gunner View Post
    Seriously why the fuck not just dual-license the related code? Certainly that won't involve permissions from more than a couple of programmers and save everyone some trouble, but for that Alan Cox would have to take his and Stallmans cox out of his own mouth.
    Impossible. It's part of the kernel. Kernel is GPL. The only way to relicense it would be to remove it from the kernel.

    Comment


    • Originally posted by johnc View Post
      Alan wasn't the original author of the code. And in fact it was initially written EXPORT_SYMBOL, and was only later changed -- presumably without the consent of all involved.

      Whether there's really a difference between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL is pretty tenuous, and NVIDIA is probably already accessing EXPORT_SYMBOL code.

      From what I understand, NVIDIA has a sign-off from most of the people involved... just Alan and one or two others are simply saying that NVIDIA should consult their lawyers [because they would be presumably violating the license]. Not that any of that means the patch will be accepted.


      Now I see why Sun released all their stuff under the CDDL. One so they don't have to deal with GPL bullshit, and two just so they can stab a fork in the eye of these Stallman nuthuggers.
      And what you don't understand is that the affected code is derived from linux kernel. Thus Alan and others have no saying here. Don't like this "GPL bullshit"? Use something else! Maybe one of the BSDs? They must have much better blob drivers with their more permissive license, dont they? ROFL.

      Comment


      • Originally posted by log0 View Post
        And what you don't understand is that the affected code is derived from linux kernel. Thus Alan and others have no saying here. Don't like this "GPL bullshit"? Use something else! Maybe one of the BSDs? They must have much better blob drivers with their more permissive license, dont they? ROFL.
        Code:
        alex@Sylbit ~/Develop/Repos/Git $ find ./freebsd-head/sys/ -name \*.uu |wc -l
        36
        (or simply ./freebsd-head/ if you also want to count non-driver/non-firmware thingies)

        Compared to : http://linux-libre.fsfla.org/pub/lin...re-3.6-gnu.log

        Get your numbers straight.

        Regards.

        Comment


        • Originally posted by log0 View Post
          And what you don't understand is that the affected code is derived from linux kernel. Thus Alan and others have no saying here. Don't like this "GPL bullshit"? Use something else! Maybe one of the BSDs? They must have much better blob drivers with their more permissive license, dont they? ROFL.
          For some reason, kernel<>userland interface is exempted from GPL (probably someone sane realized that making ALL Linux software derivative works - as it would be if GPL didn't have exceptions - means not getting some software for the platform, ever). I don't see how establishing a well-defined binary kernel<>drivers interface and exempting it from GPL is not possible. Basically, just add a jump table (pretty much what int 80h handler is) and since it constitues an API, it can't be copyrighted.

          Comment


          • Originally posted by pingufunkybeat View Post
            I was only trying to help you. If you can't get acceleration working, ask somebody more technically inclined.

            No need to get all angry and all...

            Acceleration working is not the matter on Nouveau/prime. I have a pretty good supported Fermi GPU and Nouveau runs nice indeed. Problem is, that a workaround as bumblebee/blob using virtualgl copying stuff from/to a 2nd Xserver is faster. dma_buf/blob would run circles around dma_buf/nouveau.
            Now Amonakov's Primus is ready to use, giving another 30%-100% percent boost, so why should I use nouveau? To bake bread on my laptop?

            Comment


            • Originally posted by RCL_ View Post
              For some reason, kernel<>userland interface is exempted from GPL (probably someone sane realized that making ALL Linux software derivative works - as it would be if GPL didn't have exceptions - means not getting some software for the platform, ever). I don't see how establishing a well-defined binary kernel<>drivers interface and exempting it from GPL is not possible. Basically, just add a jump table (pretty much what int 80h handler is) and since it constitues an API, it can't be copyrighted.
              I was just wondering the same thing, what's the problem in this?

              Comment


              • Originally posted by RCL_ View Post
                For some reason, kernel<>userland interface is exempted from GPL (probably someone sane realized that making ALL Linux software derivative works - as it would be if GPL didn't have exceptions - means not getting some software for the platform, ever). I don't see how establishing a well-defined binary kernel<>drivers interface and exempting it from GPL is not possible. Basically, just add a jump table (pretty much what int 80h handler is) and since it constitues an API, it can't be copyrighted.
                The GPL cannot decide whether something is a derivative work or not nor does the copyright holder, however the copyright holder of the original work can decide what licensing terms apply to the usage of their code. Considering that Linux's int 0x80-API is just a standard Unix-API, it's likely that a userland app is not a derivative work of the kernel. If that is indeed the case, then no exemption will be necessary when it comes to the kernel<>userland interface.

                Comment


                • Originally posted by mememe View Post
                  Considering that Linux's int 0x80-API is just a standard Unix-API, it's likely that a userland app is not a derivative work of the kernel. If that is indeed the case, then no exemption will be necessary when it comes to the kernel<>userland interface.
                  By that reasoning, it should be possible to create something like NDIS-wrapper for all the binary drivers (reimplementing "just a standard" Windows driver API or FreeBSD one or whatever) and circumvent GPL altogether.

                  I don't see why unprivileged code can have whatever license it wants while privileged code cannot.

                  P.S. I believe that Linux's 0x80h interface is not "just a standard Unix API". Either way, Linux changed it when moving to x64 and the API still remained exempted.

                  Comment


                  • Originally posted by christian_frank View Post
                    you are such a closed minded zealot ! amd gives specs , how well does the opensource driver work compared to the amd or nvidia blob ? do you really think specs would change the situation for noveau that mutch ?even with specs it would take years to be on par with the blob !

                    users simply need the blob for everything more than basic 2d usage . And nobody buys an optimus laptops for that purpose ! alan cox move is a hit in the face for linux users . that's a fact .
                    For me personally Mesa Radeon drivers are working really good while Fglrx are basically unusable (dual head setup). The fact I don't have to recompile them every time I upgrade a kernel is an added benefit. So yes, releasing specs did actually change the situation for better.

                    Comment


                    • Originally posted by RCL_ View Post
                      By that reasoning, it should be possible to create something like NDIS-wrapper for all the binary drivers (reimplementing "just a standard" Windows driver API or FreeBSD one or whatever) and circumvent GPL altogether.

                      I don't see why unprivileged code can have whatever license it wants while privileged code cannot.

                      P.S. I believe that Linux's 0x80h interface is not "just a standard Unix API". Either way, Linux changed it when moving to x64 and the API still remained exempted.
                      Yeah, but then we could just use ReactOS or FreeBSD instead of Linux. The point is that
                      1. the API that Linux exposes to the userland is pretty much a standard set of Unix system calls like open, write, ioctl, select
                      2. the system call API marks a definite interface between the kernel and the user mode
                      3. it is indeed possible to run certain Linux programs under operating systems that come with a reimplementation of the Linux system call API + ABI (I believe FreeBSD does)
                      4. pretty much all Linux programs can be recompiled to run under other Unix systems.


                      That makes it highly unlikely that a userland program is a derivative work of the kernel.

                      Comment

                      Working...
                      X