On Jul 9, 2010, at 9:51 AM, Geoffrey Hutchison wrote:
> I think we're *way* off topic here. Suffice to say that Peter shared some
> details about the identity of COMP for his particular situation, and I can
> say that they already distribute stripped object files to users.
Grrr. It's awfully hard to work with hypotheticals which mask a
real-world case since it feels like essential information is
missing. I have a more concrete form below, which fit into PMR's
original hypo, but which doesn't fit this extra data point.
Do you mean to say that everything they ship is in object form,
or that they ship their libraries, plus applications which use
those libraries, where part of those applications are not available
as a library? Since it's only the former which gets around
this clause.
In any case, here's my more detailed hypo.
On Jul 7, 2010, at 8:16 AM, Peter Murray-Rust wrote:
> Take hypothetically that I have written a piece of code PMRCODE which is
> contributed
> to a large project BASE which uses the LGPL licence, the whole of which can
> be used
> as a library LIB. As a result I decide to use the same licence (LGPL) for
> PMRBASE.
I offer an example which is a bit less hypothetical, in the hopes that it
may bring some things into focus.
I have (this is made up) developed a voice entry system for structure
editing called "VoxChem". It depends on (this is made up) a proprietary
library from AT&T for speech recognition. The license I agreed to said
that I can not provide programmatic access to the AT&T library. This clause
exists to keep people from developing and selling Python/Perl/Java/etc.
wrappers to the AT&T library.
(Assume that there is no comparable free tool, and that dropping VoxChem
development to improve a free voice recognition package does not interest me.)
I have packaged VoxChem as a single binary. This means people can just
download it and run it, without having to worry about setup. I did this
by statically linking everything into the program. My customers rave
about how easy it is to use VoxChem because it always just works.
Now I want to add InChI export to my program. InChI is distributed under
the LGPL. This now means I have to ship a version of VoxChem in object form,
which can be relinked with altered/improved versions of InChI to produce a
new version of VoxChem.
(I chose InChI because it uses the LGPL. If CML was released under
the LGPL then it would be an equally applicable example.)
Because of the LGPL clauses, I need to make this available on the same
location as the actual VoxChem, which may lead to customer confusion over
which version to download. Because I always release good quality software,
with documentation (ha!), I have to good include build instructions, with
proper testing.
These take time - perhaps a week - but InChI support is worth it. And
let's say that it was trivial to make the .o release proper.
However, because I'm releasing the .o files with the requirement that
my customers can relink and rebuild the program, what do I do with the
dependency on the AT&T library? If I include that library as part of the
distribution then I've broken their license agreement either directly
(because I'm redistributing their library) or indirectly (because others
now have direct access to the API calls). Without that library, I no
longer have a product.
I could have InChI and InChI only be part loaded as a shared library,
but then there goes my ease of use, and my support calls and overhead
increase.
For this case, should the InChI Consortium grant a single additional
permission, which is a waiver to the clause dealing with statically
linked libraries?
(Please note how I constructed this phrase. The GPLv3 describes
the core set of freedoms, and others can give additional permissions.
The LGPLv3 is a set of additional permissions on top of the GPLv3.
All that's needed here is a single additional permission on top of
the LGPLv3.)
> I am not so sure I should change my licence because it is a better
> business model for a downstream commercial
I give this example to highlight that it can be more than free software
vs. business model.
How important is software freedom over wider use of a common chemical
identifier system? Is this point important enough that the InChI
Consortium should keep this (IMO) minor point of the license? Especially
since most people don't even know that it's a requirement?
(You could still say it's part of the business model, but the VoxChem
model is much more dependent on proprietary software than free software,
and would certainly survive without it.)
As well, how important is software freedom vs. the bit of ego boost
I know I get when I find out that other people are using my code?
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
