Forum Moderators: phranque
Or, (2) if that's not your thing, find someone who does read source, and verify the cryptographic signature of the software package with them before installing it.
Or, (3) find a user or developer community you trust, one that is inspecting, developing and/or deploying the source code, and verify the crypto signature of the software package with them.
(3) is what nearly everyone does. The community might be something as large as a Linux distribution like Fedora, or more often the authors of the software itself. For people who aren't able to vet the software by hand, it is a matter of locating people who do, evaluating their reputation and trusting their conclusions. The very nature of open source leads to many eyeballs viewing the source, and cheating is difficult.
But even if you build it yourself, how can you be sure that your development tools don't contain spyware, even if they come from the operating system vendor? Check out the classic story of the self replicating compiler back door [jargon.net]...
It depends on what you consider to be spyware, too. I've said in the past that I consider the open source WordPress [wordpress.org] blog package to contain spyware because it has a web bug in the admin section: the Get Firefox icon is called from a remote server, allowing the owner of that server (static.wordpress.org) to compile statistics on where WordPress is installed and how often it is used. I was not the first person to discover this "spyware": it was picked up immediately by beta testers - which goes to show the advantages that the open development model offers.
You get another vital layer of protection with open source too: the ability to fork the project if the development model doesn't go the way you would like, as well as the associated advantage of the license allowing you to make any modification you want, use the program in any way you want, and even redistribute the end result if you desire. (the redistribution must be with an open source license in some cases).
You don't get a guarantee, but open source software is very well protected against spyware, and certainly a lot more than most closed source products.
The vast majority of software is clean.
Incidentally, I think you are confusing open source with shareware/freeware. If anything, the chances of open source software being dirty are less than other software for the reasons given above.
Kaled.
You can run a spy software program on your pc. It should tell you all the spyware running on your pc.
There is a website that offers a free scan of your system for spyware. Last time i checked, it was free. Although if there is spyware on your pc, i don't think they will remove it for you. You'll most likely have to purchase their software to get the spyware off your pc. **It removes most or all spyware on your system. So if it's in the software, it should remove it. You'll need the software though. It runs around $30 bucks. I personally use it. It works well.
frenzy77
For compiled stuff, if you download it from an authorized mirror, not some other site with no direct affiliation, often they have md5 checksums you can run against the package. Most Linux distros have this. As far as I know it's not possible to add something to a compiled package and have the md5 checksum match, or at least it's not very easy.
For freeware/shareware, you have no way to know, and as stuffit users on mac recently found out, even previously honest products can change for the worse with a change of ownership/policy, I think it was stuffit anyway.
HAH! Not so. It took three days to figure out how to root out locations and settings that had been changed to set the defaults to the author's web site, search panels, etc.
Believe me, I was not a very happy camper. Not because of the changes themselves, but by the fact that the changes were not disclosed, and thus making appear to be very risky to trust the install package in total.
That is the real problem with open source where there are multiple distribution points. This does not include projects such as FreeBSD where there is one and only one packager.
Unless you have nothing else to do, reading the source code of a complex package is not really an option.
In the situation that I described above, there were a limited number of places to look, but it involved digging around in a mess of jar files to find the changes. And then more forensics to come to some conclusions as to what other files had been changed.