Re: ATLAS license discussion, please

Clint Whaley wrote, at 9/4/2011 10:25 AM:
> So, if someone sees something wrong with LGPL, I would like them to
> discuss it so that I can understand the problem.  If there are other
> licenses or if there are ramifications I am missing, I would like
> to get all sides before making a final decision.

This is as good a place for me to jump into the conversation as any, I
think.

To introduce where I'm coming from: I lead a team that does runtime
libraries for high-performance embedded computing, and we rely quite
heavily on ATLAS.  We're part of a larger team that does a lot of work
with open-source software, particularly with compilers and debuggers, so
we have a lot of experience using code with different licenses in
commercial work.


The LGPL has some very significant problems for us in this sort of use,
which a license such as Apache or BSD does not.

First is simply the obligation that anyone distributing a library that's
LGPL-licensed must also provide access to the exact source used to build
the library -- and must assure that access to it is available even if
the upstream sources go away.  As it happens, we already do this with
ATLAS, even though it's BSD-licensed; it's just good practice, and it
makes our customers happy.

However, the LGPL would require that we pass this requirement along as
an obligation to our customers. Even though they are not doing anything
with ATLAS other than installing it onto hardware as an internal part of
our products, they must have mechanisms in place to ensure that the
source code is available to their customers for the relevant period of
time, and that it is exactly the source code corresponding to what's
installed.  Doing this to the satisfaction of a large-company legal
department is a quite expensive undertaking, if it's possible at all.


Second, and even more problematic, is the requirement that the end
recipient of a product that uses LGPL-licensed software be able to swap
out that software for another version.  Even aside from the issues of
whether LGPLv3 (in reaction to Tivo's interpretation of v2) requires
that the vendor of an embedded device provide access to reprogram the
hardware -- which of course adds hardware expense, as well as being
quite problematic in an environment such as aerospace or medical imaging
devices with regulatory requirements and high liability -- this is
problematic simply on the software end.

With a dynamic library, the LGPL is relatively easy to address from a
software perspective; you can just replace the installed library file
with another compatible one.  With a static library like the standard
ATLAS builds, however, the LGPL requires that either you provide your
sources or you provide the unlinked object code for anything you
distribute that links to the library, along with the means to re-link it
with a new copy.  Providing the object code is, in most cases, not
really practical -- I am unaware of one single product anywhere that
does this.  So, in practice, for static libraries the LGPL is
essentially equivalent to the GPL as far as the source-code disclosure
requirements it places on the software that links to it.

And, as I mentioned, we're in the business of selling larger libraries
that include ATLAS within them (and, for many platforms, these are
static libraries).  This is not just a requirement for us; it would be a
requirement that we must transfer to our end users.


Beyond those major issues, there are some minor issues -- the LGPL
pretty much precludes distributing the code under a binding NDA, which
is a legal hassle (at least!) in cases where we are doing contract work
for a semiconductor company on unreleased hardware, as we happen to be
doing right now.


Meanwhile, on the other side of the fence, there is this question that
you addressed to Andrew, but I'd also like to comment on:

> Camm used this fact to argue that "good" companies prefer the GPL or LGPL
> because it means that competitors can't just parasitize the common
> development.  He believed I would get *more* commercial contribution
> with the LGPL than with the BSD license, and that companies would feel
> more comfortable helping.  What do you think of this argument?

Personally, I think this argument is exactly backwards.  As you noted
with Apple and GCC, the GPL does not prevent parasitizing the common
development for proprietary gain -- Apple simply branched the code and
did not contribute things upstream, and so even though they provided
source, it was of little use to anyone.  Likewise, there are several
companies that simply rebuild the GCC sources from our products without
doing any compiler development of their own, and sell them in direct
competition to us.

To a first approximation, we've found that the effort of meaningfully
contributing code upstream beyond than just doing our own source dumps
(sufficient to satisfy the minimum requirements of the GPL) is of the
same order of magnitude as developing the code in the first place.
That's a significant barrier, and you won't get people to cross it by
license requirements, whether you choose LGPL or BSD.

The reason companies do upstream submission is that it's directly
valuable to them to do so.  Once the code is upstream, we no longer need
to pay the ongoing costs of updating it to adapt to other upstream
changes, and other people will contribute to keeping it from
bit-rotting.  New and improved upstream versions will contain the
changes that we need for our internal use, and so it's cheap to upgrade.
 Likewise, we get benefits from ensuring a healthy upstream community
that will improve the software.

(Apple's use of GCC is a good example here, too, of the costs of not
sending changes upstream.  They basically got stuck at a rather old
version because they'd diverged so far that it wasn't feasible to merge
in upstream changes any more.)

The thing is, though, that this is valuable only insofar as the end
product is something that the company can freely use -- and a license
like the LGPL that adds more obligations limits that usability, and thus
limits the incentives for companies to participate.


So, with all that said, I would very strongly encourage you to choose
the Apache license (or remaining with the BSD license) over the LGPL.
The LGPL has some very serious problems for statically-linked libraries,
for inclusion in components of larger systems, and for things that go
into embedded end products.  To put it bluntly, ATLAS is a project that
we've used for years and we want to contribute to because it is
something we can give to our end users without restrictions, and that's
possible because of its BSD-like license.

Thanks,
- Brooks


--
Brooks Moses
CodeSourcery / Mentor Graphics
brooks@...

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel