Announcement

Collapse
No announcement yet.

NihAV Is An Experimental Multimedia Framework Written In Rust

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

  • #21
    I don't think AGPL works the way it's described here. I have personally worked on an AGPL product that also had commercial, closed source modules.
    The open part you can still see here: https://github.com/sipXcom/sipxecs/c...66b8e2b9ba50bd

    Comment


    • #22
      Originally posted by ssokolow View Post

      Except that if you don't want to do so in a meaningful sense, there are ways to lawyer around it, like compiling a binary containing nothing but NihAV which communicates with the rest of your program through pipes or loopback sockets.

      People have tried to close that "hole" before, but you run up against the problem that you also make the license unsatisfiable because the resulting license either fails the FSF/OSI/Debian definitions of open-source licensing or is incompatible with the licenses of other processes running on the same host or both.
      You know, MPL-2.0 isn't the most restrictive copyleft license by any means, but it is the most clear-cut and enforceable.

      Comment


      • #23
        Originally posted by tildearrow View Post
        Why are Rust project names so negative? Like:

        - Rust (a bad thing for metals)
        - Corrode (same thing)
        - ripgrep (sounds scary, like Rest in Peace, grep)
        - NihAV (not implemented here AV)
        nih -> not invented here.

        Comment


        • #24
          Originally posted by wswartzendruber View Post
          Why license this as AGPLv3?

          EDIT: The answer seems to be so that anyone using this to provide services has to disclose the source.
          This is the reason given by the author:
          NihAV is licensed under GNU AGPL in order to be not so popular and provided as is without any warranty or promise of user support. Nevertheless, if you find some part of it useful I'll be happy to re-license it for you under any other free license (LGPLv2+, MIT, WTFPL, whatever—as long as it does not make new obligations for me) and other people can use it afterwards from your repository while NihAV still remains under AGPL.
          I do not believe he is right though. AGPL did not prevent Own/Nextcloud to become popular. (but it is still strange to use it for something else than SaaS)

          Comment


          • #25
            Originally posted by tildearrow View Post
            Why are Rust project names so negative? Like:

            - Rust (a bad thing for metals)
            - Corrode (same thing)
            - ripgrep (sounds scary, like Rest in Peace, grep)
            - NihAV (not implemented here AV)
            Rust was intended to be named after the impressively overengineered family of fungi.

            <graydon> I think I named it after fungi. rusts are amazing creatures.
            <graydon> Five-lifecycle-phase heteroecious parasites. I mean, that's just _crazy_.
            <graydon> talk about over-engineered for survival
            -- https://www.reddit.com/r/rust/commen...endall_source/
            As for "Corrode", it's a play on the project "turning something into rust", which is what the process of corrosion does to iron.

            Rest In Peace (or "Requiescat In Pace" as it was originally) apparently never occurred to the author of ripgrep, who intended it to mean "fast" as in "to rip through your text."

            As for NihAV, it's tongue-in-cheek honest that it's reinventing somebody else's wheel rather than contributing to the existing project.

            Comment


            • #26
              Originally posted by birdie View Post
              NiH is strong with this one.

              Expect this project to die in a few months/years after the developer gets tired of maintaining it.

              And it's unlikely ffmpeg developers will ever migrate to Rust given a ton of effort required and less than obvious benefits, besides, ffmpeg cannot exist without low level assembler code in order to speed up certain functions and this doesn't mesh well with Rust.
              C has the same problem which is why any top tier encoder/decoder has assembly (whether its C or Rust)

              Comment


              • #27
                Originally posted by bug77 View Post
                I don't think AGPL works the way it's described here. I have personally worked on an AGPL product that also had commercial, closed source modules.
                The open part you can still see here: https://github.com/sipXcom/sipxecs/c...66b8e2b9ba50bd
                One of the licenses posted is an AGPL loophole:

                All user facing (Web) interfaces that provide access to functionality or services provided in full or in part by this software must display the license and SIPfoundry copyright in a clearly visible way. By using this software you grant the right to SIPfoundry to use your name and logo to make such representation
                Separate the machines and you separate the modules -- Is that the case with what you were working on?

                Comment


                • #28
                  Originally posted by skeevy420 View Post

                  One of the licenses posted is an AGPL loophole:



                  Separate the machines and you separate the modules -- Is that the case with what you were working on?
                  I don't understand. All that says is you must acknowledge you are using software from sipfoundry and allow sipfoundry to use your name and logo (that was done on public presentations, to show who's using sipXecs/sipXcom - no other form of monetization involved).

                  Comment


                  • #29
                    Originally posted by bug77 View Post

                    I don't understand. All that says is you must acknowledge you are using software from sipfoundry and allow sipfoundry to use your name and logo (that was done on public presentations, to show who's using sipXecs/sipXcom - no other form of monetization involved).
                    Because with AGPL web facing clients don't have to show logos or anything like that because web facing clients is the loophole. Run all the closed source stuff on another machine and then you don't have to share your code that is meant to work with AGPL FOSS. Use that loophole with their software and that license acts as a digital watermark for them. It's actually both funny and shitty how they're abusing the AGPL with their own Corporate Logo License that literally covers the AGPL web client loophole.

                    So was their closed code ran on one machine and the FOSS code on another?

                    Comment


                    • #30
                      Originally posted by skeevy420 View Post

                      Because with AGPL web facing clients don't have to show logos or anything like that because web facing clients is the loophole. Run all the closed source stuff on another machine and then you don't have to share your code that is meant to work with AGPL FOSS. Use that loophole with their software and that license acts as a digital watermark for them. It's actually both funny and shitty how they're abusing the AGPL with their own Corporate Logo License that literally covers the AGPL web client loophole.

                      So was their closed code ran on one machine and the FOSS code on another?
                      I couldn't say. It was a cluster setup and you could toggle services on each node... It's possible some services were mutually exclusive, I don't remember that part too well.

                      I'm also not sure that is a loophole. If AGPL allows you to use AGPL code over some interfaces, why not assume that was intended?

                      Comment

                      Working...
                      X