Different license

[jml]

The AGPL is a highly viral license, which means that there are contexts where I cannot use Pelican even though I would want to.

Given that Pelican is not intended to be used as a server-side application, the GPL would preserve the same essential freedoms while allowing a greater scope for use.

I don't mean to whinge. Fundamentally, I am grateful for Pelican and for it being released as open source software. I realize that license changing bugs can be a hassle and I respect the right of authors of a work to choose how it's shared. However, I do want to make it clear that at least one of your users would rather it weren't AGPL.

[justinmayer]

In past IRC discussions regarding this topic, there appears to be consensus that switching to a less restrictive license would be beneficial. At this point, it's just a question of carrying out said license change, which as one might imagine simply hasn't been a very high priority from a project management perspective. That said, there are folks who feel strongly about this, and we want to be good netizens, so we are amenable to switching to a more permissive license. (cc: @liyanage)

(Fellow maintainers: I feel like I've accurately summarized past discussions, but if I am speaking out of turn, please feel free to chime in.)

[almet]

I'm not against changing the AGPL licencing to GPL, but I'm not sure to understand what are the limitations carried by the AGPL.

Also, changing the licensing scheme means contacting all the authors since the beginning of the project and have them agree this change is the right thing to do. Legally, I'm not sure what is the best way to do this, and if we need to have everyone sign-off this choice in some way (and if electronic signature is enough or not).

[gangelop]

^ not that it helps at this point but, a good reason to initially make everything public domain.

[dstufft]

I was concerned about using pelican because I was not sure how the AGPL would interact with the produced output, specifically because some parts of pelican are copied into the output via the themes which I think would imply that the blog posts must be AGPL as well?

[liyanage]

My situation is similar to jml's, I'd like to use Pelican, but AGPL (as well as GPL, at least higher than 2.0) licensing means I can't in some contexts where I'd want to.

I'm willing to contribute to the project by fixing issues or adding new features, but only if I can use the package myself, and that's only the case if it's licensed under something like BSD or MIT.

Like jml I'd like to make it clear that I am grateful for Pelican to be open source and I know I can't expect it to be under any particular license. But I wanted to also make it clear that the project is missing out on some users (and contributors) because of GPL licensing.

[jml]

With the AGPL, there's also some ambiguity of what license I'm allowed to use for my blog posts, and the code in my blog posts.

[FedericoCeratto]

@jml: can you please elaborate? Afaik your posts are not importing and/or executing Pelican's code directly.

[prokopst]

Few thoughts:

• Is it completely legal to reuse the sample configuration for my project? From my understanding I can not for example reuse sample project configuration, because I would use AGPL code, thus I would have to make the configuration public
• Business environment which cares about legality does not like GPL, AGPL even less
• Both Jekyll and Hyde have a less restrictive license, MIT

For me the license is a problem (the sample configuration).

[lucywyman]

If I'm licensing a website made using Pelican, but it isn't making any changes to Pelican source code or replicating Pelican in any way, do I need to use AGPL, or can I use a different license?

[FedericoCeratto]

@lucywyman the license of Pelican does not apply to the contents of your website, in the same way as, for example, the license of Gimp does not apply to images made using Gimp.

[lucywyman]

@FedericoCeratto Excellent -- that's what I thought, but wanted to verify as some friends thought differently. Thank you so much!

[hynek]

GCC is a bad example because they had to add a linking exception to avoid licensing problems.

The FSF is very clear on their interpretation that calling any code of a library in what way whatsoever makes your code derived work. How that applies to templates is a bit unclear, but Drupal maintains:

Yes. Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later. You are not required to distribute them at all, however.

WordPress says:

Part of this license outlines requirements for derivative works, such as plugins or themes. Derivatives of WordPress code inherit the GPL license. Drupal, which has the same GPL license as WordPress, has an excellent page on licensing as it applies to themes and modules (their word for plugins).

There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license. If you disagree, you might want to consider a non-GPL platform such as Serendipity (BSD license) or Habari (Apache license) instead.

Put bluntly: if you’d ask the FSF whether pelican plugins, themes, and content have to be AGPL: their answer would be yes.

That doesn’t mean it will be enforced, but you’ve entered a legal minefield and legs-conscious companies won’t allow their employees to use it.

(To be clear: if that is what you want with your license, it’s your choice since it’s your project. Nobody gets to judge that. However claiming it’s not a big deal is dishonest.)

[FedericoCeratto]

@hynek: In your answer you bulked together "plugins, themes, and content", but they are quite different things. This conversation is about the output of Pelican.

Here are some relevant answers from the GPL FAQ. (See last link regarding the differences between GPL and AGPL)

https://www.gnu.org/licenses/gpl-faq.en.html#GPLOutput https://www.gnu.org/licenses/gpl-faq.en.html#WhatCaseIsOutputGPL https://www.gnu.org/licenses/gpl-faq.en.html#WMS http://www.affero.org/oagf.html

[hynek]

The output is derived work of a theme. So assuming a theme is (A)GPL (I’m sure any designer will disagree with the FSF’s notion that a theme is “minor enough”; it just show again how disconnected from the reality they are) you know where that is heading.

There has been a lot written and a lot of the matter is uncertain because it hasn't been tried in court. But it’s legal liabilities that seem unnecessary and limit your adoption. At least that’s what ultimately keeping me from pelican and I heard it from others too. There’s also companies whose legal departments blanketly forbid the adoption of GPL software for it’s legal risks.

Again: if that’s the intended effect, it’s your call and for you to decide. But licensing using (A)GPL and downplaying the consequences based on your current interpretation is not okay. You could start suing pelican users tomorrow if you wanted (I'm absolutely not suggesting you would).

If you wanted to guarantee legal safety to your users based on the interpretation of the (A)GPL you’re describing, you’d have to add special clauses & exceptions to your license like e.g. crossbar.io: http://crossbar.io/docs/Crossbar-License/ .

Which is effectively re-licencing and you could go for MIT as well. :)

[sigmavirus24]

As someone who has contributed to a few pelican repositories, consider this my official notice of consent to change the license to whatever will benefit the project most.

[datagrok]

I'd be disappointed to see the Pelican license change to one that doesn't protect improvements to the source code from companies who would attempt to proprietize it.

Some have raised a concern that Pelican's license applies to its themes, and since its output is a "derived work" of the themes, the output must be AGPL as well.

From an examination of the source, it seems (and correct me if this is wrong) Pelican themes are simply Jinja templates. Unlike the case with Drupal or Wordpress themes, they are not specific to Pelican and could be used with other projects, and thus not a "derived work." This makes it easy to apply a separate license to each individual theme, and if you follow the FSF recommendation, use simple permissive terms. I see that many in the pelican-themes repo already do employ a variety of different licenses. The only thing left to do is explicitly state that all the code in the included samples/ and pelican/themes directories are not covered by AGPL, and instead provided under a permissive license.

Note that samples/pelican.conf.py is considered configuration and not code, so is already exempt from the AGPL.

Also, I don't represent the FSF. But they will happily answer questions like the ones presented here, just e-mail licensing@gnu.org. I have made several inquiries in the past and their responses have always been thorough and helpful.

Those efforts should be sufficient to avoid accidentally "infecting" users' posts with the AGPL, but it probably won't satisfy parties with a grudge against it, like those with employers who have blanket prohibitions against copyleft.

I think such blanket prohibitions are actually a mistake, not the risk to most businesses that they have been convinced it is, and they would actually benefit in many situations from embracing copyleft code. But they're unlikely to do so anytime soon.

So the decision to re-license comes down to: is it better to use a permissive license that allows private forks that:

• might not give back improvements to the community
• might be incompatible with the original, dividing the user base
• might out-market the original into obscurity, especially if transformed into a proprietary product
• might get baked into a device that users can't modify
• might form the foundation of spyware tools, siloed "services," or add DRM to posts

Or do you consider those scenarios unlikely enough for this project that it's not worth the cost of many people (instead of pushing back against their employer's policies) using a different project instead?

I won't begrudge whichever path you choose; I agree with the FSF that releasing Pelican under a GPL-compatible permissive license is not doing wrong. The code that you release would still provide the four essential freedoms and benefit the community, and maybe(?) no company with the resources to do so will ever attempt to subvert the project.

[liyanage]

For what it's worth, the fact that Pelican is still not under a BSD-style license made me stop investigating it for my project (and possibly contribute features or bugfixes). Instead I'm experimenting with the MIT-licensed Nikola.

[ionelmc]

I'd like to see BSD or MIT too, but getting agreement from 250+ contributors to switch to totally different license is a bit unrealistic.

I think the project should outline clearly what's ok and what's not ok wrt to "not contributing back" in the documentation. ELI5 sort of answers with some more detailed legalese mumbo-jumbo in the next paragraphs for the more skeptic.

[nehalsin]

1. When FSF is talking about ideals like community, helping, sharing, most of us are busy in quarreling about surface talks, snatching, fighting for I, me and mine. We care about things that only cater to us, we don't bother about the neighbor next door, about a weeping stranger, or someone struggling with severe winters in some part of the globe.
2. When we ourselves face the deepest strokes of atrocity inflicting our own basic free behaviour, then we understand this talk of community and sharing and so on.
3. But just because FSF talks of ideals does not mean their time of lives with undying efforts is futile and free of cost. They are protecting rights of a wider community but they also have to protect their own virtue, work and lives by vertical atmosphere syndicating wars, battles, nuclear weapons, viruses, malware so on and so forth.
4. In this sense, it is highly important to first understand idealism of RMS and FSF and then talk about further work done for protection of liberating work, work that makes you rise from gross thinking of hitting the neighbour and getting on further with life.
5. Copyleft, GNU GPL, AGPL are all to protect the work of an individual and still let the community prosper by adding, modifying, distributing their work with anyone they like. It is thereby not a matter of debate but of immense pride and satisfaction that one feels while helping other.

[maxbrito]

Hmm. Some comments here sound like "I really, really promise to contribute one day, but only if you use a license that doesn't make me contribute".

There's the unwritten Internet rule where 1% are vocal about some topic, while the other 99% are happy with the current status. On this talk we have at least 1 out of 250 contributors not caring vocally about license terms, that's 0.4% of the contributor population (if we assume @sigmavirus24 is not happy, albeit he actually just seems to fall inside the 99%, while the participants here asking for a different license are not even contributors).

Maybe running a poll across contributors to ask if they agree to the possibility of permitting other developers of Pelican to (potentially) take their work into a commercial closed-source edition that will be promoted as "better"?

One other option is to simply document what is under the AGPL scope of the Pelican, and what is not. For example, mention that plugins and themes can follow their own terms. This doesn't mean creating exceptions or re-licensing, just make things clear on the documentation level to solve ambiguities as asked here by @dstufft, @ametaireau, @prokopst and @lucywyman.

My 0.2 cents vote on this matter (for what is worth) goes to @datagrok.

btw, Linus had similar dilemma with the Linux Kernel and solved it this way:

NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the linux
 kernel) is copyrighted by me and others who actually wrote it.

            Linus Torvalds

https://www.kernel.org/pub/linux/kernel/COPYING

[mitsuhiko]

JFTR. Amendments to the license that extend the rights granted as as complex to implement as a license change. The linux kernel just clarified the license but there was never any doubt about how this works given how the GPL is set up. This does not apply to pelican however. There is not even a discussion about this as this is exactly the reason extjs sells commercial licenses.

My use of pelican so far has been with a custom theme only that is not distributed with pelican and as such is not distributed at all and the (A)GPL does not activate. However if you do distribute themes or use a distributed theme, then I'm pretty darn sure you will need to keep the content of the blog as APGL as well.

Hmm. Some comments here sound like "I really, really promise to contribute one day, but only if you use a license that doesn't make me contribute".

I would not contribute to Pelican either way but I can only support this thread in the sense that AGPL is a terrible license for such a project and I'm sure whoever chose it, did not spend enough time considering the ramifications. Maybe that is something for future generations to learn from.

[sigmavirus24]

if we assume @sigmavirus24 is not happy, albeit he actually just seems to fall inside the 99%, while the participants here asking for a different license are not even contributors

@nunobrito it's truly poor form to put words into others mouths when you neither know them nor have sufficient information to support your ponderings.

Further your mental model of how people view this is very skewed by your own biases. I would say there's 10% that's unhappy, 70% are ambivalent and apathetic, and the last 20% are actually happy to be using something licensed under the GPL family of licenses.

Pelican is easily one of the better static blog generators out there (having tried Jekyll, Nikola, etc.). When you're working on something where a static blog is appropriate, it would be nice to be able to use the best possible solution. However, the licensing of Pelican means that a significant portion of your website (if not its entirety) must then also be licensed as GPL because of code-copying. This is the same argument the FSF has made about any project that includes any autotools generated code (that the whole of the project then must be GPL'd). The argument is "I would contribute if this were a different license" it is "I would use this for A, B, and C projects and D, E, and F corporate projects because Pelican is awesome and I want to. Unfortunately, the licensing is incompatible with the rest of these projects and the corporate policy on licensing so we can't and we as users are suffering as a result."

Non-lawyers may disagree on this point, but any IP lawyer you talk to will explain that this is in fact a valid and justifiable concern. Please don't try to dismiss the people passionately speaking up in this thread for the last 15 months or try to marginalize them. If anything, I would be rather certain that the existing ambivalent users of Pelican don't fully understand the effects of Pelican's license on their static blogs. Perhaps Pelican never intends to pursue legal recourse against a user, but you can understand why people wouldn't want to place themselves in that position.

[maxbrito]

As mentioned, clarifying the doubts expressed on this talk already goes a good way to explain what can (or cannot) be done within the current license.

Likewise, maybe a poll would bring real data about the contributor opinion on this matter. Maybe also pointing concrete cases of companies that refuse adopting AGPL-based products and explain to contributors that you'd like to see Pelican adjusting to such corner cases, rather than the other way around. :-)

[datagrok]

Regarding @mitsuhiko's points:

Amendments to the license that extend the rights granted as as complex to implement as a license change.

No, while that might have been true for the Linux kernel, I don't think that's the case for this project. Reasons:

1. I mentioned before that pelican themes are just Jinja templates. It can easily be argued, and the Pelican authors can make an explicit statement to attest, that they are a "separate work" and thus are not covered by the GPL or AGPL. Neither are they executable code; such templates may be considered "input" to Pelican.
2. The only templates that might be covered by the AGPL are the ones in the pelican repo because they are located in a subdirectory of the AGPL LICENSE file. The difficulty of contacting contributors for permission to issue a permissive exemption or license those themes separately only applies to those who modified those files. (git shortlog -s pelican/themes reports there's 60 contributors, not the entire project's 296. And of those 60, 12 are contributors to the same file which is marked as MIT-licensed.)
3. pelican/themes/notmyidea/static/css/main.css already contains a statement that it is MIT-licensed and samples/content/another_super_article.rst already contains a statement that it is under a permissive license. It could be argued that the code in these subdirectories have always been permissively-licensed, and no license change needs to be made just to clarify this situation in the documentation.

However if you do distribute themes or use a distributed theme, then I'm pretty darn sure you will need to keep the content of the blog as AGPL as well.

Not if the theme is permissively licensed. The FSF covers this explicitly.

AGPL is a terrible license for such a project and I'm sure whoever chose it, did not spend enough time considering the ramifications. Maybe that is something for future generations to learn from.

Presuming negligence, implying the project is a lost cause, is so rude and uncharitable. Why would you make this statement about fellow developers @mitsuhiko? Can't we work together amicably to find the best solution?

AGPL is a great license for a project that wants to preserve freedom for all users, even against attempts to transform it into a proprietary hosted service. It just needs to be applied carefully in special cases.

I'm trying to help find a path from an ambiguous situation to one where it is clear that the project license does not apply to the user's page content output from the program, as (I imagine) the authors intend.

[mitsuhiko]

@datagrok

I mentioned before that pelican themes are just Jinja templates. It can easily be argued, and the Pelican authors can make an explicit statement to attest, that they are a "separate work" and thus are not covered by the GPL or AGPL.

No, can not. Jinja templates are compiled to bytecode and executed together in the pelican module. There is no separation that the GPL would permit for this. There is also no mode in Jinja that would circumvent this. There is nothing that can be argued at that point and this has been a point of discussion in the past with Jinja and other projects before.

(You could render the Jinja templates in an external process if you want, that would set up a GPL permitted boundary)

[dstufft]

"It could be argued" is not really the kind of statement you want to hang your hat on when deciding the legalities of doing something in my experience. Generally if it could be argued one way, it could also be argued the other way and it's safer to just not rather than take the risk.

[mitsuhiko]

@datagrok since I missed that other part.

Why would you make this statement about fellow developers @mitsuhiko? Can't we work together amicably to find the best solution?

Because it's very important for us as Open Source community to have an understanding of what our licenses mean and how they work. I did not pick the license for pelican, not sure why you blame me for this.

[datagrok]

@sigmavirus24 you have left out quite a bit of detail:

However, the licensing of Pelican means that a significant portion of your website (if not its entirety) must then also be licensed as GPL because of code-copying.

Only if the templates are AGPL-licensed, and I think that is still ambiguous, and that ambiguity is resolvable without herculean effort.

This is the same argument the FSF has made about any project that includes any autotools generated code (that the whole of the project then must be GPL'd).

Autoconf's license contains a permissive exception to solve this problem. As Pelican might also.

[sigmavirus24]

Only if the templates are AGPL-licensed, and I think that is still ambiguous, and that ambiguity is resolvable without herculean effort.

And you're being too optimistic @datagrok.

To be clear, we're discussing templates like this which are checked into the repository? Certainly no one with any understanding of licensing would argue those are not AGPL-licensed. The question then becomes, does any template that inherits from one of those templates also need to be AGPL-licensed? How many templates inherit from those? If the FSF regards templating engines like Jinja2 as it typically regards projects, the answer is most likely "Yes".

Autoconf's license contains a permissive exception to solve this problem. As Pelican might also.

This is actually a fairly significant amount of backpedaling by the FSF then and I'm quite frankly shocked that they've backed away from that ledge. (Must have been one really interesting lawsuit that made them do that.)

[mitsuhiko]

@sigmavirus24

The question then becomes, does any template that inherits from one of those templates also need to be AGPL-licensed?

That's completely irrelevant anyways as a Jinja2 template rendered within a GPL project needs to be GPL licensed by the nature of the way the template engine works. There is no separation of anything. It generates out Python code and executes it. You can't argue that the AGPL does not apply just because you use a different programming language. It runs in the same executable and it invokes GPL licensed APIs.

[sigmavirus24]

@mitsuhiko we agree then. :)

[datagrok]

If the FSF regards templating engines like Jinja2 as it typically regards projects, the answer is most likely "Yes".

Or, we could collect the specific details of this situation into a concise e-mail, and just ask them?

Autoconf's license contains a permissive exception to solve this problem. As Pelican might also.

This is actually a fairly significant amount of backpedaling by the FSF then and I'm quite frankly shocked that they've backed away from that ledge. (Must have been one really interesting lawsuit that made them do that.)

@sigmavirus24 the licence exception has been part of autoconf for at least 15 years. Do you have a link to whatever "backpedaling" or lawsuit you're referring to? If this isn't just FUD I'd like to better educate myself. But I can't find any mention in the autoconf mailing list archives.

[datagrok]

There is nothing that can be argued at that point and this has been a point of discussion in the past with Jinja and other projects before. ... A Jinja2 template rendered within a GPL project needs to be GPL licensed by the nature of the way the template engine works.

@mitsuhiko I'm not convinced, but I would like to reach some shared understanding so this discussion can remain constructive. Could you link to one such discussion or mailing list archive you mention, where this issue has been covered before for use of Jinja within a copyleft-licensed project? I Googled for a while and couldn't find anything.

[mitsuhiko]

@datagrok I don't think the topic came up in the context of Jinja2 on mailinglists before but I that licensing interpretation has always been my stance and I have pointed out out in the past when consulting people on how Jinja2 operates. You can however come to the same conclusion easily if you read the Software Freedom Law Center's statement on the wordpress theme license situation which falls under exactly the same situation as any Jinja2 template: https://wordpress.org/news/2009/07/themes-are-gpl-too/

It also is consistent with the general rules that apply to derived works in dynamic programming languages that have been universally applied in the Python community: any module loaded into an (A)GPL application needs to be GPL compatible and "upgrades" to GPL in the process. There are no exceptions to that rule other than a process boundary.

Jinja2 templates operate like any other Python module, there is no difference. This also applies to many other template languages that are code and not data. There really is not much discussion about this topic as any other interpretation of the GPL in that matter would by extension also mean that the GPL would not apply to programs written in dynamic languages at all to begin with.

You might also have some interest in looking at ansible to see how they went around this issue. Their GPL code is very clearly separated from their BSD licensed playbooks. See here for some information about the issue: https://github.com/ansible/ansible/issues/8864

[mitsuhiko]

@lathan since I just read your comment: you do not want to put something into the public domain. That's even worse than AGPL because it means people from most countries in this world can no longer contribute. You cannot relinquish your copyright in most countries. Just pick a good general license and be done with it.

[tony]

there was a nice utility decorator I found here, thankfully I checked the license first.

so now back to reinventing the wheel, since I'm not going to relicense my code as just for a function

but I'm not sure to understand what are the limitations carried by the AGPL.

I'm not directing this at you or this project specifically, One of the most painstaking tricks (vocal) GPL supporters put you through is acting as if the onus is on you to prove why (A/L)GPL in python is limited. I've exhausted myself over the years doing this. I bring up some here https://github.com/urwid/urwid/issues/41#issuecomment-30979846. And that's urwid, a license less restrictive than GPL and especially AGPL.

I doubt python (A/L)GPL projects held themselves to the same standard of thoroughly reviewing its practical benefits and limits. hey lets ignore the obvious success of mit/bsd/etc. projects, and just opt for a more complex license with more ambiguity and strings attached, all the while we're actually pulling in mit/bsd libs. It's also hilarious when you're told to talk to a lawyer. Oh it's a big business for lawyers these days, you want a static blog generator, django wiki or to use a python library, let me go call a lawyer up for 200-400usd an hour. i'll be right on it

i've helped some projects do license conversions, but even when i've successfully done it... that is, the diplomacy, personal emails, biting my tongue with strongly opinionated people who clearly haven't even read the license, and waiting for the thumbs up to vote "yes, we want change" from hold outs and people who fell off the map, by the time the conversion is over, I end up implementing another solution.

maybe the burden should rest of the ones backing the more sophisticated license to justify the value it brings over alternatives.

[rspeer]

I take it that this discussion didn't go anywhere?

I would love to port my blog to Pelican, but I cannot license my blog under AGPL, and it sounds like I would have to, because my blog would derive from Pelican's AGPL-licensed themes.

Even if re-licensing the entire project is daunting, have you considered granting an MIT license to use the "simple" theme?

[tony]

To the maintainers: you can also consider making future commits MIT+GPL dual licensed, or MIT-only since MIT is forward compatible with GPL.

This isn't really about GPL being good or bad, but more about staying license-agnostic. I like ISC/MIT/etc because it's forward compatible with pretty much every other major license. The other thing is I like keeping the option for my downstream users to pick their own license. This is easy to do with ISC/MIT/BSD, but harder to do with GPL because it's not backwards compatible.

That said - I ended up having to use something else due to the license. This no longer is an issue, but just noting that I ended up losing interest, took a different approach to whatever I was doing, and license played a part. The reason why I say this is I don't think every user with a licensing conflict will end up voicing their concern.

[jorgesumle]

I don't want my code used in proprietary software. You don't have my permission if you want to relicense my commits. Everyone deserves free software. If you want to restrict software freedom, I'd urge you not to do that. Also, there are plenty of static site generators under a lax, permissive non-copyleft free software license.

[tony]

It wasn't freedom for me. I don't want license terms pushed on me or my downstream users.

GPL is a great license. I think in many ways, the trade-offs GPL guarantees are unnecessary since they're de facto anyway. I think, in the end, the downsides of compliance isn't worth the benefit it guarantees. The reason why I think this is, if a project is on GH, someone can build from source if they chose to. A normal consumer won't likely be building from scratch or know how to code.

The other reason is this is website generation software, with a scripting language. There isn't much benefit to guaranteeing access to source when python packages are source distributions - the user can already see the code - and a permissive license would still give a user ability to hack. I don't see that changing, but even if that was the case, a permissive license could just hard fork into GPL later on. It's harder to go from GPL -> permissive.

As for someone potentially releasing a proprietary piece of software - this is only my personal opinion - I don't worry about it much. FreeBSD wasn't hurt when PS4 and Switch built off it - if anything having corporate ecosystems depend on upstream code puts the tendency on them push changes upstream. It's time consuming to maintain private branches and keep them up to date - and in the companies self-interest to send patches upstream. Most of the time, not all the time.

In the end game - I'd rather take the chance of a company using proprietary code, and 50/50% chance they'll send (meaningful, substantive) patches back, than them not use the code at all due to not dealing with the headaches of compliance. That's part of the reason why I think Nintendo and Sony went with FreeBSD - they got all the benefits of open source as a vendor, without the pains GPL compliance created. Even though Linux is far more mature and featureful.

In any event. I moved onto something else. Thank you all :smile:

[jorgesumle]

There isn't much benefit to guaranteeing access to source when python packages are source distributions - the user can already see the code - and a permissive license would still give a user ability to hack.

AGPL already gives the user the ability to hack and contribute back the changes.

As for someone potentially releasing a proprietary piece of software - this is only my personal opinion - I don't worry about it much.

So, because you don't care much about proprietary software you think it's OK to take back software freedom from lots of users.

It's time consuming to maintain private branches and keep them up to date - and in the companies self-interest to send patches upstream. Most of the time, not all the time.

There's no need to. Under the AGPLv3, the companies have freedom to send patches to upstream.

In the end game - I'd rather take the chance of a company using proprietary code, and 50/50% chance they'll send (meaningful, substantive) patches back, than them not use the code at all due to not dealing with the headaches of compliance.

I see, for you it's very important to empower companies that take away the software freedom of users to do nasty things. Because if you don't have nothing to hide and your changes are beneficial to society, why would you hide the source code?

That's part of the reason why I think Nintendo and Sony went with FreeBSD

Do you think I want to work free for those horrible companies? The world would be a better place if they didn't exist.

[mosra]

I thought I would share my opinion here. I created m.css, which is (among other things) a Pelican theme and a bunch of plugins. I slapped a MIT license on it, because all my projects have it and I am personally using those other MIT-licensed projects for commercial purposes -- gotta earn money somehow, right?

The m.css theme is not derived from any Pelican theme, just using it beneath so I guess the license is okay here (?), but some (one or two) plugins are monkey-patching some Pelican behavior from outside, which might be understood as modifying Pelican code. Does this mean I should relicense the plugins as AGPL as well? Does this mean I should move away from Pelican if I want to create a website that presents potentially commercial / proprietary content and source of the website isn't openly available in full? I hope not.

I vote for relicensing Pelican under MIT as well.

[justinmayer]

I appreciate all the many thoughtful comments regarding the license, which — and I feel I must emphasize this point — I did not choose. That said, I think the allegedly viral nature of the license is overstated, and I believe that output generated by Pelican can be licensed however the author wishes. There is also growing sentiment that perhaps the existing license is less liberal but is more equitable.

That all said… Given the difficulty in obtaining permission from nearly 350 contributors for a license change, I believe the question is moot. I simply do not have the time to pursue such an endeavor. And so I think it's time to put this topic to rest. Many thanks again to everyone for taking the time to share your thoughts and perspectives.

[justinmayer]

Do you want to contact everyone who has contributed to date and ask them if they are okay with switching to another license?

[crickets chirp softly in the distance]

If anyone else comes across this issue and would like to volunteer to undertake this endeavor, please file a new issue stating your intention to do so. 💫