GPL compliance notice in proc macros

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.

2 Likes

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.

2 Likes

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 crates.io, a LICENSE.md file, or tools like cargo-license or cargo-deny.

11 Likes

I'm using debian and I have never seen any license or contibutor list pop up at boot time. Even installing packages doesn't show their license.

12 Likes

we seem to remember the debian motd being pretty clear about things like licensing.

Right, that only shows when you login on a console or using ssh. It is also only a single message covering all distributed software without listing specific licenses. The equivalent for rust would be to have cargo show a single message (preferably fitting on a single line) applicable to all crates at the start of a build. I'm not sure this adds much value though.

Yeah, I've used Debian, and I've used other Apt-based and RPM-based distributions, and I have rarely ever seen the system display the license or contributors list. That's only appeared for maybe one or two packages, and I've been using Linux for a decade at least. And those packages where I've seen them do that are usually closed-source ones.

The one-line license thing is just under /etc/issue (or a related file somewhere on the system). That can be trivially removed, and its only on the SSH or over the console. As others have said, it wouldn't add any value if Cargo did this (if anything, it would just sew confusion since Cargo cannot technically declare every crate under one license, because that wouldn't actually be correct). Hell, its questionable whether that header line in Debian is even accurate since I'm pretty sure Debian has a lot more than one license in their repositories for different packages.

/etc/motd says you need to look in /usr/share/doc/*/copyright for individual licenses.

$ cat /etc/motd

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
1 Like

Oops, yeah your right, I forgot about that.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.