(Ok, I know I said I wasn't going to post any more today, but it is
sufficiently close to midnight that I'm going to fudge it. Of course,
everything I say is a lie, so YMMV anyway. :-)
In <55CD79FA-D5F5-11D8-B1F6-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton
<andy(_at_)hxr(_dot_)us> writes:
On Jul 14, 2004, at 7:19 PM, Michel Bouissou wrote:
Such a standard must be public domain, free for anybody to comply
with, use or implement without any kind of licences or constraints
from any entity, in any kind of MTA or software itself governed by
any kind of license, among which Free Software licenses and the
GPL.
Can you please explain the legal technicalities that lead you to
believe that the license for Caller-ID inhibits (a) development and/or
(b) distribution of open source software, and especially the GPL,
under such license?
IANAL. It is my understanding that several lawyers from the OSS
community (the FSF and OSI) are working with lawyers from MS, but I do
not know what has resulted from those discussions.
I have every reason to believe that folks like Harry, Jim and Bob have
the best of intentions to try and get a license that is acceptable to
all parties. Unfortunately, we all know what road is paved with good
intentions. The hell I want to avoid is having this WG end up with an
RFC that can not be easily uses by parts of the SMTP community, in
this case, open source MTAs/spamfilters.
My layman reading of the Caller-ID license raises the following
issues:
1) In Section 2.1, the license granted by MS is nontransferable and
non-sublicensable. So, it is my understanding that if I create a
hunk of software that implements SenderID, I must license it. Now,
if I upload this hunk of code to sourceforge and source forge
starts to distribute it, do they have to go get a license also?
What about all the linux/*BSD distributions, will each of them have
to obtain a license if they bundle my code? Does each ftp server
that mirrors one of these distribution have to get a license?
These kinds of issues are not as much of a problem for commercial
products since there would be contracts and such saying that these
folks are acting as my agent and that these other distributers
aren't creating a new product. However, in the open-source world,
I would expect many of these distributers to change the code, fix
bugs, or add features.
2) In Section 2.2, the Caller-ID license requires *adding* a term to
the existing licenses. Sorry, but I don't think anyone is going to
want to change the BSD or GPL.
3) In Section 6.3, in order to obtain a license, I must either use
certified snail mail, or a fax machine to request a license. I
don't have a fax machine, so I'm stuck trying to send certified
mail and waiting for a reply. So, if you find a bug in my
open-source implementation of SenderID, you can't just fix it and
put a new version up on your ftp site, you have to go running
around getting licenses and wait until you get a response back from
MS.
This all gets back to what Shevek said: "Implementors are not lawyers,
and generally have better things to do with their time." The fact
that I have to dig through yet another new license that requires me to
modify a bog-standard open source license and do so without messing up
is a big burden.
Again, as Shevek said: "I believe that a large part of the reason for
the success of the GPL, BSD or Apache licenses is that the rights of
the user and developer are particularly well understood in those
cases. It's frequently simpler to pick a GPL'd package than to
understand the license of a (possibly better) package under a custom
license."
As RFC3668 says:
In general, IETF working groups prefer technologies with no known IPR
claims or, for technologies with claims against them, an offer of
royalty-free licensing. But IETF working groups have the discretion
to adopt technology with a commitment of fair and non-discriminatory
terms, or even with no licensing commitment, if they feel that this
technology is superior enough to alternatives with fewer IPR claims
or free licensing to outweigh the potential cost of the licenses.
I do not believe that the advantages of the PRA algorithm outweighs
the costs of licensing, or at least, not the current license.
The fact that the IETF generally prefers technology without IPR issues
is not just a philosophical position, it is also a practical one.
Given that SPF-classic can be freely implemented without any hassles,
the adoption of an RFC that is more burdensome runs a huge risk that
people will widely ignore the RFC and just use SPF-classic. Mind you,
there are people who will do this anyway because they don't feel the
PRA algorithm is as effect, but the licensing issue makes a snappy
justification for not going with the RFC.
The problems with the license need to be addressed before the last
call goes out for the drafts. (According to the schedule, that would
be this month.) If the problems can not be resolved quickly, and this
has dragged on for weeks, then I think the PRA needs to be dropped.
It can be dealt with later on when there is more time.
-wayne