David.Comay at Sun.COM writes:
> This isn't a new architectural policy per-se but a restatement of the
> existing policy that we've been working under. Or at least that I've
> been working under. :-) And I realize that this policy hasn't been
> articulated outside of Sun which is something we've been working to
> change as part of a revised set of GPL/LGPL architectural guidelines
> that we want to make available soon. I'd love for us to be able to
> liberalize the policy in the namespace area as part of that effort.
It actually hasn't been articulated too well _inside_ Sun either.
> > 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.
>
> Note that as far as I know, there isn't as much of a concern about LGPL
> components for obvious reasons.
Sure ... but there are random GPL things there as well, such as
libgtop.
> > Nor, frankly, do I see what establishing such a ghetto would
> > accomplish. If you need one, /usr/sfw is already a mess like that.
>
> Believe me, I don't want to segregate these bits either - remember, I'm
> on this kick to make things familiar. But as with readline case, there
> was/is the concern about delivering viral libraries under /usr/lib. Or
> do you see a difference between this case and the one for readline?
We parked that case pending the outcome of a legal opinion. Either
that opinion never arrived, or the submitter lost interest.
My last message on that topic was:
As the licensing issues are much more complex than just a single
"which one" question, I think this suggestion (if serious) provides a
substantial risk of providing a false sense of security to users.
Those who set the flags right and are told that nothing is wrong will
_assume_ that they are in fact in the clear. Given that we can't
actually guarantee that, and that doing so would be tantamount to
providing free legal advice by way of our system utilities and linking
infrastructure, I don't think it's a good idea.
In other words, providing a special ghetto for storage of GPLv2
components that (presumably) can "infect" things that get too close --
somehow a directory structure is expected to be enough to prevent
infection -- implies two things:
- Sun is implicitly saying that it has evaluated all the
licensing issues, and the things in this special directory
are subject to GPLv2.
- Sun is also saying that it has evaluated everything else,
and none of it is subject to GPLv2.
Both of these are essentially providing customers with legal advice
(something we should just _never_ attempt to do), and both are
potentially quite wrong. We have no good way of auditing these
statements or proving that there are no mistakes on this boundary.
How do we know that the stuff we're putting there is _only_ under
GPLv2 and that no other restrictions apply? How do we know that the
person purporting to be the original author really has the right to
convey that license to us? How do we know that nothing else in the
system has a similar license?
How do we know that library linkage is special, so /usr/lib must be
guarded, but that invocation from within a script isn't, so /usr/bin
is wide open?
I don't think we can answer these things. In fact, I'm arguing that
we should not answer them.
> > 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.
>
> So these libraries do deliver public interfaces and the creation of new
> protocols can be done outside of the Quagga project?
Yes. I don't know what the stability of libospfapiclient.so might be,
but it's certainly a programming interface.
> > We've been trying to do away with that problem.
>
> Again, you won't get any pushback from me on this in the general case.
> If /usr/lib is where everyone else delivers the libraries, then that's
> what I'd like to see at some point. But from a practical point of
> view, I do see a difference between a library exporting public
> interfaces and those which implement project implementation details.
I'd like to see the legal beagles who are pushing for a new system
architecture to come out of the shadows and propose something concrete
that we can use. I don't want to see us designing the system based on
second- or third-hand filtered advice. We need solid rules.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
