Andrew Newton <andy(_at_)hxr(_dot_)us> writes:
The IETF does not require a royalty free license.
Sure, but it seems evident that RF is practically a requirement for
MARID acceptance and consensus.
It appears that IETF's contemporary policies do not prevent the
sponsor/advocates from including patented IP material into
standards-track specifications, without even requiring the sponsor to
actually enumerate and identify their intellectual property; a mere
claim of the existence of some nebulous IP rights is sufficient, which
can be revealed at any point in the future, at the sponsor's
discretion.
I'm not sure what point you are trying to make here.
Fill in the blanks.
1) How do you base your decision on incompatibility? I ask this because
Courier uses OpenSSL and ships with a file called COPYING which states:
This software is released under the GPL, version 2 (see COPYING.GPL).
Additionally, compiling, linking, and/or using the OpenSSL toolkit in
conjunction with this software is allowed.
According to the FSF, the OpenSSL license is also incompatible with
the GPL. Additionally, is the webmail part of Courier licensed in a
different way?
I believe the Courier author could fix this by adding an exception to
the license. Also, it's possible the usage of OpenSSL is okay if you
consider OpenSSL to be part of the operating system, but that seems like
a stretch from what I've read.
Your message seems to boil down an ad hominem tu quoque that revolves
around orthogonal issues. OpenSSL could be replaced by another library
with the same API. OpenSSL or Courier could tweak their license.
Patents often can't be worked around unless the owner changes their
license... especially if you don't know what the patents cover.
Would there be issues using it with Apache since the FSF also
considers the Apache license to be incompatible with the GPL?
The ASF believes that Apache License 2.0 is compatible with the GPL.
http://www.apache.org/licenses/GPL-compatibility.html
2) Based on my limited understanding of Courier, it seems that the only
document in the Sender ID docset that needs to be implemented directly
into Courier is the SUBMITTER ESMTP extension. The encumbered portions
of Sender ID, -core and -pra, could easily be implemented in a separate
module using the courierfilter interface. Are you unwilling to
incorporate the unencumbered SUBMITTER even if a core/pra courierfilter
were available?
-core is the document that ties it all together so the unknown
patents could cover ... well, I don't know what, but more than PRA.
You may be right that the Courier author might be able to include enough
of Sender-ID to support it and help make it a success. The separate
module would not really be open source, though.
3) If somebody were to patch Courier with Sender ID and distribute it
with such modifications, would you take legal action against them?
That seems like a hard question to answer given that you can't predict
the nature of a future license violation.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/