> P.S. Good time to re-read Ken's paper Reflections on Trusting > Trust (online at http://www.acm.org/classics/sep95/), before you decide > where to put your foot down.
Wow, that is totally off-topic. The discussion is about how we can use some of our clout to encourage source availability in the long term (versus giving no pressure at all) while not hurting our users by not giving them what they need. Right from the start, the discussion is about where to draw the line, in a field of grey, instead of choosing black versus white position. THAT is the problem we always face. A way to balance them. When I run software that is in ports, I have absolutely no doubt that there are security risks, and quite frankly, I don't care. If you care, you must work to fix it, and in reverse too -- if you don't work to fix it, then you must not care enough to fix it. And that is NOT what this is about. When binaries have holes, or risk factors due to distribution problems, well DUH, so does source code. ANY SOURCE CODE has just as much risk. Which of you even bloody read what you download. It is the standard balony of "If it is signed it must be risk-free" or "If it is signed at least it has fewer risks". It is still balony. This discussion is not about security. It is about trying to encourage suppliers of code to stick to the open source way of doing things. If we accept binary files all the time, how are we sending the right message? But if we only accept source, we are hurting our users. THERE ARE MANY MIDDLE GROUNDS where we don't hurt our users too much, yet we send a message to people who don't supply source. Even with "blobs", we have middle grounds, because while some of them are huge traps, some of them (like firmwares) just require redistribution rights, but too few people actually study the situation well enough and then (stupidly) they choose either black or white positions. Again, this discussion has ZERO TO DO WITH SECURITY.
