There are many who dislike the GPL because of the restrictions it
places on derivative works. There are others who like it for this
very reason. The subject of "which creates freer software, the BSD
license or the GPL?" is frequently argued.
The difference between the GPL and the Microsoft SenderID patent
licenses is that with the GPL, anyone can go out and create a new
program that isn't under the GPL. With the patent license, everyone
has to accept it.
Part of this is the difference between copyright and patent. It is easier
to write a new program that doesn't infringe copyright than a program that
doesn't infringe patent.
As I recall the GPL, you can not create a non-GPL program containing GPL code.
If you include GPL code, you are obligated to GPL your new program.
In that respect, the MS license is actually somewhat freer. So long as you are
willing to negotiate with MS for their cut of your pie, you are able to make
for profit apps containing their stuff. If you give your app away, you are
covered by the already existing free license, just like the GPL.
With GPL, you have no option but to give it away.
Ref. GPL section 2b "You must cause any work that you distribute or publish,
that in whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties under
the terms of this License."
(Actually, that "derived from" language might not stand up in court when the
claim is based on copyright protection. A famous case, recently decided in
a US Circuit Court found that a novel clearly derived from "Gone With the
Wind" did not infringe copyright because it is an obvious parody.)
It appears (IANAL) that the Microsoft patent license is incompatible
with the GPL. This means that such programs as exim and spamassassin
*can not* implement SenderID. This is a problem, and in my humble
opinion, a very serious one.
If you never exercise the option, under the MS license, of charging for your
software, you don't break the GPL. If you do exercise it, you break both
licenses, but MS gives you the option of negotiating a commercial license.
GPL doesn't. If you stay within the terms of GPL, you will never break the
basic terms of the Microsoft license. (There may be problems on the fringes,
but the basics are compatible.)
One of the complicating problems is that the GPL is based on Copyright while
the MS SenderID license is based on Patent. They are not the same, and licenses
based on them will likely be different.
No argument that the license issue needs careful attention, but there is no
reason to make it a bogey man. A "Just the facts, Mam" approach is needed.
It will need the attention of lawyers.
Again I have to add the disclaimer that I am not a lawyer. This isn't legal
advice. It is my understanding of what I have read.
I have to say, after weeks of fairly steady lurking on both this and the MARID
list, that I think MARID would be ill advised to bless SenderID without
explicitly including SPF Classic, and making sure that the result is fully back
compatible with SPF Classic. This opinion has nothing to do with the licensing
issue. The technical side of SenderID is still way too murky. There is
essentially no real world experience with SenderID and important decisions are
being proposed on theoretical cases that are admitted, even by their proponents,
to have quite low probability.
I also have come to question whether the testing of DATA headers
against SPF or SenderID style records is really all that valuable. There are
too many ways to derive the PRA, and too many ways to fail the test. John Doe
sitting at his computer, isn't going to know how to interpret the fact that some
obscure header he has never heard of doesn't come from a Kosher IP, and I doubt
email program writers will be able to make it significantly easier for him.
With SPF Classic testing the envelope information, the decision tree is simpler
and the large majority of possibilities can be handled by fairly obvious
extensions to existing software. Yes, forwarding gets broken in some cases, but
the truth is those cases are already broken in their current form and need
fixing.
For forwarding, SPF just hastens the day of reckoning, Yes those road warriers
who are submitting email by smoke signals, or whatever crazy scheme, are going
to
have to find a more standardized way of doing it. That is going to be a good
thing all around. The industry should be straigtening the mobile user mess out
no matter what happens with SPF.
A perhaps even more important point: Even sysadmins are going to be confused by
SenderID. A significant fraction of them will have to stretch their
knowledge to correctly implement SPF Classic. (This is an established fact.
We have already seen email from exactly this situation on this list.) SenderID
is worse, because there are more ways for it to go wrong.
When a sysadmin starts getting complaints of undelivered legitimate mail from
his customers, if he can't figure it out pronto, he is just going to pull the
plug!!! After a few dozen of these, the word will get out, and you won't be
able to get sysadmins to touch SenderID with a ten foot pole. The same is true
for SPF, but the risk of this failure mode is considerably higher for SenderID.
Mark Holm