On Thu, 2008-05-08 at 18:00 -0400, Mark Phippard wrote:
> I do not really want to bog down in semantics as this is likely a
> smallish change (for the one or two people that understand the Windows
> build system).
Uh, sure, but from a time allocation perspective, "we have to do this or
we're violating Neon's license" is very different from "it would be nice
if we did this." I don't think we're violating the LGPL.
> Now I think you can still statically link provided you make available
> the source code or the compiled object code so that the user can do
> this. I was under the impression it needs to be in the same
> distribution, which in our case is not true.
Nope. The source code can be available alongside the binary download.
The LGPL is written in fairly plain English. It only takes a few
minutes to review
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
and see what is required.
> >> They cannot support LGPL because their license allows the package to
> >> be relicensed commercially and LGPL does not permit that.
> >
> > That's also false, although the LGPL certainly applies some constraints.
>
> Is it worth taking up with the foundation's lawyers? Are you aware of
> any precedent or docs we could point them to?
It's generally not worth talking with lawyers about stuff, so no. I
can't really provide any references since you haven't defined
"relicensed commercially." The LGPL is specifically designed to allow a
work to be used in combination with proprietary software, as long as you
provide the necessary machinery to empower a user to modify the LGPL
portions of the work within any binaries you distribute. That might be
distasteful to a commercial software provider but it's certainly a far
cry from "the LGPL does not permit that."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-09 00:15:46 CEST