You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Ralph Goers <ra...@dslextreme.com> on 2009/08/25 17:10:44 UTC
SVNKit
I wrote an Apache Commons VFS "Provider" for SVNKit. SVNKit's license
is at best as viral as the GPL. As such, I have not added the provider
to VFS (or made it open source at all for that matter). However, the
discussion regarding APR leads me to believe that including the
provider in VFS would be OK because:
a) it is optional - SVNKit would be listed as an optional dependency
in the pom.xml and VFS would not include support for the provider
unless the SVNKit jar is present.
b) SVNKit would not be distributed by the ASF. The user would have to
specifically add the dependency to their pom.xml to build their
application or add it to the appropriate classpath directory.
SVNKit's license is at http://svnkit.com/license.html
Thoughts?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SVNKit
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 31, 2009, at 7:50 PM, Justin Erenkrantz wrote:
> On Tue, Aug 25, 2009 at 8:10 AM, Ralph Goers<ralph.goers@dslextreme.com
> > wrote:
>> I wrote an Apache Commons VFS "Provider" for SVNKit. SVNKit's
>> license is at
>
> If you code against JavaHL instead of SVNKit, then you wouldn't have
> any licensing issues. SVNKit has a mode where it is API-compatible
> with JavaHL. JavaHL is the officially supported Java bindings for
> Subversion (hence under ALv2); SVNKit is wholly unsupported
> and...well...don't get me started on SVNKit...
>
> For more, see:
>
> http://svn.collab.net/repos/svn/trunk/subversion/bindings/javahl/
> http://subclipse.tigris.org/wiki/JavaHL
Thanks, but I looked at that before I started. JavaHL basically gives
you the same functionality you get from the command line - checking
out files to a local file system, etc. Commons VFS wants Subversion to
be the filesystem. SVNKit provides an API to work directly with the
repository, which is exactly what was needed.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SVNKit
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Aug 25, 2009 at 8:10 AM, Ralph Goers<ra...@dslextreme.com> wrote:
> I wrote an Apache Commons VFS "Provider" for SVNKit. SVNKit's license is at
If you code against JavaHL instead of SVNKit, then you wouldn't have
any licensing issues. SVNKit has a mode where it is API-compatible
with JavaHL. JavaHL is the officially supported Java bindings for
Subversion (hence under ALv2); SVNKit is wholly unsupported
and...well...don't get me started on SVNKit...
For more, see:
http://svn.collab.net/repos/svn/trunk/subversion/bindings/javahl/
http://subclipse.tigris.org/wiki/JavaHL
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SVNKit
Posted by Brett Porter <br...@apache.org>.
On 26/08/2009, at 6:49 AM, Ralph Goers wrote:
>>
>> Exactly. The user would have to install svnkit (reviewing its
>> license
>> terms) in order to use the provider. The combination is subject to
>> the
>> svnkit license (as well as the AL, obviously). The source code and
>> the
>> binaries distributed by the ASF must not be under this license.
>>
>> (Except perhaps for an svnkit optional binary package, see my earlier
>> comments).
>>
>
> While I agree with all your comments it isn't clear to me whether
> you think this would be acceptable.
>
> Obviously, any code I would write for this that would reside in
> Commons VFS would be under the Apache license. Unlike the GPL, the
> SVNKit license doesn't say that all the code that uses the library
> has to be under the same license, so applications are free to use
> whatever license they choose. So it is perfectly acceptable for the
> code that uses SVNKit to be use the Apache license. Their
> restrictions only come into play upon redistribution, which we would
> never do. Furthermore, I would imagine that the NOTICE file would
> want to provide some warning about the consequences of downstream
> users taking advantage of the feature.
>
> LEGAL-45 was actually created for a similar use case but was never
> answered. Brett marked it wontfix since he apparently decided to do
> the work outside the JSF.
No, the author decided to do that so I just closed the issue. I had
only offered to get an answer (you can see more details in the
thread). I still agree with your interpretation.
> I don't have karma to reopen it, but I've added a comment to it
> regarding this. If someone could reopen it I'd appreciate it.
I've reopened it for you to pursue further.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SVNKit
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 25, 2009, at 10:08 AM, William A. Rowe, Jr. wrote:
> Ralph Goers wrote:
>> I wrote an Apache Commons VFS "Provider" for SVNKit. SVNKit's
>> license is
>> at best as viral as the GPL. As such, I have not added the provider
>> to
>> VFS (or made it open source at all for that matter). However, the
>> discussion regarding APR leads me to believe that including the
>> provider
>> in VFS would be OK because:
>> a) it is optional - SVNKit would be listed as an optional
>> dependency in
>> the pom.xml and VFS would not include support for the provider unless
>> the SVNKit jar is present.
>> b) SVNKit would not be distributed by the ASF. The user would have to
>> specifically add the dependency to their pom.xml to build their
>> application or add it to the appropriate classpath directory.
>>
>> SVNKit's license is at http://svnkit.com/license.html
>>
>> Thoughts?
>
> Exactly. The user would have to install svnkit (reviewing its license
> terms) in order to use the provider. The combination is subject to
> the
> svnkit license (as well as the AL, obviously). The source code and
> the
> binaries distributed by the ASF must not be under this license.
>
> (Except perhaps for an svnkit optional binary package, see my earlier
> comments).
>
While I agree with all your comments it isn't clear to me whether you
think this would be acceptable.
Obviously, any code I would write for this that would reside in
Commons VFS would be under the Apache license. Unlike the GPL, the
SVNKit license doesn't say that all the code that uses the library has
to be under the same license, so applications are free to use whatever
license they choose. So it is perfectly acceptable for the code that
uses SVNKit to be use the Apache license. Their restrictions only come
into play upon redistribution, which we would never do. Furthermore, I
would imagine that the NOTICE file would want to provide some warning
about the consequences of downstream users taking advantage of the
feature.
LEGAL-45 was actually created for a similar use case but was never
answered. Brett marked it wontfix since he apparently decided to do
the work outside the JSF. I don't have karma to reopen it, but I've
added a comment to it regarding this. If someone could reopen it I'd
appreciate it.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SVNKit
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 28, 2009, at 7:53 AM, Julien Vermillard wrote:
> On Tue, Aug 25, 2009 at 7:08 PM, William A. Rowe,
> Jr.<wr...@rowe-clan.net> wrote:
>> Ralph Goers wrote:
>>> I wrote an Apache Commons VFS "Provider" for SVNKit. SVNKit's
>>> license is
>>> at best as viral as the GPL. As such, I have not added the
>>> provider to
>>> VFS (or made it open source at all for that matter). However, the
>>> discussion regarding APR leads me to believe that including the
>>> provider
>>> in VFS would be OK because:
>>> a) it is optional - SVNKit would be listed as an optional
>>> dependency in
>>> the pom.xml and VFS would not include support for the provider
>>> unless
>>> the SVNKit jar is present.
>>> b) SVNKit would not be distributed by the ASF. The user would have
>>> to
>>> specifically add the dependency to their pom.xml to build their
>>> application or add it to the appropriate classpath directory.
>>>
>>> SVNKit's license is at http://svnkit.com/license.html
>>>
>>> Thoughts?
>>
>> Exactly. The user would have to install svnkit (reviewing its
>> license
>> terms) in order to use the provider. The combination is subject to
>> the
>> svnkit license (as well as the AL, obviously). The source code and
>> the
>> binaries distributed by the ASF must not be under this license.
>>
>> (Except perhaps for an svnkit optional binary package, see my earlier
>> comments).
>>
>>
>
> What we did for Apache MINA was to provide a sepial maven profile for
> building the modules using LGPL licensied libs.
> If you build MINA with the default maven parameter, no LGPL libs are
> downloaded and the module using it is not built.
> HTH
> Julien
Thanks. With Commons VFS it is actually a bit easier. VFS has a
mechanism to specify required runtime dependencies for file system
providers. For example, the webdav support requires a jackrabbit jar.
If the jar (or rather, a specific jackrabbit class) is not present
then that provider is not loaded and its protocol isn't supported. In
the Commons VFS pom the SVNKit (and jackrabbit) jar is specified as
optional. So all the user of VFS has to do to enable certain providers
is add the dependency for the needed jar(s) to their project.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SVNKit
Posted by Julien Vermillard <jv...@gmail.com>.
On Tue, Aug 25, 2009 at 7:08 PM, William A. Rowe,
Jr.<wr...@rowe-clan.net> wrote:
> Ralph Goers wrote:
>> I wrote an Apache Commons VFS "Provider" for SVNKit. SVNKit's license is
>> at best as viral as the GPL. As such, I have not added the provider to
>> VFS (or made it open source at all for that matter). However, the
>> discussion regarding APR leads me to believe that including the provider
>> in VFS would be OK because:
>> a) it is optional - SVNKit would be listed as an optional dependency in
>> the pom.xml and VFS would not include support for the provider unless
>> the SVNKit jar is present.
>> b) SVNKit would not be distributed by the ASF. The user would have to
>> specifically add the dependency to their pom.xml to build their
>> application or add it to the appropriate classpath directory.
>>
>> SVNKit's license is at http://svnkit.com/license.html
>>
>> Thoughts?
>
> Exactly. The user would have to install svnkit (reviewing its license
> terms) in order to use the provider. The combination is subject to the
> svnkit license (as well as the AL, obviously). The source code and the
> binaries distributed by the ASF must not be under this license.
>
> (Except perhaps for an svnkit optional binary package, see my earlier
> comments).
>
>
What we did for Apache MINA was to provide a sepial maven profile for
building the modules using LGPL licensied libs.
If you build MINA with the default maven parameter, no LGPL libs are
downloaded and the module using it is not built.
HTH
Julien
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: SVNKit
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ralph Goers wrote:
> I wrote an Apache Commons VFS "Provider" for SVNKit. SVNKit's license is
> at best as viral as the GPL. As such, I have not added the provider to
> VFS (or made it open source at all for that matter). However, the
> discussion regarding APR leads me to believe that including the provider
> in VFS would be OK because:
> a) it is optional - SVNKit would be listed as an optional dependency in
> the pom.xml and VFS would not include support for the provider unless
> the SVNKit jar is present.
> b) SVNKit would not be distributed by the ASF. The user would have to
> specifically add the dependency to their pom.xml to build their
> application or add it to the appropriate classpath directory.
>
> SVNKit's license is at http://svnkit.com/license.html
>
> Thoughts?
Exactly. The user would have to install svnkit (reviewing its license
terms) in order to use the provider. The combination is subject to the
svnkit license (as well as the AL, obviously). The source code and the
binaries distributed by the ASF must not be under this license.
(Except perhaps for an svnkit optional binary package, see my earlier
comments).
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org