ietf-mxcomp
[Top] [All Lists]

Re: Obstacles between us and the finish line

2004-09-03 12:30:35

At 8:13 PM -0500 9/2/04, wayne wrote:

 > 4) IP licensing:  I'm not dogmatic about the GPL or commercial
 licenses, but there are significant MTAs and mail filters that fall
 under both kinds of licenses, and several others to boot.  I think
 that any proposal that has incompatible IP licensing needs to be
 dropped.

Sadly, in response to this post back in July, Ted Hardie (the IETF
Area Director for this WG), told us to stop worry about IP licensing
issues.  I believe the mess we are in right now is a direct result of
this.  Instead of getting the IP licensing issue resolved *much*
earlier on, we now have a crisis and a no-win situation.

There's no reference to which post of mine is meant, but I
assume http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html
is the one to which this refers.

That post did not say "stop worrying about the licensing issues",
it said "Discuss licensing in terms of the engineering decisions"
or more fully:

Comments based solely on the licensing terms without regard to the engineering
choices they affect *do not speak to the question working groups need to
decide*.   The sudden appearance of new working group participants
after postings inviting them to comment is welcome *if they contribute to
the engineering discussion*.  But if you are here to comment on licensing
outside of the engineering context, you are wasting your electrons.

Several posters since that point have made very clear posts describing
the engineering choices and deployment mechanisms which would have to
change in the context of their reading of this license.  I again point
to Eric's post as one example; there are others.

Saying "I don't like this" means nothing.  Saying "I won't implement this"
or "I will deploy this" means something.  Saying "To do this I would have
to implement an external filter mechanism in my MTA and distribute the Sender-ID
filter separately under this license.  The cost of that external filter
mechanism development plus the filter development isn't worth
the spam reduction costs in my environment.  If someone contributed the code
for the external filter mechanism,  however, I would be willing to work
on code efficiency and provide a pointer to an external filter" gives
a lot more for the group to work with.

                                Ted Hardie