>> The quagga binaries already reside under /usr/sbin, as >> described in PSARC/2005/571. The quagga libraries--libzebra, >> libospf, and libospfapiclient--are currently in /usr/sfw/lib >> and will be moved to /usr/gnu/lib. Because of restrictions of >> the GNU Public License (GPL), under which quagga is licensed, >> these libraries cannot reside under the default /usr/lib >> location. > > I don't agree. Dealing with licensing issues (real or imagined) is > not what /usr/gnu was defined to do by PSARC 2007/047. > > Instead, it's *only* for naming conflicts -- cases where there's a GNU > variant of some utility (e.g., tar) where a user would want to have an > un-prefixed alternative by setting his path. > > Furthermore, we have GPL all over the system, not just here, and a lot > of it is in /usr/lib. What could make this one project special?
It's my understanding that those GPL components under /usr/lib should not be there per the most recent guidelines from Sun legal. So it was my recommendation to the team to explore the alternative of /usr/gnu/lib as Quagga is one of the GNU components in the FSF/UNESCO Free Software Directory. Upon rereading PSARC 2007/047 though, you're correct that it's focused on the naming conflict instead of other sorts of conflicts. Assuming these libraries are Project Private (note that the opinion for the Quagga case, PSARC 2005/57, is missing so I'm not sure of the stability level here), would a reasonable solution here be to instead deliver those components under /usr/lib/quagga? Private? dsc
