On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote: > OK, I know this is going to be painful, but we need to solve this (FESCo > is waiting for us to do it), and I think this is the cleanest way: > > Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > and http://fedoraproject.org/wiki/Licensing . > > We'll vote on it next week. > I think that's missing a scenario. Covered: You can have License A or License B (Dual license) You can have License A on /usr/bin/foo and License B on /usr/bin/bar (Multiple Licensing) Not Covered: You can have License A on foo.c and License B on bar.c being linked together to form /usr/bin/foobar (A different kind of multiple licensing) With GPLv2 as one of the licenses, this shouldn't be an issue because the GPLv2 states that you can't have additional restrictions so for our purposes[1]_, saying the package is GPL is fine. But there could be code under two licenses in which this does matter, for instance BSD with advert clause and a second license which specifies that modifications must be shipped as patches on top of upstream. [1]_: Provided that "our purposes" is internal package audit and not information for developers. Someone outside Fedora looking for code to include in their project could be interested in knowing that 90% of /usr/bin/foo is public domain and only one GPL source file makes the whole thing GPL. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
