James Carlson schrieb: >> I think use of the GPL for libraries is a special case here, as would be >> use of any similarly 'viral' license, which places requirements on > > I never mentioned any "viral" problems, and that's not the problem I > have with this case. > > The problem I have is that a couple of random components -- ones that > are in Solaris today -- were removed from this project because the > upgraded license is now considered to be unacceptable. >
If the issue is GPLv2 vs. GPLv3, then I misread the problem and agree to your assessment. > In effect, we're using legalese to determine system architecture, and > I think that's a problem. Perhaps there's a reason why lopping off > these particular limbs won't hurt anyone, That should in any case be reviewed on its own merits. > but as a general principle, > we're headed for trouble if we determine system architecture on the > basis of what passes the lawyers. > My argument was that GPLness of the license for a component does have an architectural impact, as it excludes some potential users of an interface. And upgrading a piece of software with stable interfaces may be architecturally invalid, if it comes with a license change, for example from LGPL to GPL. If the prior version of those libraries was GPLv2, then my argument does not concern this case. Sorry, I noticed this potential ambiguity only after submitting the post, when it was too late to do more research. > A better solution is to decouple these things: do the architectural > review on the *whole* case, ignoring the legal questions, and then > allow the project team to go off and do the legal review as a > dependency for shipping. > As I said, GPLness (or 'viral'ness) IMHO does have an architectural aspect, which goes beyond legal organizational policies. > We have a high level directive from Tim Marsland saying that > everything must be "familiar," which (as far as I understand it) means > "the same as on some currently popular distribution Linux; probably > Ubuntu." > What various Linux distros ship - and what they ship as part of the default install vs. through opt-in repositories varies depending on conceptual, legal or political differences. I think that is an area where OpenSolaris can (and must) define its own policies. > By hacking away components from what we deliver -- particularly doing > so on the basis of a fear of GPLv3 -- we're failing to comply with > that directive. > Well, I'm not sure we need an openssl shim for one piece of crypto, if we have the real openssl available. Similar arguments may apply to some of the other pieces left out in this case. I agree that issues with the license should not preempt architectural consideration. OTOH project teams that don't want to fight certain legal battles (or lose them) may still be forced to submit something that was shaped by legal considerations. In the present case this may mean staying with an outdated version of the entire package or switching to an up to date subset. Which of those will comply better with the directive you mention? - J?rg -- Joerg Barfurth Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
