> > An open-source project is not supposed to change rules at will. The > > license > > itself of open source software is often oriented toward this view, > > such that > > it guarantees people to keep using software they already got, even > > when the > > project becomes a completely commercial one. > > Exactly but the ONLY thing open-source guarantees is that you will not > be charged for the source code. The fact that the community provides > binaries is a convenience for you (and the rest of us). If you chose > to build your own, you could have prevented this by modifying the > source code.
Right, but it isn't that simple to me. The OS stems from the idea of wide usability and free exchange which is (was?) common in research. The basic idea was to prevent anybody to limit your option in using an OS product. The various OS licenses available nowadays are effectively only based on a matter of free access to the software, but this is because it was basically the only reasonable thing needed in a unconnected world, when you had to physically "put in the disk" to install or update something. To me, today the freedom of use of an OS package also means that any risk of impairing the usefulness of an existing installation should be reduced to a minimum. Please note this isn't stated in licenses, of course. Probably because it is unfeasible to be stated there, or because in a connected world there are many things which may go the wrong way and impair existing software. But nevertheless one of the target to which a team developing a (successful) OS product should attain, should be to keep old installations working the way they already do. It doesn't mean backward compatibility, of course. It simply means "live and let live". > > A remote kill is very dangerous to a commercially-oriented product, > > but may > > be a real disaster to an open-source one. Because the open-source > > idea is > > all based on freedom. > > They did not do a "Remote kill" They sent out one of the new style > signatures which your installed version could not handle. It is still > your responsibility as it is the responsibility of everyone who sets > up a server to ensure it DOES what they want in case of a failure. You > chose to keep the default behavior which is to block mail when it > can't be scanned and want to blame ClamAV for that. All they are > responsible for is sending out the new signatures as they had promised. But they were aware of the consequences. And they were probably aware of the fact that there were workaround which could let the new functionalities live, while letting the old installations live too. > > The ClamAV team can't act the way it did and not risk to be censured > > by the > > open-source community. > > > > If people blames you and feels betrayed by you, it is not a "sysadm > > matter"... > > > > Giampaolo > > > Yes it is, as my systems did not fail nor did anyone who bothered to > heed the warnings that clamd would STOP working and took steps to > mitigate the situation. That could be by upgrading or not accepting > new signatures or ANY other method including modifying the source code. The people who preferred clamav because it was a solution much less prone to stop due to licensing matters, may feel betrayed. Honestly, I feel more worried than betrayed. But it isn't a good feeling anyway. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
