GnuTLS Update [LSARC/2008/341 FastTrack timeout 06/03/2008]

[Joerg Barfurth]

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/