Salmon, a Python Mail Server
salmon-mail.readthedocs.io
salmon-mail.readthedocs.io
https://anvil.works/blog/email-driven-apps
(There's a video example at that link, where I build and deploy a Mailinator-like service from scratch in a couple of minutes.)
> Salmon is a fork of Lamson. [...] Lamson was relicensed under a BSD variant that was revokable. [...] I read that to mean that I could make a contribution but then have said work denied to me because the orginal author didn’t like the colour of my socks. So I went and found the latest version that was available under the GNU GPL version 3.
Does anybody know the backstory here?
The clause:
The copyright holder reserves the right to revoke this license on anyone who uses this copyrighted work at any time for any reason.
(Then again, it might mitigate the likelihood that a court would limita the licensors recovery after revocation based on the principle of promissory estoppel.)
If I had to guess, I'd guess that's why Salmon says it forked from a GPLv3 release of Lamson.
Yes, it does say that. That doesn't actually override a law which makes it revocable at will irrespective of it's terms—the license is governed by the law, not vice versa.
Whether the GPLv3 is a gratuitous license probably depends on the circumstances of licensing in a particular case and not the text alone—its certainly possible for it to be a contract license instead, but it's not, AFAIK, clearly one in the general case.
Try revoking one of those and suing a site for infringement on grounds that it's impossible to grant an irrevocable license, and let me know how it turns out for you.
Those are not gratuitous licenses granted by the rights holder, they are contract licenses in which the license are part of the exchange for services the site operator is providing for user.
> Try revoking one of those and suing a site for infringement on grounds that it's impossible to grant an irrevocable license,
I never said it's not possible to grant an irrevocable license. I said gratuitous licenses are revocable at will as a matter of law. I expressly noted that free software licenses are not, in all circumstances, a gratuitous.
It seems to me that Zed felt that he had been taken advantage of from users of his open source software in the past and this is simply a provision to guard against that. Whether you agree with his reasoning or not, it's not fair to just dismiss it and assume malicious intent.
Imagine you tell your neighbors they can use your pool so long as they act responsibly otherwise their access would be revoked. You're not going to spell out every little thing that they can/cannot do. You'd just hope that they'd use common sense and revoke their access if they do something you find intolerable. Imagine your neighbor responding to this offer, "Uhh yea, that's not going to work for me. I want unrevokable access." Ridiculous right?
As far as I can tell, nobody assumed it was malicious, so maybe you can put that straw back in storage.
This isn't a straw man. Read the parent:
"No, but the clause in that license is gross. He can sue any of his users at any time if he decides he doesn't want them to be his users anymore."
OP is entitled to his opinion, but he's not giving Zed the benefit of the doubt. He is framing it in a way that makes it seem Zed will exercise this right unreasonably. At least, that's the way I understood what he said.
You appear to be arguing that the behavior isn't gross in general, in which case rando definitely is the right measure. Maybe you're only arguing it's not gross when Zed Shaw does it. That seems dubious to me, in that a) most people don't know who he is, and b) many reasonable people differ from you in their analysis of his reliability. (Indeed, many people mainly know him as being a high drama jackass. [1]) Maybe you're just arguing it's not gross to you and when it's Zed Shaw, but even there the neighbor thing is a bad analogy in that your relationship with Zed Shaw is not social, but parasocial. There is no reciprocal benefit serving as a check on his behavior.
> He is framing it in a way that makes it seem Zed will exercise this right unreasonably. At least, that's the way I understood what he said.
You understood it poorly. He said "can", not "will". Contracts are not about giving people the benefit of the doubt. They're about locking things down to remove doubt. If we just assumed good things about everyone, we wouldn't need contracts. So this is analysis of capability, not intent.
Given that the clause is there, I think there are two reasonable interpretations: a) Zed Shaw is an idiot, who puts random clauses into licenses, or b) Zed Shaw is reasonably smart, and put that clause in there because he was thinking of cases where he'd use it. On whom? In what circumstances? The license doesn't say. It introduces a great deal of legal risk, and of doubt. It seems a little rich to me for Shaw to go out of his way to create a great deal of doubt and have anybody expect he should be given the benefit of it.
[1] https://techcrunch.com/2008/01/01/zed-shaw-puts-the-smack-do...
You seem to be arguing that the analogy is bad because there is no check on his behavior, I don't know why this is a necessary condition, but it's not true anyway, there's the same check as in the analogy: reputation. If I deny access to someone to my pool for no reason or a bad reason, my reputation will suffer in the community. It's the same thing in open source. That is why it is often described by people as a community.
I don't think I did understand it poorly. Using a word like "gross" denotes a certain emotion. They also said, "I would rather use non-free software than risk being sued just for being a user." This makes it sound like getting "sued for just being a user", in other words, unreasonably, is likely. All I'm saying is that I don't think that risk is as high as OP is making it seem, especially if you're not a bad neighbor, which I think is a reasonable thing for Zed to expect.
I'm arguing the analogy is bad because it is not congruent to the circumstance. Zed Shaw does not have a personal, reciprocal relationship with everybody who sees that package and thinks about using it. One does have a personal, reciprocal relationship with the neighbor using one's pool. (Reputation is possibly a consideration, but strongly secondary.)
> This makes it sound like getting "sued for just being a user", in other words, unreasonably, is likely.
No. It makes it sound like a possibility. Which it is, or the clause wouldn't be there. A possibility of an unknown frequency but with significant risk, so worth considering during license examination.
I would rather use non-free software than risk being sued just for being a user.
REVOKED!
well, unless you’re into that
Lamson isn't a perfect fit for the system, but it did make it easy to get started. Unfortunately it also had a number of bugs I had to fix, since the project was defunct. I should check to see if salmon needs those fixes.
My use case needs to save it to a database and make various decisions depending on the sate of the database (e.g., send notifications to anyone watching the ticket and update due dates for the support SLA). Since this database access is more efficient if the process stays connected to the database, it's better to have a long-lived process which handles mail as it comes in than to launch a new script on every incoming email.
Lamson serves as both the procmail side and the script side. It's a long-running process that routes the incoming email to the appropriate business logic internally. And since it's in Python, it's easy to integrate with our existing Django database and business logic. It's not perfect, but it works well enough that I'm not actively looking for a replacement.
I have 20 year old code that does the same client/server thing, by having procmail leave files in a directory that the daemon is watching for new files to appear in.
So I'd agree that it's a useful piece of sugar!
So I guess the reason I don't use procmail (aside from it not having a release since 2001) is that postfix is sufficient :->
I was evaluating it for the use case where I needed to receive emails, and then respond based on the user's position in a decision tree.
I worked on a system years ago that did this for FBL reports.
I have since switched over to aiosmtpd [1], a Python 3 based SMTP server using asyncio that was developed by Barry Warsaw and friends.
Is there any design documents? The stuff to explain the design, architecture, motivations, and intent.
Why!?
From the docs
The only bit I see that talks about something similar is, "Salmon is designed to sit _behind a traditional mail server_ in the same way a web application sits behind Apache or Nginx", emphasis is mine.
> Salmon is best deployed behind another mailserver such as Postfix or Sendmail - much in the same way as you host a WSGI application behind Apache or Nginx.
It is a combination of developers wanting to have cross platform end users, while also working around restrictions in place on corporate networks. It's been downhill since hotmail.
Node.js / Python both have very good support for http. Soap etc, run a web server for quick file serving from command line if you want. Dgraoh and other tools can easily be interfaced via http.
Why not leverage all that?