Hi Justin,
I understand. The Apache JAMES project says that SpamAssassin was the
one seeking clarification 4 years ago.
I understand why SenderID has become moot.
We are talking to legal about the issue.
Thanks for you quick response.
Regards,
Dave
On Apr 18, 2008, at 10:54 AM, Justin Mason wrote:
hi David --
To be honest, I haven't looked at any OSP-covered specs yet.
The Sender ID situation was really quite unpleasant, and involved a
lot of
negotiation and lawyer work, which is never fun (no reflection on the
ASF's great legal team, just a general statement of fact ;). On top
of
this, in terms of "real world" usage, by now, Sender ID seems to be
obsolete; I haven't seen a situation where an alternative couldn't
be used
in its place with similar or better results.
The result is that we have no drive to date to go back and
investigate the
implementability of an OSP-covered spec. Given the amount of legal
hassle
that would be involved, it'd take a _very_ good reason to do so.
For what it's worth -- I, alone, definitely couldn't give an
indication as
to whether we believe the OSP is sufficient to make a spec now
implementable by an ASF project. That's a question for the legal
team,
imo. Sorry ;)
--j.
David Fisher writes:
Hi -
I'm involved in the Apache POI project and we have quite an active
discussion going on that includes discussion about Microsoft's Open
Source
Promise (OSP) [1] and whether that is sufficient license protection
for
the project's users. During the discussion we were pointed at the ASF
Position Regarding Sender ID [2] which was written by the ASF, Apache
SpamAssassin PMC and Apache JAMES PMC.
I couldn't help noticing that Microsoft had made the OSP to the
SenderID
RFC's. Does the project feel that the OSP does anything to
eliminate the
concerns expressed in the position statement?
The OSP makes me think so, but I think you are the definitive
audience to
ask. (I'm asking both projects)
[1] http://www.microsoft.com/interop/osp/default.mspx
[2] http://www.apache.org/foundation/docs/sender-id-position.html
Regards,
Dave Fisher
