The license is the modified BSD, not original BSD.
See the COPYING file in the latest version. The
prior to 3.1 may have been fuzzy, but it has never been
the original BSD license. Using LAPACK has never
required an advertisement, although we'd really
appreciate a citation.
The license is now given explicitly in the COPYING
and it is essentially the BSD
license without the advertising clause.
Depot, encap, etc.
There's a long history here. The most up-to-date
system that merges the package directory and Unix
schemes is <a
Others include old <a
Depot and <a
Stow. NeXT placed apps in their own
directories, and I imagine MacOS X does, too.
The main problem is that packages aren't always
cleanly divisible, leading to Solaris-like packages.
(Solaris is just one example.) And now you start
getting nasty inter-package dependencies. So then
you start heading towards being over-specific and
inflexible, or towards <a
removing a module from a current environment is
difficult. Also, analyzing your needs sufficiently well
to use modules at all just takes too much time.
In short, there's a lot of previous work, and no
satisfactory answer for all cases.
Part of the problem
lies with how programs look for their data. Some,
like gcc and just about everything, get horribly
confused when compiled-in paths fail. Others, like
teTeX (http://www.tug.org/tetex/) and
other web2c-based TeXs, do a great job in 99% of
the cases. But they cheat by being all-in-one
systems. Mixing, say, a newer version of Context
with teTeX without fully replacing the old one can
lead to insanity. This is true even though all the
packages are nicely placed into their own
subdirectories (modulo some config files).
It's a hard problem. Everyone has different needs.
Using encap / epkg with semi-large, unremovable
modules seems a fair compromise. You might want
to look into those.