You are not logged in.

#1 2016-12-10 21:55:03

CrocoDuck
Member
Registered: 2015-10-25
Posts: 9
Website

Packaging software with different licensed components

Hi cool people!

I am in the process of preparing a PKGBUILD for this software. It is a collection of audio plugins. I have a full working PKGBUILD that I would like to be high quality. My problem is that not all the plugins that are included in this repo have the same license. Most are LGPL or GPL, few others are MIT or ISC (see here). I was thinking about few possible solutions:

1) Include all the licenses in the array

license=('GPL' 'LGPL' 'MIT' 'custom:ISC')

Include the custom licenses as sources:

source=("${pkgname%-*}::git://github.com/DISTRHO/DPF-Plugins"
        "LICENSE_KARS_ISC" 
        "LICENSE_NDC_MIT")

Manually install the custom licenses under the required directories:

package() {
    # Install the custom licenses:
    install -Dm 644 "LICENSE_NDC_MIT" "$pkgdir/usr/share/licenses/$pkgname/AmplitudeImposer/LICENSE"
    install -Dm 644 "LICENSE_NDC_MIT" "$pkgdir/usr/share/licenses/$pkgname/CycleShifter/LICENSE"
    install -Dm 644 "LICENSE_NDC_MIT" "$pkgdir/usr/share/licenses/$pkgname/SoulForce/LICENSE"
    install -Dm 644 "LICENSE_KARS_ISC" "$pkgdir/usr/share/licenses/$pkgname/Kars/LICENSE"
   ...
}

However, the wiki seems to suggest that this is not a very good idea:

Some packages may not be covered by a single license. In these cases multiple entries may be made in the license array e.g. license=("GPL" "custom:some commercial license"). For the majority of packages these licenses apply in different cases, as opposed to applying at the same time. When pacman gets the ability to filter on licenses (so you can say, "I only want GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using OR, rather than AND logic, thus pacman will consider the above example as GPL licensed software, regardless of the other licenses listed.

2) Just use 'unknown' as license and let the user find out for himself browsing github.

3) Split the package in many sub-packages. Probably the best solution, but I would like to avoid it if possible as the PKGBUILD for the entire plugin pack would be much more concise and elegant (and easy for me to maintain).

So, my question is: is there a standard way to handle software with many components having different licenses? If not, which one of the above methods would be the best? Do you have any other idea to solve the problem?


Check my Linux audio experiments on my SoundCloud.
Fancying a swim in the pond?

Offline

#2 2016-12-11 14:20:43

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Packaging software with different licensed components

Looking at things I'd say you've walked into a licensing minefield created by the author of that package.

I see only one license in that code : dpf/LICENSE

The global readme doesn't mention any license at all,neither do any other folders then dpf/ .

Without licensing files we have no way to determine if the DISTRHO/DPF author is allowed to distribute that code.
If some of the plugins are indeed GPL or LGPL they are violating the license by not including it.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#3 2016-12-11 14:40:23

CrocoDuck
Member
Registered: 2015-10-25
Posts: 9
Website

Re: Packaging software with different licensed components

Thank you Lone_Wolf. Indeed, the situation is kinda messy.

I can see the license for each plugin included in DISTRHO/DPF-Plugins by looking at their specific repo. For example, ProM is included in DISTRHO/DPF-Plugins and it has a LGPL license. These, which are included as well, are MIT instead. When dealing which single plugins repos we actually have a LICENSE file for each. This is making me thinking that strategy 3 would be the most appropriate, although perhaps strategy 2 is not actually violating Arch packaging standards too much (right?): the situation is ambiguous for real.

I guess I will start working on strategy 3.


Check my Linux audio experiments on my SoundCloud.
Fancying a swim in the pond?

Offline

#4 2016-12-11 15:12:10

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Packaging software with different licensed components

Good, that suggests the missing licenses are an oversight and unintentional.

If the author is willing to correct the issues[1] i'd say putting ISC and unknown in the license array is acceptable for the time being .

[1]
adding some notes to the global readme / or a new global licensefile claryfing which code falls under which license, along with adding the individual licensefiles should be enough.

The mesa license shows an example of how this can be done.

Last edited by Lone_Wolf (2016-12-11 15:12:35)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#5 2016-12-11 16:05:36

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Packaging software with different licensed components

I have to disagree with some of the above.  Number 3 does indeed sound best.  Number 1 is a bit ugly and has some downsides, but all the licenses are provided which is the most important part.  Number 2 sounds lilke a bad idea to me, and while I don't know for sure, I hope it would be unacceptable.  A license of "unknown" means it is not known whether it is even legal for AUR users to download and use the code at all.  IMHO, any package with license "unknown" should be removed from the AUR.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#6 2016-12-11 16:39:37

CrocoDuck
Member
Registered: 2015-10-25
Posts: 9
Website

Re: Packaging software with different licensed components

I see. I opened an issue on GitHub. If the author is able to provide a "mesa style" license file I should be good to go. If not, I will perhaps go with solution 3.


Check my Linux audio experiments on my SoundCloud.
Fancying a swim in the pond?

Offline

Board footer

Powered by FluxBB