incorrect GPL headers

[cgwalters]

I just noticed that a lot of code has a GPLv2+ header, not LGPLv2+ which is what our COPYING file says.

(Also related: #1179 )

Running git log -G 'under the terms of the GNU General Public' and looking at the log in reverse, f93cb5b is the first commit that imported a GPLv2+ test driver.

However, the next hit after that is c0d15a6 which added some daemon code as GPLv2+, and I don't think anyone noticed at the time...

And since when creating new C files at least I often copy/paste a previous one as a basis, I think it spread.

The first introduction of Rust code in 479406e was GPLv2+ too...which...that code originated in coreos/coreos-assembler@35bd3c6 and didn't have a license header at the time (oops). I guess Jonathan added that, would be curious if he explicitly chose GPLv2+ for a reason.

So um...I am not sure we can easily dig ourselves out of this hole now. We may have to just accept reality and dual-license LGPLv2+/GPLv2+.

However, I would like to take the stance that new Rust code we write should be the "standard Rust" dual MIT/ASL2.0, and new glib-C code should be LGPLv2+. Opinions?

[cgwalters]

And also, we clearly need a license CI test...

[jlebon]

The first introduction of Rust code in 479406e was GPLv2+ too...which...that code originated in coreos/coreos-assembler@35bd3c6 and didn't have a license header at the time (oops). I guess Jonathan added that, would be curious if he explicitly chose GPLv2+ for a reason.

Ouch... I did not. It's very likely I just copied the header from one of the C sources, which happened to be one of the daemon files which used GPLv2+. 😢

However, I would like to take the stance that new Rust code we write should be the "standard Rust" dual MIT/ASL2.0, and new glib-C code should be LGPLv2+. Opinions?

SGTM! Might be too late for src/daemon/ but at least rust/ is new enough that it should just be a handful of people we'd need to ask if we want to relicense the existing code.

Checking now:

$ git shortlog -s --no-merges rust/
    73  Colin Walters
    39  Jonathan Lebon
     3  Rafael Fonseca

So that just leaves @r4f4

[r4f4]

No problems by me.