On Jul 9, 2010, at 8:36 AM, Craig James wrote:
> The burden that LGPL puts on developers is really pretty minimal.
If you assume the build system is simple enough then yes, it's
minimal to release the object files and a simple build system.
PMR didn't give enough information to make that judgement. Perhaps
the build information is all inside of the Eclipse/VisualWhatever
IDE and can't easily be made independent.
Perhaps it depends on a distributed build farm. Perhaps they
use a compiler which is only licensed for a single machine so
there's a bunch of rsh/ssh calls in the Makefile to that machine.
Perhaps they do something crazy, like the InChI for Java port
which compiles the C code to MIPS assembly then runs the assembly
in a Java emulator. (Crazy in a 'OMG, that works?! Wow!' sort of
way. ;) Would they ship the MIPS assembly files? Or something else?
Or perhaps it's a small executable which pulls out utility
functions from a dozen in-house libraries, each of which is
250,000+ LOC. Now the burden is to extract just the .o files
which are needed for the executable. (For a real-world example,
the NCBI toolkit for bioinformatics is huge, and not easily
broken down into, say, just the components needed for BLAST.)
(I'll ignore the other option, which is to release all of the
libraries as source.)
There's just not enough information in PMR's sketch to conclude
that in this case there's only a minimal burden.
Still, I imagine any of these could be remedied with a week
or two of development, so it isn't a large burden.
Mind you though, this is just to fulfill the technical
requirements of that clause. It says nothing about the
business model impacts, including the couple I mentioned
earlier (improper access to internal APIS, ease of getting
around the license manager).
Andrew
[email protected]
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Blueobelisk-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
