The openSUSE project requires spec files to have a license header. It assigns the same license to its RPM spec files as the license of the package itself. So, if a package is GPLv3-licensed, the spec file is also considered GPLv3. The exception is if a package does not have an open-source license, then the spec file is assigned the MIT License.
It seems to be incredibly inconvenient for everybody involved. Is it implied that due to the GPL linking clause, this is (in their opinion) what you have to do?
It’s a really strange choice because the spec file doesn’t link against anything in the code. It’s not to different from a textual description of the build process.
It’s also problematic when the package license changes. Suppose a package with a sole maintainer (who can just do it single-handedly) changes its license from GPLv3 to MIT. Suppose the spec has multiple contributors who all need to agree to any potential license change. Now the spec is stuck with GPLv3 even though the license of the package itself is now much more permissive.
On the flip side, a spec file must (if only to protect maintainers) have some license. “Use the same as the package” is simple to explain, and avoids all kinds of ongoing support requests / discussions / storms in teacups over ‘license changes’ which aren’t really licence changes.
Surely “Use MIT” is even simpler to explains and avoids even more ongoing requests/discussions? I mean what happens if you have 10 contributors to a complicated spec file, then the upstream project changes license from e.g GPL to MIT? You’d need to contact those 10 contributors and get their consent to re-license the spec file! That seems like a wholly unnecessary waste of time.
I can’t say for sure, but it wouldn’t surprise me if “Use MIT” resulted in a steady trickle of well-intentioned-but-ignorant tickets getting raised to the tune of “It looks like you’re relicensing upstreams GPL code to MIT, you can’t do that”.
It would surprise me a lot if that is more work than gathering signatures for everyone who has ever contributed to a spec file any time its upstream relicenses..
We have seen extremely complex projects pull off license changes with no issues… Plenty of the truly huge and complex open source software out there requires contributers to sign a CLA
I think the best argument for it is that if the upstream package maintainers wants to start maintaining the specfile too, i.e. like docker-ce does, having the spec file as the same license as the project makes it easier for the project to pull it into their repo and keep it up to date.
I don’t think that happens very often in practice, but perhaps it happens about as often as upstream license changes, which are also quite rare.
I don’t think I will object, but I think it makes no sense. 90% of PKGBUILDs are just information about the package and a few lines of build instructions copied from upstream. This is not enough to be copyright-able and hence you cannot license it.
90% of PKGBUILDs are just information about the package and a few lines of build instructions copied from upstream.
Yes, this is the problem, but the focus is on the last 10% of the packages here. Instead of licensing only when it meets an arbitrary “creative work” bar, we can just license everything permissively and be done with it.
This is not enough to be copyright-able and hence you cannot license it.
And then you don’t need to care about the license either.
This should be “slapping a license”. Copyright is more or less something that occurs with no work of the creator. If a work is copywritable is has copyright protections no matter what the author does and whether or not the author chooses to enforce them. (At least until the author gives away ownership to someone else or the public domain.) In cases where the work isn’t sufficiently creative it doesn’t really matter. However I agree with Foxboron it is much simpler overall to just get a license from the author all of the time, rather than try to draw a line of what needs and doesn’t need the author’s permission to use.
Yes, what I mean is: in almost all licenses like this you start by asserting your copyright, as the reason why you can give that license.
If you write that you have a copyright on something that is copyrighted by someone else, you have a problem. If you write that you have a copyright on something that cannot be copyrighted, I don’t think it’s too problematic.
In this specific case the license file says “Copyright 2024 Arch Linux Contributors” (without a CTA or anything similar to back it) which is yet something different…
Thanks, I had not read the RFC in detail yet. And I just noticed the first reference in the RFC regarding this (NoC1) is… me on aur-general in 2011! Good to know I didn’t change my mind then. :)
They are planning to use the 0BSD license which doesn’t impose any requirements on the recipient, so it makes no difference whether or not the file is subject to copyright. It is helpful to make it clear that the file can be freely used, in case anyone disagrees with you or is less sure than you about the copyright status.
(When I use 0BSD or MIT-0 or CC0, I say “written by Tony Finch” without claiming “copyright” at all, to avoid silly contradictions.)
You don’t need to claim copyright. If you author the work (and it is sufficiently creative) you have copyright protections for the work. It takes explicit action such as granting a license, or releasing to the public domain to give up your copyright protections. (Of course you can chose not to enforce them, but then the user of the code is relying on your godwill rather than the promise of a license.)
Some countries (the UK for example) have the concept of “database right” and a whole repository of packages like this would seem to be a place it could be applied. Usual IANAL but I don’t think you can blanket say this can’t be licensed.
If that’s the case it’s whoever consolidates the database that has a copyright claim, so there would be no need to assign a licence to each file.
In fact it creates a conundrum where someone could claim that just having a license for each individual file is not sufficient for redistributing the entire collection.
My thought also. I would have said to avoid arguments about it write a notice saying you don’t think this is under copyright, but if someone else thinks so they can have it under CC0 or similar.
Creative Commons are not software licenses, see their FAQ. The use of 0BSD is to be a close approximation of “the public domain” and the intention of CC0.
If you follow the links from that, they explicitly call out CC0 as suitable for software too (not that there is anything wrong with 0BSD either, and the lineage to software licenses might help a bit with acceptance)
On the other hand, CC0 is not an approved OSI licence because it has a problematic disclaimer of patent rights https://opensource.org/faq#cc-zero
Many simpler open source licences are worded so that they cover all uses of the software, so they are implicitly both copyright and patent licences. More complicated licences cover copyrights and patents explicitly. Software licensing is not just a matter of copyright.
The “reply to opt out” relicensing scheme is not something I’ve seen before – I’ve only ever seen “reply to opt in” relicensing, where maintainers wait for all contributors to explicitly OK it.
I wonder if something like this would actually hold up from a legal standpoint.
I wonder if something like this would actually hold up from a legal standpoint.
As noted in the RFC discussion, this would by no means be “OK”-ed by any lawyer as there is ample opportunity to litigate if you really wanted too.
What we are doing is hinging a bet on most of this work not being copyrightable, along with contributors being reasonable about their contributions. If this is not the case people have ample opportunity to invoke their copyright and we would spend the required effort to fix the copyright infringement. We consider this a better balance on risk versus protecting maintainer time and effort.
I also doubt anyone would seriously litigate against package files, which has been remixed, rewritten, translated, borrowed and utilized across multiple distros over 20 decades.
Another example which does what you mentioned, was when we realized our developer tooling had no license and we had to fetch approval from all past contributors.
Very curious how the OpenSUSE policy came to be.
It seems to be incredibly inconvenient for everybody involved. Is it implied that due to the GPL linking clause, this is (in their opinion) what you have to do?
It’s a really strange choice because the spec file doesn’t link against anything in the code. It’s not to different from a textual description of the build process.
It’s also problematic when the package license changes. Suppose a package with a sole maintainer (who can just do it single-handedly) changes its license from GPLv3 to MIT. Suppose the spec has multiple contributors who all need to agree to any potential license change. Now the spec is stuck with GPLv3 even though the license of the package itself is now much more permissive.
On the flip side, a spec file must (if only to protect maintainers) have some license. “Use the same as the package” is simple to explain, and avoids all kinds of ongoing support requests / discussions / storms in teacups over ‘license changes’ which aren’t really licence changes.
Surely “Use MIT” is even simpler to explains and avoids even more ongoing requests/discussions? I mean what happens if you have 10 contributors to a complicated spec file, then the upstream project changes license from e.g GPL to MIT? You’d need to contact those 10 contributors and get their consent to re-license the spec file! That seems like a wholly unnecessary waste of time.
I can’t say for sure, but it wouldn’t surprise me if “Use MIT” resulted in a steady trickle of well-intentioned-but-ignorant tickets getting raised to the tune of “It looks like you’re relicensing upstreams GPL code to MIT, you can’t do that”.
To a close approximation, 0 people read spec files, so I’d be surprised at such a trickle.
If I understand correctly, Fedora defaults all .spec files to MIT, and searching around their bugzilla, I can’t find any confused reports like that.
It would surprise me a lot if that is more work than gathering signatures for everyone who has ever contributed to a spec file any time its upstream relicenses..
How complicated a spec file are you getting for a project with few enough contributors to pull off a license change?
We have seen extremely complex projects pull off license changes with no issues… Plenty of the truly huge and complex open source software out there requires contributers to sign a CLA
I assume this is where you impose a CLA on spec changes.
I think the best argument for it is that if the upstream package maintainers wants to start maintaining the specfile too, i.e. like docker-ce does, having the spec file as the same license as the project makes it easier for the project to pull it into their repo and keep it up to date.
I don’t think that happens very often in practice, but perhaps it happens about as often as upstream license changes, which are also quite rare.
Just a guess: .srpm files have a consistent license then.
I don’t think I will object, but I think it makes no sense. 90% of PKGBUILDs are just information about the package and a few lines of build instructions copied from upstream. This is not enough to be copyright-able and hence you cannot license it.
Yes, this is the problem, but the focus is on the last 10% of the packages here. Instead of licensing only when it meets an arbitrary “creative work” bar, we can just license everything permissively and be done with it.
And then you don’t need to care about the license either.
It makes sense. I don’t think anything bad can come from incorrectly slapping a copyright on something that cannot be copyrighted.
This should be “slapping a license”. Copyright is more or less something that occurs with no work of the creator. If a work is copywritable is has copyright protections no matter what the author does and whether or not the author chooses to enforce them. (At least until the author gives away ownership to someone else or the public domain.) In cases where the work isn’t sufficiently creative it doesn’t really matter. However I agree with Foxboron it is much simpler overall to just get a license from the author all of the time, rather than try to draw a line of what needs and doesn’t need the author’s permission to use.
Yes, what I mean is: in almost all licenses like this you start by asserting your copyright, as the reason why you can give that license.
If you write that you have a copyright on something that is copyrighted by someone else, you have a problem. If you write that you have a copyright on something that cannot be copyrighted, I don’t think it’s too problematic.
In this specific case the license file says “Copyright 2024 Arch Linux Contributors” (without a CTA or anything similar to back it) which is yet something different…
As mentioned in the RFC, this is the most common, but not the only case. Just look at gcc
Thanks, I had not read the RFC in detail yet. And I just noticed the first reference in the RFC regarding this (NoC1) is… me on aur-general in 2011! Good to know I didn’t change my mind then. :)
They are planning to use the 0BSD license which doesn’t impose any requirements on the recipient, so it makes no difference whether or not the file is subject to copyright. It is helpful to make it clear that the file can be freely used, in case anyone disagrees with you or is less sure than you about the copyright status.
(When I use 0BSD or MIT-0 or CC0, I say “written by Tony Finch” without claiming “copyright” at all, to avoid silly contradictions.)
You don’t need to claim copyright. If you author the work (and it is sufficiently creative) you have copyright protections for the work. It takes explicit action such as granting a license, or releasing to the public domain to give up your copyright protections. (Of course you can chose not to enforce them, but then the user of the code is relying on your godwill rather than the promise of a license.)
Some countries (the UK for example) have the concept of “database right” and a whole repository of packages like this would seem to be a place it could be applied. Usual IANAL but I don’t think you can blanket say this can’t be licensed.
If that’s the case it’s whoever consolidates the database that has a copyright claim, so there would be no need to assign a licence to each file.
In fact it creates a conundrum where someone could claim that just having a license for each individual file is not sufficient for redistributing the entire collection.
My thought also. I would have said to avoid arguments about it write a notice saying you don’t think this is under copyright, but if someone else thinks so they can have it under CC0 or similar.
Creative Commons are not software licenses, see their FAQ. The use of
0BSDis to be a close approximation of “the public domain” and the intention of CC0.If you follow the links from that, they explicitly call out CC0 as suitable for software too (not that there is anything wrong with 0BSD either, and the lineage to software licenses might help a bit with acceptance)
On the other hand, CC0 is not an approved OSI licence because it has a problematic disclaimer of patent rights https://opensource.org/faq#cc-zero
Many simpler open source licences are worded so that they cover all uses of the software, so they are implicitly both copyright and patent licences. More complicated licences cover copyrights and patents explicitly. Software licensing is not just a matter of copyright.
So “or similar” then.
[Comment removed by author]
The “reply to opt out” relicensing scheme is not something I’ve seen before – I’ve only ever seen “reply to opt in” relicensing, where maintainers wait for all contributors to explicitly OK it.
I wonder if something like this would actually hold up from a legal standpoint.
As noted in the RFC discussion, this would by no means be “OK”-ed by any lawyer as there is ample opportunity to litigate if you really wanted too.
What we are doing is hinging a bet on most of this work not being copyrightable, along with contributors being reasonable about their contributions. If this is not the case people have ample opportunity to invoke their copyright and we would spend the required effort to fix the copyright infringement. We consider this a better balance on risk versus protecting maintainer time and effort.
I also doubt anyone would seriously litigate against package files, which has been remixed, rewritten, translated, borrowed and utilized across multiple distros over 20 decades.
Another example which does what you mentioned, was when we realized our developer tooling had no license and we had to fetch approval from all past contributors.
https://github.com/archlinux/devtools/pull/62
I love their choice of license.
FreeBSD made this explicit in 2005 with the BSD2 license that the src tree also uses: https://github.com/freebsd/freebsd-ports/commit/2654a642da69d34276779c58e80128f3fff9c6d8