Hi folks! I hate bogging down into this too; Mike Milinkovich asked me a
few questions so I promised him I'd follow up, and it did seem to point
out a couple of issues.
On Thu, 8 May 2008, Mark Phippard wrote:
> On Thu, May 8, 2008 at 5:47 PM, Greg Hudson <ghudson_at_mit.edu> wrote:
>> On Thu, 2008-05-08 at 17:27 -0400, Mark Phippard wrote:
>>> In the process of going through this with Brian he looked at our
>>> Windows download and said "I do not see Neon in this". I pointed out
>>> that this is because we have always statically linked Neon on Windows.
>>> Brian pointed out that we cannot do this, it violates the terms of
>>> the LGPL.
>>
>> Which term does it violate? Looking over the LGPL, I think we're fine
>> since we're providing source code for all of Subversion. A
>> closed-source derivative of Subversion might be in a different
>> situation.
>
> 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). That said I think what Brian said was that the user
> has the to have the right and ability to replace the library with a
> different version and if we statically link we take away that right.
> 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.
First, realize that, to a layperson, svn-win32-1.4.6_dev.zip and
svn-win32-1.4.6_javahl.zip currently and apparently inadvertantly are
"closed-source derivatives of Subversion". The first clear big issue with
svn-win32-1.4.6_dev.zip is that it doesn't include any copyright notice at
the top level. The README doesn't discuss copyright issues, nor does
anything under doc/ (it appears). There are copyrights in the header
files included, but it's not clear that those cover other packages. But
worst of all, there's no copyright information around lib/neon/libneon.lib
or lib/neon/zlibstat.lib indicating that Neon is LGPL, and where to get
the source code (and incidentially how to replace it with one compiled by
end-users).
http://www.opensource.org/licenses/lgpl-2.1.php
Section 6 of the LGPL is what leads me to thinking that LGPL-licensed
components in these binary builds must be done as dynamically linked
libraries separate from the compiled SVN code. I suppose one could argue
that 6c is satisfied by telling people "you can build it yourself from the
source code to everything else, and here's how", but those instructions
aren't included in the Windows .zip file; so better docs might suffice.
But it seems more in the spirit of the LGPL license (and not any harder)
to compile them as dlls/libs.
Now it *does* appear that svn-win32-1.4.6_dev.zip has neon as a separate
library, lib/neon/libneon.lib. But it's not separate in
svn-win32-1.4.6_javahl.zip. Libintl for win32 is separately distributed,
the safest thing to do, but it looks like subclipse's zipfile has
intl3_svn.dll included, similarly without any documentation or licensing
info. The JavaHL Win32 zipfile also appears to include SVNKit, but no
licensing information is provided for it.
I hate license pedantary as much as anyone; and I am looking forward to
serf getting to the point where we can drop neon as a dependency.
>>> 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?
I imagine the folks at the Eclipse Foundation are well informed on
licensing issues, having several people full time focused on this; but I
imagine they have the same kind of perspective as the Apache Software
Foundation has and other projects (pretty reasonably) do, which is that
software they take responsibility for should be consistantly licensed.
They're also avoidant of non-Java code - ironic, since their UI framework
went against the Java orthodoxy and required platform-specific code just
like using JavaHL does. But still reasonable when you think about
simplicity and stewardship. I don't think Subclipse and Subversion would
ever be Eclipse Foundation projects, but I still would love to see
Subversion support somehow included by default (or a single button-click
away after install, for all platforms). Eliminating the LGPL dependencies
would get us there all the way, I think; properly following LGPL
requirements and aiming to eventually eliminate them gives us a reasonable
starting point.
Brian
---------------------------------------------------------------------
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 01:31:21 CEST