Re: Windows support via XebiaLabs OverThere

[Alex Heneveld]

jruby is a good option -- trying to do anything deep with object 
references across the language barrier is painful, but api calls are 
pretty straightforward.

but best would be asking xebia if they can either revert the license or 
grant the ASF the right to distribute it under the ASL2

--a


On 09/02/2015 17:40, Andrew Kennedy wrote:
I agree the legal issues are a potential minefield. It's really annoying
that OverThere actually used to be Apache 2.0 licensed. I wonder if we
could reach out to Xebia and explain that their method of dual licensing is
having the effect of preventing use of their code in ASF projects, and see
if they would change it?

I also saw wiseman, but disregarded it for the same reason, it seems
abandoned. Thinking about the Ruby client more, it seems pretty feasible,
looking at this example from the JRuby wiki on GitHub:

-
https://github.com/jruby/jruby/wiki/JRubyAndJavaCodeExamples#Java_calling_JRuby

Andrew.


--
-- andrew kennedy ? distributed systems hacker :
http://blog.abstractvisitorpattern.co.uk/ ;

On 9 February 2015 at 17:35, Richard Downer <rich...@apache.org> wrote:

On 9 February 2015 at 16:58, Andrew Kennedy
<andrew.kenn...@cloudsoftcorp.com> wrote:
Hm.

What's wrong with the second option from legal, i.e. making it an
optional
dependency?
The issue that I see is that it imposes additional burdens on our
users. The license exception is not quite the get-out-of-jail-free
card that it first looks. There are two problems that I have
identified (there may be more):

Firstly, it is common for Brooklyn's commercial users to write their
own entities that connect to proprietary software or hardware, and
that their own code is kept closed source. That is absolutely fine
when joined with ASL2 projects such as Brooklyn. However this would
cause the "open source exception" clause of the OverThere license to
be void and revert to GPL, or require the user to seek a license from
XebiaLabs.

Secondly, even when there is no closed-source parts, the "open source
exception" clause still imposes further restrictions, namely that
source code must always accompany binary distribution. Again this is
something that ASL2 does not require, but the presence of OverThere
adds these burdens to the user.

So I am quite concerned that our *only* way of talking to Windows adds
these extra burdens that our *users* must resolve.

problem is that alternative Java implementations of WinRM are pretty thin
on the ground. Well, non-existant, as far as I know, so the Xebia
implementation is really the only choice.
There are some others; for example wiseman:
https://java.net/projects/wiseman/
although how functional it is I do not know; it appears the svn
repository has not been updated in 5 years.

But I certainly agree that from a technical viewpoint OverThere is
almost certainly the best implementation, by a considerable distance.

There *is* a Ruby client implementation, so maybe we could bind to that
using JRuby, and that would sove our client problem? The license for this
ios Apache 2.0, so we'd be all good on the legal front, it's just
technically more complex.
I hadn't considered that - it is a very interesting option. There is
also a Python client (pywinrm, MIT license, which is Apache category
A), and Jython bindings (PSF license, also category A). Maybe there
are a few more options out there than I first considered...!

Richard.