Announcement

Collapse
No announcement yet.

Fedora Decides To Not Allow SSPLv1 Licensed Software Into Its Repositories

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

  • #41
    Originally posted by tuxd3v View Post
    AGPL, at least for me, is more complicated, seems not clear, because if you have a Library, released under AGPL, even having a client that is dynamic linked with that Library, turns your code in AGPL, I think..
    Correct. In that respect, the AGPL is essentially identical to the GPL - it doesn't include an LGPL-style exemption for linking. It's basically an adaptation of the GPL for server applications, clarifying that someone using that server over a network counts as a user for the purposes of being entitled to the code, even though they've not technically received a copy of the software binaries.

    Originally posted by tuxd3v View Post
    The only way this could eventually work out, seems to be,
    If I have a AGPL server + LGPL client library( dynamic linked with my proprietary software..), and I deploy it in a server, so that a user can access it..
    The server license doesn't matter... even though you require it, a server is considered separate from the clients which use it.

    But if you use a client library in your application (a database driver, for example), you need to comply with the license of that library, just as you would any other library you use. LGPL, Apache, MIT, BSD – they're all more or less compatible with any proprietary code you might write (GPL and AGPL are not). Alternatively, if the protocol is simply enough, such as a nicely-documented REST service, you can write your own client.

    Originally posted by tuxd3v View Post
    But I am now sure if I have to provide my source code, since users will retrieve information trough it from AGPL server.. , and without the AGPL server my code doesn't work..
    No, because client and server are separate things – even though they talk to each other, and even though the client cannot function without the server, they're separate applications. The license of the server code is unrelated to the license of the client code... but note that I say "code license". It doesn't mean that the server doesn't have conditions on using the server itself, but your code doesn't care about the server code... a GPL client can talk to a 100% closed proprietary server, and there's no conflict over the *code* licensing.

    That's where the SSPL is a concern – because it's written by people who don't agree that client and server are separate things, and believe that calling a remote API is equivalent to linking code into a combined executable... you're not just using their IP, you're creating a derivative work. And there's some truth to that claim, because in the Mongo world, cloud services and microservice architectures have lately been displacing the traditional monolithic services, and open-source licensing is slow to respond to new trends.

    But as-is, the SSPL is far too reaching... it leaves that distinction between linking and usage ill-defined, and as such, it's almost certainly going to result in court cases trying to establish what the boundaries actually are. And until that happens, this is a license that nobody in their right mind should be going near...

    Comment


    • #42
      Originally posted by hreindl View Post
      jesus christ MongoDB is just another network service and the GPL is about source code itself and not about "hey i talk over a socket to a server"
      You do understand that the issue here is the license MongoDB has switched to and not the software itself? Right?

      do you really not understand the differences?
      Well look who's talking...

      Comment


      • #43
        Originally posted by hreindl View Post
        which is exactly the point because GPL don't apply in such cases other than the new license
        Oh for crying out loud... The fundamental issue here is that the new license is is incompatible with other licenses and what people want to do with their code. Not only that, the exact same sorts of issues apply to the GPL and derivatives of it as well. After all, the license in question is a GPL derivative, more specifically a derivative of GPLv3.

        As a practical example of GPL incompatibility there's the licenses for the proprietary graphics libraries used by the last couple of generations of consoles. These proprietary licenses are so strict that you can't even document them, let alone open source API bindings for them. Epic, makers of the Unreal engine, for example can't open source the console-specific portions of their engine and instead require developers to prove to them that they have the necessary license agreements with the platform owners before they'll release the relevant sections of the engine source code to them.

        Comment


        • #44
          Maybe it'll help to look at is this way.

          If an entire license ecosystem is saying MongoDB is wrong, and MongoDB is saying the entire rest of the license ecosystem is wrong, who is more likely to be wrong?

          Comment


          • #45
            Originally posted by ssokolow View Post
            If an entire license ecosystem is saying MongoDB is wrong, and MongoDB is saying the entire rest of the license ecosystem is wrong, who is more likely to be wrong?
            That ultimately depends on their reasoning... Argumentum ad populum is a known logical fallacy and history is full of examples where the common consensus was just plain wrong (earth being the center of the universe, lobotomy being a sensible way to treat mental illness, slavery being a-ok, there being no valid reason for the U.S to join WW2, rats and other vermin being born from dirt, etc.).

            Comment


            • #46
              Originally posted by L_A_G View Post
              That ultimately depends on their reasoning... Argumentum ad populum is a known logical fallacy and history is full of examples where the common consensus was just plain wrong (earth being the center of the universe, lobotomy being a sensible way to treat mental illness, slavery being a-ok, there being no valid reason for the U.S to join WW2, rats and other vermin being born from dirt, etc.).
              Obviously. That's why I asked who is more likely to be wrong.

              Claiming to be more correct than the status quo is such a commonly abused tactic that it carries no merits on its own and, statistically, it's rare for it to play out. (Heck, it's a favourite tactic of pseudoscientific claims.)

              Beyond that, don't forget to take survivorship bias into account. Our perception of the past is skewed heavily in favour of the cases where they bucked the trend because, when the status quo is right, it's not really that noteworthy.

              One great demonstration of this is a site named A Brief History of the Apocalypse, last updated in 2011, which tallies up all the 2012-esque doomsday claims the site's maintainer could find from 2800 B.C.E. through 2040. (Plus an entry for the sun swelling up into a red giant in 4.5 billion years.)

              TL;DR: These sorts of "everyone else is wrong" claims are so commonly made (and so often made in ignorance or bad faith) that the onus is on the claimant to prove that it's worth our time to even address them in detail. (Religious crazies love to use this to claim that scientists are afraid to challenge them when, in truth, the scientists just have much better things to do with their time.)

              Heck, the only reason this is getting any attention is that they relicensed a project with a large existing user base.
              Last edited by ssokolow; 17 January 2019, 12:12 PM.

              Comment


              • #47
                Paging Michael for another spuriously spam'd reply.

                Comment


                • #48
                  Originally posted by ssokolow View Post
                  Maybe it'll help to look at is this way.

                  If an entire license ecosystem is saying MongoDB is wrong, and MongoDB is saying the entire rest of the license ecosystem is wrong, who is more likely to be wrong?
                  How is MongoDB "wrong"?! Wrong in what? If you don't like it, don't use it. Nobody forces you to use it. As if wronging Fedora has any relevance.

                  Comment


                  • #49
                    Originally posted by Weasel View Post
                    How is MongoDB "wrong"?! Wrong in what? If you don't like it, don't use it. Nobody forces you to use it. As if wronging Fedora has any relevance.
                    If we assume this is a good-faith effort to encourage the opening up of more code (as opposed to a deceptive attempt to use terms which are unsatisfiable in practice to force people to pay for the proprietary license option) then the question is whether MongoDB is right or wrong in thinking that this is the proper way to accomplish this goal. They claim they're right. The rest of the ecosystem thinks they're wrong.

                    Comment


                    • #50
                      I'd like to point out that there isn't a single comment in this thread crying about fedora censoring people for removing this package. It's a shame all those people attacking Debian on the Weboob stuff only care about censorship when it's convenient

                      Comment

                      Working...
                      X