Announcement

Collapse
No announcement yet.

SteamOS Didn't Use Ubuntu Over Legal Issues

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

  • #76
    So the ..heise.de article refers to Gabes presentation at CES however doesn't mention the source of
    Originally Ubuntu was provided as a basis, but because of legal issues were unclear to some additional components to be switched just before just to Debian. There you have some need to program yourself what Ubuntu would have already had it.


    Did i miss something? Because i hear no mention of legal issues

    Comment


    • #77
      Originally posted by dee. View Post
      No, they can't. AGAIN, the GPL covers the binaries of the software as well as the source code. Building the binaries does not give Canonical a right to restrict how that software is used. Do I need to cite the relevant passages to you again, in case you've forgotten them since our last "discussion"?
      No, you don't, since they still don't apply. Again, I am not talking about restricting the use of the binaries, I am talking about restricting the service to build the binaries. The service to build those binaries has nothing at all to do with the license of the software that is built. Canonical can legally restrict their build service to be only available to projects that do not compete with Canonical in the OEM market. In other words, Canonical has totally the right to choose its customers and no part of the GPL prevents that. If Mint does not want to play that game the are of course entitled by the GPL to fork Ubuntu and do it themselves.
      I'm fairly certain that your view is not shared by the FSF, or any lawyer who is familiar with the GPL and works with GPL software. Building a binary from GPL source code does not give the builder a right to add restrictions on the usage of that binary. That is clearly and explicitly forbidden by the GPL, both versions of it.
      And again, that is irrelevant, since the restrictions don't apply to the software, but to the service of building binaries. They can't restrict the software, but they can dictate the conditions under which they provide the service.
      They can restrict the access to their server, if they want. That is within their rights. They can say to Mint, "people using your distro are not allowed to access Canonical's servers", and they'd be within their rights.
      Now you get it. And this includes "Remove any pointers to to our servers from your sources.list and do not by default allow usage of the PPAs that are hosted on our launchpad servers (which are all PPAs)", which would be more or less the end for Mint, regardless if they in the future load their packages from a different mirror. Canonical could even go so far and deny the installation of their own packages using an artificial dependency on a package that only is hosted on a specific Canonical server.
      They are, like I said, wanting Mint to sign a license to use their binaries, and this license is meant to restrict how Mint is allowed to use the binaries. Like I said, even Clem himself has stated that he doesn't consider Canonical's copyright claim valid.
      And this all do you get from a short article on Distrowatch with only a few sentences from Clem. That is why I stated already that your claims are baseless until we see what is actually going on between Canonical and Clem, in full detail. If Clem is accepting license terms from Canonical that are violating the GPL he is as intellectually dishonest as you claim me to be.
      I'm really getting tired of your intellectually dishonest debating style, Vim_user. You cherrypick parts of my posts to nitpick on and ignore other parts that prove your points wrong. I'm getting tired of telling the same things to you over and over again.
      That is your problem, not mine. If you don't want to discuss with me then don't do it, there is nothing forcing you to do so.

      Comment


      • #78
        Originally posted by Vim_User View Post
        That is your problem, not mine.
        Actually, it is exactly *your* problem. You again skipped a part that counters your argument. This part:
        They do NOT have the right to tell Mint "people using your distro are not allowed to access mirrors that provide packages compiled by us"

        You're constantly mentioning the service of building binaries. But what you're missing is the distribution of said binaries, which is a different service. And that one Canonical cannot restrict - as soon as someone gets the binaries, they are free to redistribute them. And then Mint can get them from that someone. Which is very easy, because there are a lot of such "someones" already, all the mirrors that are out there. There's nothing Canonical can do about it, all they can mandate is that Mint's sources.list does not point to Canonical. But it can point to any of the mirrors.

        Comment


        • #79
          Ubuntu would have trouble controlling mirrors

          Originally posted by dee. View Post
          They can restrict the access to their server, if they want. That is within their rights. They can say to Mint, "people using your distro are not allowed to access Canonical's servers", and they'd be within their rights. They do NOT have the right to tell Mint "people using your distro are not allowed to access mirrors that provide packages compiled by us", because that's against the GPL. And the problem, again, is NOT that they want to restrict access to servers. They are, like I said, wanting Mint to sign a license to use their binaries, and this license is meant to restrict how Mint is allowed to use the binaries. Like I said, even Clem himself has stated that he doesn't consider Canonical's copyright claim valid.
          Mint could respond by using only mirrors of Ubuntu's servers and blacklisting the only servers Canonical actually owns by default. Any attempt by Ubuntu to control PPA access will cause PPA owners to move off of Canonical's machines due to the popularity of Mint. In addition, as I said before, Mint already has a Debian-only based version as insurance-Ubuntu cannot kill Mint.

          I am recommending Mint or UbuntuStudio, never default Ubuntu these days due to Unity's failure to separate online and offline by default. The day Uubntu attempt to prevent Mint users from updating from their repos OR using Ubuntu PPA's, I will switch my /etc/sources.list to use Debian unstable, purge lightdm, install mdm, and switch to whatever startup system Debian uses. From then on, I will pull binary updates from Debian unstable and compile my own kdenlive and Mesa debs from git. My video editing boxes can do that with ease. Over time, my OS install that dates back to Ubuntu Jaunty will then become a Debian based setup with Cinnamon and old UbuntuStudio themes. Ubuntu needs Mint, Mint does not need Ubuntu, as anything I can do Mint can surely do.

          Comment


          • #80
            Originally posted by Vim_User View Post
            That is your problem, not mine. If you don't want to discuss with me then don't do it, there is nothing forcing you to do so.
            If you're behaving like an intellectually dishonest troll, that most definitely is not my problem. If you don't understand the GPL, that's not my problem either. If you insist on ignoring parts of my posts that already show you are wrong just so you can continue arguing and maintaining the delusion that you're right, because it's so horrible to admit being wrong on the internet - Guess whose problem that is not?

            Comment


            • #81
              Originally posted by Luke View Post
              Mint could respond by using only mirrors of Ubuntu's servers and blacklisting the only servers Canonical actually owns by default. Any attempt by Ubuntu to control PPA access will cause PPA owners to move off of Canonical's machines due to the popularity of Mint. In addition, as I said before, Mint already has a Debian-only based version as insurance-Ubuntu cannot kill Mint.
              Right, but instead, Clem is wiling to play along with it in order to maintain good relations with Canonical - they're trying to be the bigger distro there. I don't necessarily agree that this is the best course of action, but I can understand why Clem would want to do it this way. There's no risk for Mint in this - even if Canonical is violating the GPL by placing restrictions on binaries they distribute to Mint, that violation does not transfer on Mint - Mint would not be accomplice to the violation, this is also stated explicitly in the GPL: only the distributing party can be guilty of GPL violation.

              I think Canonical is just creating unnecessary problems for themselves with no gain whatsoever. And tactics like this could very well be the reason why Valve is now distancing itself from Ubuntu...

              Comment


              • #82
                Originally posted by dee. View Post
                I don't necessarily agree that this is the best course of action, but I can understand why Clem would want to do it this way. There's no risk for Mint in this
                ...except the damage caused by losing OEMs that would otherwise want to use Mint.

                Comment


                • #83
                  Originally posted by dyfet View Post
                  No they are not simply locking them up behind a paywell, which indeed would have been valid and much like what RedHat does. They are instead telling Mint where they can and cannot re-distribute the files that they do receive, which is NOT legally permitted by the GNU GPL.
                  Which bit of the GPL says they can't? Remember, the GPL is a *source code* license - it places no restrictions on binaries, other than that you can't distribute them without providing access to the source they were built from. There's nothing that says they can't deny others access to the binaries.

                  Comment


                  • #84
                    Originally posted by Delgarde View Post
                    Which bit of the GPL says they can't? Remember, the GPL is a *source code* license - it places no restrictions on binaries, other than that you can't distribute them without providing access to the source they were built from. There's nothing that says they can't deny others access to the binaries.
                    Have you actually read the GPL?


                    From the GPLv2

                    Section 0

                    "... 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..."

                    Translating into binary form via a comipler, is quite clearly a derivative work, still refered to therin as the program.

                    Section 6

                    "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein ..."

                    So while you aren't required to distribute the binary, niether can you place restriction on people who you distribute it too beyond those of the GPL.

                    Comment


                    • #85
                      Originally posted by ninez View Post
                      I'm not sure that i would consider the NSA/US Govt dumping $80 million USD for R&D of a Quantum computer tailored for cracking most (if not all) current available encryption, would fall into the category of them all being "script kiddies";

                      http://www.pcworld.com/article/20837...-computer.html
                      http://rt.com/usa/quantum-computer-nsa-encryption-100/
                      http://www.washingtonpost.com/world/...y.html?hpid=z1

                      if (more likely when) they have developed such a computer, by the sound of it, cracking even the most (historically) difficult encryption should be a breeze, due to 'quantum superposition';



                      ..and being as quantum computers aren't limited to 0/1 (on/off) states, but instead has 'all possible states' - exposing semiprime numbers and the like (used in RSA for example) will likely take no time at all to crack at all. (ie: while current super-computers may take years, in theory, a Quantum computer should be able to crack encryption very fast / very little time, in comparison).

                      anyway, OT but i thought is was worth mentioning, as while it may be true there are a lot of script kiddies (in XYZ govt/institution), there also is a lot of serious work going on that maybe you weren't aware of. (well beyond the realm of what script kids can do, and frankly a bit scary).
                      A quantum computer large enough may not even be possible. To insure sucess with shor's algorithm you need to entangle as many qubits as bits the number you want to factor.

                      Comment


                      • #86
                        When canonical talks binaries, one assumes they mean DPKGs. I cannot say if it is legal to restrict their use or not. That they are containers for GPL software may or may not be relevant.

                        Furthermore Vim is 100% right with regards to restricting repositories. Those are THEIR servers. They can restrict them all they want. An analogy: if you kept a stock of CDs with GPL software on them in a shed and let people come and go as they please to take a CD, but only if they agreed to stay for a cup of tea too, would that be GPL violation? No. To suggest so is patently absurd.

                        Comment


                        • #87
                          Originally posted by JX8p View Post
                          When canonical talks binaries, one assumes they mean DPKGs. I cannot say if it is legal to restrict their use or not. That they are containers for GPL software may or may not be relevant.
                          Why would it matter? GPL license terms do not change based on what form the GPL-licensed software is distributed in: you have to provide source (or access to), you can't place additional restrictions, you can't prevent redistribution - these apply, no matter if the software is distributed in source, binary or DEB form.

                          Furthermore Vim is 100% right with regards to restricting repositories. Those are THEIR servers. They can restrict them all they want. An analogy: if you kept a stock of CDs with GPL software on them in a shed and let people come and go as they please to take a CD, but only if they agreed to stay for a cup of tea too, would that be GPL violation? No. To suggest so is patently absurd.
                          Sigh... I'll say this one more time. Placing restrictions on the use of repositories would be within Canonical's rights. If Canonical wanted to say "Mint, you guys may not use our repositories", that would be legal. What they cannot do is tell Mint "you have to sign this license in order to be allowed to use binaries compiled by us even if you get them elsewhere". That is very clearly against the GPL.

                          They can place restrictions or conditions on the usage of their repositories. HOWEVER, those conditions cannot contradict the GPL license, because Canonical has themselves a prior agreement they have to abide by - the GPL license. When Canonical uses GPL software themselves, they have agreed to abide by the GPL license, therefore, placing restrictions on the usage of their repositories which effectively causes restrictions on how the recipients of those binaries are allowed to use them - is against the GPL.

                          I think there was even a section about this in GPL, I'll look into it later.

                          Comment


                          • #88
                            Originally posted by JX8p View Post
                            Furthermore Vim is 100% right with regards to restricting repositories. Those are THEIR servers. They can restrict them all they want. An analogy: if you kept a stock of CDs with GPL software on them in a shed and let people come and go as they please to take a CD, but only if they agreed to stay for a cup of tea too, would that be GPL violation? No. To suggest so is patently absurd.
                            No, many of them are NOT their servers, they are third-party mirrors that provide hosting to Canonical for free. Canonical has no right to restrict who they can distribute their software to. This has been explained at least a dozen times in this thread alone.

                            Comment


                            • #89
                              Originally posted by JX8p View Post
                              When canonical talks binaries, one assumes they mean DPKGs. I cannot say if it is legal to restrict their use or not. That they are containers for GPL software may or may not be relevant.

                              Furthermore Vim is 100% right with regards to restricting repositories. Those are THEIR servers. They can restrict them all they want. An analogy: if you kept a stock of CDs with GPL software on them in a shed and let people come and go as they please to take a CD, but only if they agreed to stay for a cup of tea too, would that be GPL violation? No. To suggest so is patently absurd.
                              Yes, and the fact those are their servers is already accepted by everyone. The fact is, there are LOTS of mirrors which Canonical DOES NOT OWN, and Canonical CAN NOT restrict access to those, all of those being used by the official distributions. For example, I chose, for a matter of speed, to use a mirror located in my college. Those servers belong to the University of Buenos Aires, not to Canonical. If Canonical were to just forbid access to Canonical servers, Mint would be free to use those, and countless others. If Canonical were to, somehow, forbid access to all mirrors, then they would have serious legal problems for abusing someone else's private property (or in the case of my college, public property), and at least a bunch of debian and Arch users very angry in my city, as the same servers mirror their repositories.
                              Being DPKS doesn't change the least. In fact, DPKGs are a derivative work, as their value is only on their contents, which are in several (but not all) cases, GPL. It's just the distribution media: the very same way you can not restrict redistribution of a CD containing only free software, you can not restrict redistribution of a DPKG containing only free software.

                              Comment


                              • #90
                                Originally posted by JX8p View Post
                                When canonical talks binaries, one assumes they mean DPKGs. I cannot say if it is legal to restrict their use or not. That they are containers for GPL software may or may not be relevant.

                                Furthermore Vim is 100% right with regards to restricting repositories. Those are THEIR servers. They can restrict them all they want. An analogy: if you kept a stock of CDs with GPL software on them in a shed and let people come and go as they please to take a CD, but only if they agreed to stay for a cup of tea too, would that be GPL violation? No. To suggest so is patently absurd.
                                I've torn apart binary .deb files and they are really quite simple.

                                They contain three parts wrapped in a single ar file.

                                --version info (of the .deb format, not for the package)
                                --a psuedoroot directory containing all the files to be copied into the filesystem. (clearly a derived work in itself, except perhaps added disto-specific init or .conf files)
                                --a control directory containing Scripts to run pre, post install, checksums for all of the files in the above data directory, and a controll file listing dependencies and containing package information.

                                http://tldp.org/HOWTO/html_single/De...g-HOWTO/#AEN66
                                Don't believe me, go and pull one apart.

                                Those scripts could come under separate copyright if they were distributed repeatedly, but going back to section 2 of the GPLv2 " If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."

                                Leading me to conclude that because the wrapped it up together in a single file the licence on those files must be compatible with the GPL. Besides being in a single file, it's also designed to all be pulled with a single command.

                                To actually control the copyright-able parts they add in they might be able to do something like gentoo's portage system does. All of the install information, checksums, pre and post install processes, distro-specific init and .conf files are kept in their own sub directory, and are mixed together only when the user initiates the install procedure. However this still wouldn't give canonical much leverage as they are distributing both together as a distribution. They would have to go a few steps further and make the download of the sub-directory a user-initiated process during installation. Of course this would backfire on canonical practically, because many third parties would be willing to step in to provide third-party directories.

                                Comment

                                Working...
                                X