Mar 06, 2019 - 02:58 AM
The most important thing to consider before deploying a freeware in the enterprise is to go through the T&Cs and the EULA of the software. Many a times there are additional restrictions put in place, the definition of "commercial use / production use" may be different or the size of the organisation allowed to use the software is fixed, type of allowed work is clearly defined, hidden chargeable features (that may be enabled by the users accidentally), audit clauses etc.
The second important factor is security. You cannot just take any software available online and get it installed on the system. The security team needs to check it in a test machine / sandbox environment, give you a confirmation, before rolling out the software.
The third point to focus is the importance of the project where the software is being installed. Is it in a production system? How critical is the system? What is the impact if something goes wrong? In process critical system, it is always advisable to go for paid software with a support contract.
Hope this answers your query.
Mar 07, 2019 - 11:42 AM
With my exposure to IT Security most of my concerns come from that domain - who developed it, is the code of good quality, if there's no commercial agreement what happens in the event of negligence. You also need to consider longevity - if you're basing a critical business process on a piece of freeware, what happens if the developer stops developing it and you need an upgrade or to patch a security hole? I'm thinking here particularly of closed-source freeware where you couldn't take on development yourself.
Many of these concerns apply to commercial software too but they're some things to think about. At my former employer we had some pretty niche software (the maritime industry is like that) and we were literally running multi-million pound processes on software developed by a bloke in his bedroom. No-one had really considered what would happen if he stopped developing the product or his company failed (this was a closed-source commercial app). When I pointed out that it was being used to control the supply chain for ship refits there were a few serious questions asked. It's perhaps an extreme example but you could end up in that situation trying to buy the source code from a failed supplier to continue running your critical business process. A further example was the terminal emulation software used in our call centres. Proprietary, closed-source software that all our revenue ran through, with a hard date expiry on the license key. I spent 6 weeks trying to contact them to process the renewal so we could continue service - it went right down to the final week and we didn't really have a practical alternative.