brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: Windows support via XebiaLabs OverThere
Date Mon, 09 Feb 2015 17:35:29 GMT
On 9 February 2015 at 16:58, Andrew Kennedy
<andrew.kennedy@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.

Mime
View raw message