Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#6510 - license field restriction

Attached to Project: Pacman
Opened by Aaron Griffin (phrakture) - Thursday, 01 March 2007, 16:30 GMT
Last edited by Andrew Gregory (andrewgregory) - Thursday, 04 February 2016, 02:53 GMT
Task Type Feature Request
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Andrew Gregory (andrewgregory)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 9
Private No

Details

Adding this so I don't forget.

A pacman.conf option, named something like "RestrictLicense" would be nice in the future.

Cases:
#RestrictLicense commented out / nonexistent - no restriction
RestrictLicense gpl bsd foo - only allow packages with these licenses installed

Other options for usability: (useful or not?)
RestrictLicense * - allow all licenses
RestrictLicense * !bsd - allow all except bsd licenses
This task depends upon

Closed by  Andrew Gregory (andrewgregory)
Thursday, 04 February 2016, 02:53 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Hooks can be used to prevent or warn about installation of packages with unapproved licenses. If anybody has a case not met by hooks, file a reopen request.
Comment by Scott H (stonecrest) - Thursday, 01 March 2007, 17:53 GMT
I'd suggest AllowLicense or something like that instead. To me, "RestrictLicense gpl" would mean that you DON'T want to allow gpl licenses, the opposite of what you intend. (RestrictToLicense would be better, but still confusing.)

This is a good idea though.
Comment by Aaron Griffin (phrakture) - Thursday, 01 March 2007, 18:04 GMT
AllowLicenses sounds better:

AllowLicenses * (all licenses, the default)
AllowLicenses gpl bsd foo bar

One question though... should we be able to "AllowLicenses custom" ?
Comment by Jason Chu (jason) - Thursday, 01 March 2007, 20:30 GMT
I think custom should be a question, "this package has a custom license, are you sure you want to install it?"

Custom is going to be so different that it won't really make sense to blanket it.
Comment by Bjørn Kiær (BLK) - Tuesday, 22 May 2007, 03:41 GMT
Perhaps it could pe possible to mark that certain licences should be asked about. For instance, "AllowLicenses * !cppl ?apache ?custom" would allow all licences, except that cppl would be forbidden, and the user would be queried every time he tried to install something under the Apache or a custom licence.

There should propably be some predefined licence sets, e.g. "AllowLicenses opensource" might allow all OSI-approved licences and ask about any custom ones.
Comment by arnuld (arnuld) - Friday, 29 June 2007, 20:43 GMT
i agree with BLK, there should be some predefined license sets e.g. we can use "Free", "non-Free" and more categories from here: http://www.gnu.org/licenses/license-list.html

i found that GNU arranged licenses in categories much better than anyone else :-)
Comment by Glenn Matthys (RedShift) - Sunday, 19 August 2007, 18:18 GMT
I like BLK's idea of AllowLicenses, like in rc.conf:

AllowLicenses=(* !some_other_license)

Are there any licenses with spaces in them? then maybe we should use AllowLicenses=(* !'QPL protected license'). This seems very complex though.
Comment by Nagy Gabor (combo) - Friday, 29 February 2008, 14:03 GMT
And what to do if a package have multiple licenses, like firefox?
Comment by Ian (zerathidune) - Saturday, 05 July 2008, 07:40 GMT
I find what most people who want this want it for is to block non-free software from their system. currently there is no way to determine based on the license field with 100% certainty if a package is non-free. usually it will have a 'custom' license, but all that actually means is that only one package uses the license. It does not necessarily say anything about the terms of that license. Maybe with package categories (FS#7132) we could have a "nonfree" category, and allow an option to ban or warn about packages from given categories. We might have "gpl-incompatable" as well. An option to restrict based just on licenses would be good too though, as not everyone may be satisfied by the standard categories.
Comment by Glenn Matthys (RedShift) - Saturday, 05 July 2008, 07:46 GMT
What about not caring and have the user check for himself.

One of Arch Linux's strong points (imo) is that it doesn't really care about the licensing, making it very accessible for newbies, especially when it comes to certain media, etc...
Comment by Peter Lewis (petelewis) - Friday, 09 January 2009, 11:28 GMT
I agree that it would be nice for some kind of automated checking / filtering of licences to be done by pacman, to enable the user to set up these kinds of preferences. It certainly won't interfere with anyone who isn't interested in this functionality :-)

And as for "custom" - I like the idea of replacing it with "custom-free" and "custom-nonfree" according to something like the GNU lists as arnuld suggested.
Comment by Kasumi_Ninja (Kasumi_Ninja) - Wednesday, 31 October 2012, 14:43 GMT
I would be great if pacman helped system administrators choose which software licenses they want to install. Is this on the roadmap?
Comment by Kasumi_Ninja (Kasumi_Ninja) - Thursday, 01 November 2012, 14:18 GMT
We could use the same approach as Parabola and use a non-free package package to block all non-free software. I'm in favour of a less strict interpretation of free software than Parabolas has. In my opinion non-free should primarily based on the software license itself. This means that for example Firefox and Thunderbird would be allowed. Users can easily edit the list of allowed software with ABS. You can find Parabol's your-freedom PKGBUILD here: https://projects.parabolagnulinux.org/abslibre.git/tree/libre/your-freedom
Comment by Andrew Gregory (andrewgregory) - Thursday, 04 February 2016, 02:49 GMT
This can be accomplished with a hook.

Loading...