A while ago I was picking a new SSG and I would have preferred something written in Python so I can hack on it more easily. I ended up moving on because of the license.
Thanks for educating me - I did not know about this.
Not sure I see it as a problem, though. I'm producing static files, and uploading them to a web server. At no point is a user communicating with the program - which I think is the key clause that triggers the AGPL. The whole discussion about templates being treated as code is enlightening - but again: No user is communicating with the templates either.
Furthermore, even if I'm wrong on this, I don't see the leap that the content of the blog has to be AGPL. At worst, I'd merely have to release my templates and any other modifications I've made to the code (custom plugins, etc).
Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't. A lawyer would probably have to sort that out.
The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software. I don't want to learn one tool for personal projects and another for potential work projects, in case the opportunity comes up.
The easiest way to deal with that is to just switch to a tool that has a license that is more widely accepted.
> Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't.
No - it suggests that I'm not a lawyer. I would use those phrases for any license.
Let me put it concretely. Had I read the AGPL, I would have concluded that there is no problem in this use case - just as I would with the GPL or any permissive license. It's only because others disagree, for reasons that seem faulty to me, that I hesitate. Frankly, for me, this is a good example of (unintentional) FUD.
> The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software.
I thought the issue was GPL vs AGPL. If you're avoiding GPL, then it makes it more understandable. In any case, I use it for personal reasons. Were I considering it for our work, we would consult with our lawyers (have done so in the past) - regardless of the license. My work does not involve the web, so I don't have the concern of having to learn two different tools.
I use pelican, mainly because it was the top Python SSG at the time and thought maybe I’d hack on it. I never hacked on it, just used it. I’d probably pick something new if choosing today, like Hugo which has a larger ecosystem
I picked Pelican for similar reasons. All my prior experiences eventually led me to wanting to change some aspect of the blog software, but they were always in languages I didn't know. So I picked Pelican.
In the years since, I write code to get my desired output via Pelican probably once every few years, but it's totally been worth it to have that option. I really got sick of "Let's search to see if someone's written a plugin that does exactly what I need." And then to have the plugin broken with an upgrade.
It's been around for a long time. Has lots of plugins. Easy to extend. Fairly active development.
https://blog.getpelican.com/