1. 11
  1.  

  2. 22

    Sadly that’s a really difficult bit of software to use. The license states that you cannot use it in any capacity without emailing the author.

    I’d be very hesitant to engage with this at all, unfortunately.

    1. 5

      Yeah that licence is … interesting. I could understand emailing for permission to modify it, but just to use it seems a bit over the top.

      1. 18

        This is an effort to fight individual exploitation in the FOSS community.

        By writing proprietary software. ;)

        The fact that the source code is available doesn’t make it less proprietary.

      2. 1

        Not at all. Compiling and running the code privately or for educational purposes would fall under fair use.

        Exploitation is a huge problem in the community, and it starts with little acts like this to fight it, even if it isn’t what people are used to. And as time goes on I will refine what I do to help the problem. ☺

        1. 5

          Exploitation is a huge problem in the community, and it starts with little acts like this to fight it, even if it isn’t what people are used to.

          I’m not sure this achieves anything, honestly. Other than of course, being proprietary software in an effort to “fight exploitation in the FOSS community”.

          1. 2

            That’s nice for users of your software in countries where Fair Use exists as a concept in copyright law.

            In the UK for example, the concept of Fair Use is described as Fair Dealing, and a defence exists to copyright infringement if it is for the purpose of ‘academic study’, ‘criticism or review’, or ‘reporting of current events’.

            Running this bot, for example, for my own use in a channel unrelated to its development, I don’t believe would reasonably fall into any of those three buckets.

            Have you considered a strong licence like AGPL-3.0?

            1. 2

              what “exploitation” are you referring to?

              1. 1

                The most recent event, which really opened my eyes, was the the one where Amazon took over ElasticSearch.

                My code can still be used under fair use, and is available for reading.

                1. 16

                  Amazon didn’t take over ElaaticSearch…Elastic chose to relicense it under a proprietary license, and then Amazon forked the latest Apache 2.0 licensed version into a competing product.

                  1. 1

                    Any software licensed under terms that prevent Amazon (or any other party) from doing this is not free. Maintainers of software that claims to be free software should not be able to prevent users from modifying that software in ways they disapprove of.

            2. 1

              Where do you see the license?

              1. 3

                It’s at the bottom of README.md.

            3. 16

              In addition to the license not actually being open source, the bot itself has a number of technical issues.

              I’ve dealt with IRC quite a bit in the past - I maintain a Go IRC library at https://github.com/go-irc/irc, contributed to many others, written a rust IRC library, and one of my main personal projects has a large portion of code which was written to interact with IRC.

              1. The posted bot doesn’t handle trailing arguments properly (some messages will be reported as starting with : when that is incorrect).
              2. If a PING is sent during registration, it will not be able to connect. Many servers use this as a form of protection against some DoS attacks.
              3. It only responds to PRIVMSG, not NOTICE or CTCP ACTIONs.
              4. It only sends PRIVMSGs.
              5. It is possible for multiple messages to be returned in one read, but this code can only handle one at a time.
              6. Messages are not parsed properly. It is valid for lines to start with :. These are often “server messages”. Similarly, IRCv3 defines message tags, which are parsed when the line starts with @. It’s not technically correct, but I believe Twitch’s IRC implementation sends message tags even if the client doesn’t support receiving them. Because of this, some PING messages may be ignored because it’s valid for a server to send :some!user@server PING :SOMETHING.
              7. If I’m nitpicking, there are completely unnecessary allocations. write! should be used in place of format! because then you don’t need to allocate a string, convert it to bytes, then write it.

              It’s a good start to an interesting concept, but I would caution people against using this for both the license and the reasons outlined above.

              1. 2

                Yep, for sure some things to iron out, but the goal is simplicity. A quick look at go-irc and clearly it is much more complex and has dependencies. Which is understandable considering your projects and this project have different goals! ☺

                All of those points could be changed if needed. But if you don’t need to handle particular cases a server presents, there is no point. Otherwise you can create a patch or branch to handle it.

                1. 4

                  Yep, I understand that they have different goals. I really do like the idea of this project. Being able to write bots in a super low friction language while the core is in something like rust is an awesome goal. Also go-irc has no runtime dependencies - they’re only for testing. One of my explicit goals was to have no external deps.

                  Otherwise you can create a patch or branch to handle it.

                  Yes I have the knowledge to fix those things, but also under the current license, I can’t create a patch for it without first asking for permission. Additionally, this could be closed sourced tomorrow and I couldn’t do anything about it.

                  You are of course free to do what you want with your code, but many people (myself included) would be put off enough by the license to not bother.

                  1. 1

                    You are of course free to do what you want with your code, but many people (myself included) would be put off enough by the license to not bother.

                    Yep and I fully acknowledge this. My goal isn’t popularity, it’s building good software while not being taken for a ride.

                2. 1

                  I wouldn’t call 3+4 technical issues unless they were planned features.

                  No one forces you to implement every part of the spec, and I find ‘only handling PRIVMSG’ a 100% valid thing to do for an irc bot. Also not implementing IRCv3 is fine.

                  If writing an irc client or claiming full protocol compliance you’re right, of course.

                  1. 2

                    Good point. 3+4 are definitely more features than technical issues.

                    Yes, you don’t have to implement what you’re not going to use. The 3 examples I picked (PRIVMSG, CTCP ACTION, and NOTICE) are the 3 most commonly used. I would like to see the user sending the message be passed to the shell script - it seems like you could do quite a bit with that.

                    Not implementing IRCv3 features isn’t that big of a deal (unless as mentioned above, you’re working with some very specific servers), but not handling the message prefix properly will come back and bite you later. Lots of the code here is very special-cased per-message - I would argue it’s much better (cleaner, less error prone, more bulletproof and easier to maintain) to parse messages in a standard way and handle them fully-parsed.

                    Just as an example, here’s my old irc crate with 1 runtime dep on thiserror (which could be pretty easily removed). It’s not that much more complex (especially if you remove the IRCv3 tag handling) and parsing messages into a Message type makes them much easier to deal with. It’s also not optimal (it could be using &str rather than String) but I felt that making it easier to use would be better than blazing fast performance for my use case.

                3. 10

                  Awesome! What could possibly go wrong with passing user input to a shell script?


                  (Also, OP should add the show tag and set themselves as the author on this story – they’ve submitted links to other repos with the same GitHub username while claiming authorship.)

                  1. 1

                    What could possibly go wrong with passing user input to a shell script?

                    User input is passed to scripts and programs all the time?…

                    And yes, should probably have show, but I don’t want to claim authorship. There is no rule about having to flag as being the author.

                    1. 8

                      Maybe there’s no rule, but it feels dishonest to not participate in accurately representing when you’re submitting your own works vs. sharing others’.

                      1. 2

                        User input is passed to scripts and programs all the time?…

                        mhm, that’s ok because that’s your input! Do you really want someone deciding what get’s passed to a shell script on your machine? It only takes one improperly quoted variable or one eval call to give that user more access to your computer than you supposed they would have.