search

Vimux / Mainroad

Responsive, simple, clean and content-focused Hugo theme based on the MH Magazine lite WordPress theme
https://mainroad-demo.netlify.app/
GNU General Public License v2.0
911 stars 459 forks source link

GPLv2 should be made visible to site viewers (necessary license compliance) #303

Open wareya opened 1 year ago

wareya commented 1 year ago

The HTML and CSS files in this theme are licensed under the GPLv2, and when combined into the rendered final static site, the resulting files (or at least those that contain text from the theme, which is almost all of them) must also be GPLv2 (and almost certainly are). But this isn't indicated anywhere in the files hugo generates when using this theme. So, right now, it's up to users of the theme to manually disclose the use of the GPLv2. I think it should probably be noted in the footer credits. (Even if the resulting files are not, in their wholes, licensed under the GPLv2, the parts that originate from this theme definitely are, otherwise the license would be getting laundered away during rendering.)

If the intent is not to make the generated website text GPLv2, which is almost certainly what's happening right now, then you need to add a license exception of some sort for the site output, and get every contributor to agree to said license exception. For example, the FSF recommends a particular exception for the javascript components of GPL-licensed website themes, to allow them to dynamically interact with non-GPL code (including non-GPL HTML files, etc): https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#WMS. This is not weird, hypothetical, or mistaken, it is just how the GPL works (as evidenced by the given GPLv2 FAQ link).

Side note: Hugo is licensed under the Apache 2.0 license without the LLVM exception, so it's incompatible with the GPLv2. This is not automatically a problem, but if Hugo adds any nontrivial/copyrightable text of its own to the website data it generates, that would create an illegal-to-distribute combination of Apache 2.0 and GPLv2 texts. (Assuming Hugo doesn't have its own license exception for generated site content.) I don't know whether Hugo does this, but it's important to be aware of the possibility.

Vimux commented 1 year ago

I'm sorry, is that your legal advice? I am not a lawyer, but I can't agree that we need any additional attribution(s) somewhere.

you need to add a license exception of some sort for the site output

Be more specific, please. Because…

For example, the FSF recommends a particular exception for the javascript components of GPL-licensed website themes, to allow them to dynamically interact with non-GPL code (including non-GPL HTML files, etc)…

The corresponding reference describes a different situation, not even for "GPL-licensed website themes". If I understand correctly, it describes a situation when you license your (new) templates under simple permissive terms and JavaScript files under GPL + additional exception notice.

This is not weird, hypothetical, or mistaken, it is just how the GPL works (as evidenced by the given GPLv2 FAQ link).

Considering all the above, I would not be so categorical in judgments. That link doesn't describe how GPLv2 works. At best, FAQ describes how GPLv2 + special exclusion license notice works with non-GPL parts licensed under simple permissive terms. As for me, it doesn't sound like "how the GPL works" even in a theoretical FAQ example with all corners cut off.

However, do you have real-world examples of this weird bundle of licenses used on the web (templates) specifically?

P.S. I'm on vacation, so I apologize for the long delay in responding.

wareya commented 1 year ago

I'm sorry, is that your legal advice?

I am not a lawyer and this is not legal advice. It might be weird for anyone to care or even think about this, but that doesn't mean that it's not happening.

The corresponding reference describes a different situation, not even for "GPL-licensed website themes". If I understand correctly, it describes a situation when you license your (new) templates under simple permissive terms and JavaScript files under GPL + additional exception notice.

That reference is still relevant here. It describes the interaction between Javascript code and HTML/CSS template under different data. Regardless of which direction it goes in, the existence of the exception demonstrates that the FSF considers HTML/CSS code as distributed to be possible to subject to the GPL; otherwise, the GPL'd Javascript code would not cause the HTML/CSS code to become subject to the GPL when combining them. So, if you GPL some HTML or CSS data, then it or anything based on it will be subject to GPL virality, even if it's in a context where the concept of virality makes no sense. If this were not the case, then contexts were virality doesn't make sense could be used to launder away the GPL.

The GPLv2 only allows the recipient of the GPL'd software to redistribute it or its code or its compiled form to another person according to the terms of the GPL. Which exact section of the GPLv2 is being invoked to allow the website owner to transmit the theme depends on whether the HTML with text from the theme in it counts as a compiled object or as source code, but both ways, a license disclosure is necessary.

From another perspective, if the generated website HTML/CSS text as shared with the website viewer is not licensed under the GPL, then the license is being laundered away, and someone could visit a site and get "licenseless" bits of Mainroad theme text by scraping. Laundering away the GPL like this is not legally possible, and the GPL is designed very carefully to ensure this. So the template-related text as being transmitted to the website viewer must be licensed under the GPL, cut and dry.

The possibly relevant sections of the GPLv2 are 1:

You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program

(for source distributions)

and 2-b:

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.

(for derivative works and binaries)

Vimux commented 1 year ago

I read your reply and am only more confused than before.

As I said earlier, no more notices are required to comply (in the footer section, for example). Furthermore, because I don't know exactly how different users use the theme, indicating such a footnote may be misleading in some cases. So it's better not to do that at all.

Now back to the second one (license exception). When I said to be specific, I pointed out that the FAQ example describes a different situation. I wanted to see real exceptions in our area (web templates), focusing on output or part of it. If this is how the GPL(v2) works, such examples should not be so rare, right? That was my main point. In practice, the potential issues of such exceptions, including implementation difficulties, would bring only downsides.

MTecknology commented 1 year ago

Which exact section of the GPLv2 is being invoked to allow the website owner to transmit the theme depends on whether the HTML with text from the theme in it counts as a compiled object or as source code, but both ways, a license disclosure is necessary.

To be clear, the issue you're reporting is specifically with regard to what is definitively the "compiled" product of this source code. The actual HTML produced /is/ the compiled work; the templates used to generate it are part of the source code. The difficulty required to deconstruct pieces of the theme is not relevant; the final product is the preferred format for distribution.

This is a module of the application used to generate a website. When a person sees a license mentioned on a website, they will generally assume that the license applies to the content. There /could/ be an argument made for saying that there should be a header tag that identifies licenses used for content generation, but in practice this is extremely rare.

If you want to meet this strict level of compliance, then you need to review every component in the toolchain, which also includes determining what your toolchain is. Is the bash license something you need to represent? what about the golang license? what about Makefile or any scripting language used to build page stubs?

By the time you're done with that review, you're well outside the scope of this project (module). The final result will look similar to this: https://try.gitea.io/assets/js/licenses.txt--Javascript is also a special exception for reasons that don't apply to this project.

From a DFSG perspective, the license terms appear to be met.

MTecknology commented 1 year ago

© 2023 Mainroad. Generated with Hugo and Mainroad theme.

After thinking about this more, it occurred to me that this theme /does/ provide a link to the source code in the default footer of every singe page. This link provides the full license text, so ... "problem solved." :)