Some ebuilds use "|" within LICENSE= to mean OR and some to mean AND. This begs the question as to whether multiple licenses without a "|" always means AND as well. Examples qt-3.2.2-r1.ebuild:LICENSE="QPL-1.0 | GPL-2" (QPL-1.0 OR GPL-2) colorschemes-20031113.ebuild:LICENSE="vim | GPL-2 | public-domain" (vim AND GPL-2 AND public-domain) It seems there is presently no rule for which is correct, although I'd take the former to be more intuitive (to a programmer!) and no "|" to mean AND.
Created attachment 21110 [details] All packages which contain "|" in LICENSE= When these are checked, I suggest adding a tag to the LICENSE= line such as #CONFIRMED as a means for later checking.
Created attachment 21111 [details] Packages with multiple licenses with no "|" As above
The "|" means OR. If the mailing list archives were up I'd link to the original LICENSE= propsal from 4/25/02 with the subject of "Licenses, Ebuilds, and you". Eg: LICENSE="GPL-2 | (FOO BAR)" Means that this package licensed under the GPL version 2 OR both FOO and BAR. The user may accept GPL-2 and not either of FOO or BAR. Alternativly the user can accept FOO and BAR but not the GPL-2. In the case of the colorschemes example, it's clear that the "|" is being used to mean OR.
Interesting that the maintainer of the colorschemes ebuild said that all three licenses were applicable and all had to be agreed to as each license applied to different parts of what was installed, no? I asked first on the -dev mailing list and nobody that answered was completely sure or admitted that either they didn't know or thought different. Also, the ebuild howto makes no mention of how to specifiy multiple licenses. Maybe the packages I've listed in the AND attachment are all correct, but I'd be surprised if there aren't more incorrect ones other than colorschemes listed in the OR attachment.
This bug is valid. It arises from a discussion on -dev where it was discovered that different authors have been using different standards for AND/OR in the LICENSE string. Three things need to happen as part of this bug: 1. Documentation needs to be fixed. Swift is working on this. 2. Skel.ebuild needs to include some information regarding multiple licenses. I can handle this part. 3. The ebuilds listed need to be checked to make sure they are using the syntax correctly. For this part, I would suggest, that the bug be passed around to the team for each affected herd. Each herd can then do appropriate checking, remove their ebuilds from the list, and assign to the next herd in the list. Does this sound reasonable? SandyMac, I realize (now) that the standard for this was once discussed on -dev but it was never transcribed into documentation. Now that we're (hopefully) implementing ACCEPT_LICENSES as an integral part of portage, it's important to make sure that we have the multiple license situations right. Regarding colorschemes, Jason is correct and Sandy is wrong. It mistakenly uses "|" when the user needs to agree to all the licenses.
btw, currently parantheses are NOT supported, repoman will complain on them. Do we need them or is it sufficient to say AND binds stronger than OR ?
In bug 17367, I was told that OR is stronger than AND: "foo bar | license" = "foo (bar | license)" != "(foo bar) | license" Brackets may not be necessary at the moment but it's probably better to put them in just so that the meaning of the above is completely clear at a glance. New devs would be less likely to make mistakes, as well. How hard would modifications to repoman be? Most of the code for parsing these strings couple be taken from the DEPEND code... Though, even if brackets are implemented, the question of which of AND and OR takes precedence still remains. Can I get some confirmation, please?
Slightly unrelated, but I found a another issue with this. Some packages are combined from multiple sources which require different licenses depending on USE flags. Most notably is x11-base/xfree. It has LICENSE="X11 MSttfEULA" yet only needs the MSttfEULA if the "truetype" USE flag is set. This will require either LICENSE= being similar to DEPEND= or constructs such as: LICENSE="X11" if use truetype LICENSE="${LICENSE} truetype" fi (that's if the "use" function is actually available at that location)
Jason... ^^^ ?
DEPEND-type syntax has been approved and repoman now enforces it.
