GPL compliance notice in proc macros

We should probably strive to stigmatize randomly dumping things during builds. Just imagine how annoying builds will become once corporations realize they can sponsor developers to dump really annoying ads during builds. Let's nip this in the bud.


You'd think legal notices are quite different from ads.

Well, they are different in many ways, but the difference doesn't really matter here. When compiling your code, you shouldn't get any output except from the normal cargo output and stuff like warnings and errors.


We maintain that it is important for proc macros to be able to print legal notices.

I'm aware you want to be able to print during build for other reasons, so why not write up a general RFC to get an official answer on whether it will be supported?


are you really tho? there are so many helpful things to do here, from acknowledging the license terms to acknowledging the contributions of ppl from various communities.

this thread is still about acknowledging the license.

(somewhat related side-note: the fact that cargo doesn't really do anything with authorship/contributor information kinda defeats the purpose of having it. why not proudly display those when compiling?)

I'm not a lawyer™, but proc macros are compiled into dynamic library and linked to the compiler process to allow compiler to call it to compile other crates. And the rustc is not a GPL binary. Is it legal at all? You may need to use LGPL instead.

Not a lawyer either, but even if it is linked during compilation, it is the distribution of a resulting binary that triggers the GPL. If you are distributing source and people are running that compilation themselves, the GPL won't stand in your way.

1 Like

I would definitely not want to ever use a GPL'd proc macro from anyone who believes in the FSF's definition of derivative work.


For me it's a pretty simple principle: When I'm building, I only want to see build-related information.


As far as I can tell the FSF does not define "derivative work". They operate within the copyright law. Which is where "derivative work" gets its meaning from.

They do licence their code with whatever terms and conditions. We are all free to accept the licence conditions and use the code with those terms, or not. Same as any other distributor of copyrighted material, open source, proprietary, whatever.

Truth and accuracy are only tangentially related to whether someone takes you to court. If they believe in the FSF's definition, then they're likely to cause me expensive legal fees even if I win.

1 Like

It's true that anyone can take you to court for anything. Especially in the USA.

However I don't see that the FSF's definition of *derivative work" differs from what copyright law says. Has the FSF ever taken anyone to court on unfounded grounds?

What you say is true of using any licenced, copyrighted work from any vendor. So why single out the offerings of the FSF? Do you have an example of something bad happening due to the FSF's legal actions?

Because the FSF believes that linking a shared library creates a derivative work, rather than a collective work. Other proponents of reciprocal licenses do not generally have that belief, as far as I know.

(I've not seen any indication that this is a settled legal question, thus my use of "belief". If you have case law demonstrating otherwise, I'd be interested to see it.)


I think if your code in your proc macro is super awesome and people need it you might not drive away users. But if your code is not super awesome and people do not "need" it then there is a very good chance that people will avoid it because humans are humans.


Luckily, free and open source licenses don't require you to acknowledge them. They grant you extra rights and privileges which you would not have by default. They do this automatically without you having to do anything. It is then your choice if you want to exercise any of these right, e.g., you decide if you want to modify the source code or distribute a binary (with source code for free software, and potentially without source code for open source software).

Your correct on this one. From 17 U.S.C. 101:

A "collective work" is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.
A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work".

The FSF can't actually change this. Their license may say that a derivative work is different than the above definitions but I'm pretty sure that the above definitions supersede those defined in the license agreement. They are, after all, federal law. I'm no lawyer, though, and I don't think the FSF's definition has been tested in court.

Edit: fixed typo and added a link to source.

Also, making proc macros print GPL licenses -- or make any part of a build process print license notices -- is just ridiculous. When I build something, I just want to see the output relevant to the build. At that point I don't necessarily care about the contributors or the license -- I might just want to use the software or library. If I want to read the license, well, that's what the LICENSE file is for. How would you feel if, every time your computer booted, you had to read the license and the contributors list? That's essentially what your wanting to impose on us.

And yeah, you might say, "Well, we can just add a flag to tell the system that you've agreed to the license". Sorry, but still no. Like I said, I don't care about the license when building something. That's completely unimportant, just as you don't care about the license of the various components of your operating system and firmware that are executed during boot. If you cared, you'd dig up the licenses yourself. If you want to print license/contribution info in your software in, say, an about dialog or when printing the version of the software on the CLI, go for it. But don't go blasting it in my face when all I want to do is build your software.


We already do. Have you never used Debian?

Please don't do this. If you flood my screen with licensing crap every time I run cargo build, I'm going to make PRs to every one of my dependencies that patches out your proc-macro with something less obnoxious.

I 100% agree with you that licensing is important, but there is a time and a place for displaying GPL notices and cargo build isn't it. Leave the licensing information to already established locations like Cargo.toml, the page on, a file, or tools like cargo-license or cargo-deny.