Announcement

Collapse
No announcement yet.

How many actually agree on the GNU project?

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

  • How many actually agree on the GNU project?

    While for me, I do agree that one size doesn't fits all, able to amend code is sure a plus for everyone. But if I were to create something like vbulletin, I would encrypt just a little portion of code to only allow the application to run on a specific domain while exposing all other programming code. Why vBulletin doesn't do that since so many user have pirate the software? I'm not a guru here, just trying to discuss this with other experience coders here around.

  • #2
    Really no matter what you do if someone wants the software bad enough they will crack it or find someone to do it.

    Dark Shogun

    Comment


    • #3
      while they may by all means find someone to do it, by cracking my software is doing something illegal. From my first post, I stated I will eventually encrypt a little portion of my code to only allow my software to run on one domain (wihch is the license domain). Other than that, they can amend, study or do whatever they can to the code. I don't see anything bad here unless "evil one" really wants to duplicate the software elsewhere. License users shouldn't be upset with this little encrypted code right?

      Comment


      • #4
        People who pirate your software aren't going to stop because you've encrypted one little bit of it...as DS said they will find a way around it.

        Comment


        • #5
          Originally posted by stevecop
          while they may by all means find someone to do it, by cracking my software is doing something illegal. From my first post, I stated I will eventually encrypt a little portion of my code to only allow my software to run on one domain (wihch is the license domain). Other than that, they can amend, study or do whatever they can to the code. I don't see anything bad here unless "evil one" really wants to duplicate the software elsewhere. License users shouldn't be upset with this little encrypted code right?
          I would be mad. It limits what you can customize. Even db_mysql.php has been in a few hacks, my favorite being the "Self-Repairing Database" hack. What else can be encrypted? And how would it really help?

          Not only that, but it'll probably make it a hell of a lot harder to put it on localhost and run it from there, as wouldn't additional software be required? And branching off of that, it'd be harder to find a host that supports it.

          Comment


          • #6
            Originally posted by squall14716
            Not only that, but it'll probably make it a hell of a lot harder to put it on localhost and run it from there, as wouldn't additional software be required? And branching off of that, it'd be harder to find a host that supports it.
            Actually, the software to use encoded PHP files (they aren't really encrypted) on a webserver is free. It is the software that encodes them that requires a payment. Though you are right in that many hosts do not support encoded files at this time.

            AS for the GNU project, I think the project itself has merit. However the GPL has serious fundamental flaws that effect the world economy.
            Translations provided by Google.

            Wayne Luke
            The Rabid Badger - a vBulletin Cloud demonstration site.
            vBulletin 5 API

            Comment


            • #7
              Originally posted by squall14716
              I would be mad. It limits what you can customize. Even db_mysql.php has been in a few hacks, my favorite being the "Self-Repairing Database" hack. What else can be encrypted? And how would it really help?

              Not only that, but it'll probably make it a hell of a lot harder to put it on localhost and run it from there, as wouldn't additional software be required? And branching off of that, it'd be harder to find a host that supports it.
              No, not encrypting any of the db code but encrypting the part where output of the html template. This function simply disperse all variables to a template. Don't tell me there's a hack for this? Everytime an output is called, it shall go through the checking of the domain. It doesn't requires an overhead. Just a simple == || != snippet. And for localhost, it can easily be solve by adding == 'localhost' || == '127.0.0.1' whatever.

              As far as additional software, no, its not really a pain in the neck. If you know how to install PHP, of course you know how to edit just a line in your php.ini file if the software is using Zend encoded. If it is using IOCube, you don't even need to install anything or edit anything.

              Although for the encrypting part, I can presume some experience programmers can just delete it and code himself a new snippet. But least, isn't it better than none?
              Last edited by stevecop; Mon 1 Dec '03, 5:19pm.

              Comment


              • #8
                If you know how to install PHP, of course you know how to edit just a line in your php.ini file if the software is using Zend encoded.
                That wouldn't work for shared users who aren't allowed root access.

                Although for the encrypting part, I can presume some experience programmers can just delete it and code himself a new snippet. But least, isn't it better than none?
                Not if your competitors don't require the same hassel, not if you're on a shared host, and not if you want to set up a separate test forum.
                TheologyWeb. We debate theology. srsly.

                Comment

                Loading...
                Working...
                X