License somewhat misleading

[Paul Ganssle]

This project is licensed under ISC, but has a hard requirement on pelican-plugins/asssets, which is under the viral AGPL license, and cannot (as far as I can tell) be pip installed. IANAL but I'm fairly sure that vendoring pelican-plugins/assets as is suggested in the documentation would trigger the share-alike provisions of the AGPL, and so as documented, this project is effectively under AGPL.

Ideally either assets would be dropped (replaced or otherwise) or the documentation updated to show how to set up assets such that it does not trigger these viral provisions. In any case, it's probably worth highlighting (possibly early on) that something like this might be a problem.

[Jonathan Sharpe]

[Caveat: I am also not a lawyer.]

It's worth noting that neither Bulrush nor pelican-plugins is much use without Pelican itself, which is also released under AGPL-3.0. As well as Pelican and the plugins, Bulrush is based around:

• less, which is released under Apache 2.0;
• bulma, released under the MIT license; and
• webassets, released under BSD 2-clause.

However I'm not distributing any of these; everything included in the repo (if you're using the submodule pattern) or the bundles on PyPI (if you're installing it via pip) is code that I wrote. My understanding (which may admittedly be incorrect) is that these other packages would be considered peer dependencies, and separate to the license for Bulrush itself.

The primary use case I was considering is people using Pelican to generate blogs, in which case the thing they're distributing, the resulting blog, doesn't actually include any of the above (Bulma's stylesheet comes in via a CDN link, not actually served as part of the blog). Pelican, assets, lessc, etc. are only used when the blog files are generated.

The licensing would be relevant if you are distributing a product that bundles Pelican, Bulrush and the rest of the above dependencies, for example if you are creating a blog generator based on these products (this may be the situation you find yourself in). In that case you are already affected by AGPL via Pelican, whether or not you choose to include Bulrush or any of the plugins.

All of that said, perhaps I should add a disclaimer into the README to make the limits of the licensing clear. Would something like:

Note: Although Bulrush is released under the ISC license, it is designed for use with Pelican and pelican-plugins, which are released under the AGPL, and the Less compiler, which is released under the Apache 2.0 license. This may impact the licensing options for a project using Bulrush. See #17. For more information, seek appropriate legal advice for your jurisdiction.

under the Other Requirements section be acceptable?

Thanks for taking the time to contribute to Bulrush!

[Paul Ganssle]

@textbook I think the fact that Pelican is the software that generates the static site is not particularly relevant to the project from a GPL perspective, it's not like the GPL license provisions are triggered if you use GIMP to edit an image.

The problem is that pelican-plugins is AGPL and the recommended course of action here is to bundle that project in with yours (as opposed to pip install-ing it in which case it's system installed rather than included as part of your project). bulrush itself doesn't bundle the plugins so it is fine to be under ISC, and I think you can structure a project such that the plugins are not included, but you have to go out of your way to do it.

There's no need to mention the Less compiler because for one thing Apache 2.0 is a permissive license (so even if you do bundle it you just need to leave the copyright notice intact, there's no virality), but more importantly, like Pelican, it's just a program used during the compilation of the static sites, it's not actually included in the project used to generate the site.

Either way, I'm fairly sure the GPL provisions don't transfer over to the content of the sites. It's more questionable whether they transfer over to the CSS / HTML styling, but if you create a (local) repository that includes pelican-plugins so that you can use assets, I think that project may trigger the GPL provisions (in which case you'd need to make sure that that project is licensed under AGPL and make the source code available).

Frankly, it's ambiguous enough that I think the best course of action would be to try to drop the requirement for assets. From what I can tell, the only reason that plugin is needed is to activate webassets in Jinja2, it seems like it can't be terribly difficult to write your own wrapper for that - that said, I am not familiar enough with Pelican to do so and I'm probably going to avoid Pelican in the future because of the licensing problems, so I'm not exactly volunteering to do this.

[Jonathan Sharpe]

If I'm following your argument correctly the issue isn't so much that the license for Bulrush itself is misleading, but that the license for a project using Bulrush per "One way of achieving this is..." is potentially incorrect, as it includes the AGPL-3.0-licensed plugins repository as a submodule. My understanding (caveats as above) is that the use of submodules doesn't imply derivation (see e.g. https://softwareengineering.stackexchange.com/questions/240633/is-licensing-an-issue-for-git-submodules).

The Pelican docs aren't specific on how to access the plugins, and the README of that repo does suggest just cloning it, I can't see any specific official advice on building a project that includes the plugins and the licensing considerations that implies. Given the ambiguity I have no immediate plans for changes to Bulrush, but I will add a note to that section of the README.

Thanks again for bringing this to my attention.