James Carlson wrote at 01/16/08 13:46: > David.Comay at Sun.COM writes: >>> 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. > > Something's going awry here, as a "closed approved automatic" case > should not be the place for Sun's legal group to set new architectural > policy for the system. > > I know of no practical reason to segregate GNU bits into a special > ghetto. Just about all of GNOME is under GPLv2 or LGPL, and we > intentionally don't do any separation with those, and I don't see why > Quagga is being subjected to a different set of rules. > > Nor, frankly, do I see what establishing such a ghetto would > accomplish. If you need one, /usr/sfw is already a mess like that. > >> 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? > > No. I want to see them in /usr/lib, or a clear explanation of why > they can't be there. As best I can tell, they belong there just as > much as any of the GNOME bits. > > The reason I think it's important is that Quagga offers interfaces for > new protocols to be built on top. Hiding these libraries in a > non-standard location just makes us different from other platforms for > no reason, and sets us up for the same kind of mess that /usr/sfw > created. > > We've been trying to do away with that problem.
Personally I also think that having a separate directory for each viral license is a something that we as a whole entity should try to avoid and get rid of, well, somehow. Having said that though one of the things that I constantly hear about on this subject matter from Sun Legal is that: have a separate, isolated directory and put the binary with the corresponding license file in that directory (and during legal review that is signed by your director and VP, you find there are always other additional things to do based on what you have to deliver and whom you talk to). We also have OpenSource/Freeware Advice (Authority SAC) and Legal rules for inclusion of OpenSource/Freeware (Authority Legal) that might need some update. And for these conflicting requirements and precedents, what project teams should do? It appears we need to have a single, ironed out guideline (or whatever you call it) with joint authorities between SAC and Legal on this matter. Ienup
