Re: Obstacles between us and the finish line

[Ted Hardie <hardie@xxxxxxxxxxxx>]

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