change to DCC license

Vernon Schryver vjs@calcite.rhyolite.com
Thu Sep 20 00:29:46 UTC 2007


> 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    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.