Re: [aur-dev] AUR 4 and licensing
I like this idea, but I don't think it's sound to consider something GPL-licensed because the author checked a box or accepted the TOC. I doubt that has any legal significance.
I agree that accepting a one time ToS agreement is hardly binding. That's why I suggested printing out a message with a Git hook saying everything you push is going to be GPL, it's a bit harder to claim ignorance when you see that message every time. We're already in the gray area since there's thousands of packages with no license explicitly listed, and I don't think it's sane to suggest removing those.
Wouldn't it make more sense to use a mandatory two-line header like below?
This switch to Git is already going to cost us a lot of maintainers who simply don't feel like learning it, I can't say I'm in favor for imposing any more requirements. I'm also not really a fan of littering my PKGBUILDs with static text either. Listing the current maintainer and contributors is already less than ideal (with the move to Git, I guess we could stop listing the contributors inline since they're in the logs).
On Mon 13 Apr 2015 12:46 -0230, David Manouchehri wrote:
I like this idea, but I don't think it's sound to consider something GPL-licensed because the author checked a box or accepted the TOC. I doubt that has any legal significance.
I agree that accepting a one time ToS agreement is hardly binding. That's why I suggested printing out a message with a Git hook saying everything you push is going to be GPL, it's a bit harder to claim ignorance when you see that message every time.
We're already in the gray area since there's thousands of packages with no license explicitly listed, and I don't think it's sane to suggest removing those.
Wouldn't it make more sense to use a mandatory two-line header like below?
This switch to Git is already going to cost us a lot of maintainers who simply don't feel like learning it, I can't say I'm in favor for imposing any more requirements.
I'm also not really a fan of littering my PKGBUILDs with static text either. Listing the current maintainer and contributors is already less than ideal (with the move to Git, I guess we could stop listing the contributors inline since they're in the logs).
I don't really like the idea of all this red-tape, requiring one license or another. So I have some concerns. Is there a plan to enforce this? If the PKGBUILD is trivial can you reasonably defend a license? If you want a license why not allow the contributor to select one rather than choosing for them? If I write a patch/etc is it under GPL or is it under the project's original license? So I'm thinking any license of the build scripts should be compatible with the software it is packaging, or at least not impose any new restrictions. Allow the contributor to select a 'do what you want' type 'license' which can be used as a default if the package has a non recognisable license or multiple licenses. Otherwise let the contributor specify the license. Get rid of the TOS. I don't think the TUs want to become the license police. Furthermore this is a topic that most likely should be discussed and decided among TUs in a formal fashion.
On Mon, Apr 13, 2015 at 08:47:12PM -0400, Loui Chang wrote:
If the PKGBUILD is trivial can you reasonably defend a license?
This. Licensing depends on Copyright, so it requires a creative effort to be made. PKGBUILDs, on the other hand, are mostly generic repetitions with some small changes to deal with edgecases. Personally, I think it would be much simpler to just declare all PKGBUILDs and .install scripts uploaded to the AUR to be Public Domain and leave it at that. But, that may just be my own opinion. All the best, -Sam
On 14/04, Sam Stuewe wrote:
Personally, I think it would be much simpler to just declare all PKGBUILDs and .install scripts uploaded to the AUR to be Public Domain and leave it at that. But, that may just be my own opinion.
With that comes the usual issues with international law and Public Domain, though it would be nice, yes. CC0 might be the closest. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
participants (4)
-
David Manouchehri
-
Johannes Löthberg
-
Loui Chang
-
Sam Stuewe