[Liblas-devel] Open source lidar software?

Howard Butler hobu.inc at gmail.com
Fri Apr 8 10:00:29 EDT 2011


On Apr 8, 2011, at 5:38 AM, Martin Isenburg wrote:

> On Thu, Apr 7, 2011 at 8:05 AM, Michael P. Gerlek <mpg at flaxen.com> wrote:
> Martin-
> 
> I don’t understand why you put some of those applications under LGPL -- the LGPL typically only makes sense for *libraries* that are designed to be linked against…?   (Or are you concerned about 3rd party applications that could invoke your applications as a separate process?)
> 
> Michael ,
> 
> I don’t understand it either ... probably due to my aforementioned own incompetence on those things. (-: Howard suggested LGPL for LASzip so- blue-eyed as I am - I figured it must be a decent license to use.
> 
> Which license would you suggest? Or maybe someone else has an informed opinion about which license they would like me to put the "open source" part of LAStools under?

In my opinion, the LGPL is a perfectly fine license to use, even for LAStools.  The reason why I suggested LGPL for LASzip was a very specific one (see below), and keeping all of LAStools LGPL will simplify Martin's ability to swap code between the LAStools and LASzip codebases without having to maintain two separate projects like we have to for libLAS - LASzip.  In my opinion, it is fine to leave the license of LAStools alone.

Michael's discomfort with the LGPL is probably related to the fact that the BSD license isn't compatible with the LGPL license as far as code sharing at the developer level is concerned.  A developer in a LGPL project can copy code and cite it from a BSD project, but a developer in a BSD project cannot do the same with the LGPL code without making their codebase *also* be LGPL. A closed, commercial software developer has the same problem as the BSD developer has as well.

The reason why I suggested LGPL for LASzip, and am quite happy that Martin chose to release it as such, is that LASzip the library is *both* a format and a software right now.  The software is the specification of the compression/decompression and its storage on disk, and if it were more liberally licensed (such as MIT or BSD), a nefarious or bumbling market player could start using the very same source code to write "LAZ" files that are different than the public version we have been purveying.  While there's nothing to prevent someone from using the existing LASzip codebase to do that now, the LGPL requires them to *release the source* of those bumbling changes so we can choose to use them or drop them on the floor as we wish. This key feature of the LGPL is why I suggested it for LASzip.

> Please reply only to me and not the entire list.

I have replied to the list to explain the rationale of suggesting LASzip's license be LGPL.

Howard


More information about the Liblas-devel mailing list