> From: Jeff Mincy > Sorry I wasn't clear. I don't want to run across something calling itself > SSS (Super Spam Solution, which could be anything) only to figure out > later that it is a modified DCC.
The current license says something about keeping the "copyright notice and this permission notice," but that hasn't stopped plenty of anti-spam appliance vendors from shipping whatever they find on free CDROMs (always SpamAssassin and sometimes DCC and others) as their own unique Super Spam Solution(tm). If they'd use their own DCC servers instead of the public DCC servers, I could ignore them. If the repackagers would keep up to date, I could ignore some of the appliance vendors. If the repackagers would not break updatedcc, a lot of sites could update and fix things. I can't count the number of times I've urge a site that has pegged the public DCC server DoS defenses to update and been told "We can't until X releses new RPMs." I don't think the repackagers intentionally ignore ./configure and break updatedcc. It's just that they've never written and shipped non-trivial code. It never occurs to them that they don't need to rape and pillage with sed to set directories but might use ./configure. It also never occurs to them that updatedcc might exist. > The name is useful for deciding to look at > it in more detail. The name is not going to help that much when looking > at the different version in more detail, although it should give some idea > where the significant differences should be. The name of a product is a long way down on my checklist, but I also assume without other evidence that the sales stuff is all lies. > I'm not sure if the standard Debian/Ubuntu/Redhat type repackagings > should count or not. Such repackagings are "standard" mostly in the packing mechanisms. The repackagers often fit local conventions such as "put big files such as dcc_db in /what/ever," but they also always add their own improvements. Perhaps that is because those who get stuck repackaging odd minor things like DCC don't have enough experience to know that anyone can always find something to add or improve in anything, but that saying "No" takes work, thick skin, skill, experience, and perhaps talent. > I was thinking about modified checksums affecting the rest of the DCC > network. On second thought this isn't all that likely since any changes > to the checksum would affect the results. Yes, non-standard DCC checksum functions would look like invisible noise in the data to standard DCC clients and only bloat the server databases. They would not be useful even to the non-standard clients unless the non-standard clients see a lot of mail. > Could something along these lines be made part of the license? Eg if > you redistribute a modified DCC you must send an announcement. The laziest tactic is to get your changes adopted into the official source. That saves work in merging your changes into future versions, and shifts the responsibility for maintaining your improvements to the official source. The second laziest tactic is to build a patch. With luck, you can run your patch against future versions with very little effort. Allowing modified DCC source with announcements would not solve the problems with the modified versions. Those who do "source forks" because they are too lazy to use those really lazy tactics would still be shipping their 2.5+ year old versions that cause troubles and that they can't update in part because they've lost the recipe and reasons for their sed scripts. Vernon Schryver [EMAIL PROTECTED] _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
