Windows support via XebiaLabs OverThere

[Richard Downer <ri...@apache.org>]

All,

I am often asked about Windows support in Brooklyn. The truth is that
Brooklyn does not yet have a good way of dealing with Windows hosts,
although some users have had moderate success with installing an SSH
service on Windows and configuring Brooklyn to not send Linuxy
commands.

In the pre-Brooklyn years, I had looked at XebiaLabs' OverThere
library[1]. I recently revisited it to see if it would help us. It
speaks WinRM, a Windows remote management service that permits remote
command execution, and is a standard part of recent versions of
Windows Server.

The problem is the license - it's GNU GPL plus special exceptions for
open source projects. I suspected that this would not be acceptable to
us and took it to the Apache legal-discuss list[2] to confirm.

The response[3] confirmed what I thought - we cannot bundle OverThere.

The only thing we can do (apart for dropping it and finding something
else) is make it an optional dependency so that Brooklyn will work
cleanly without it. Then it becomes the responsibility of our users to
decide if they want to install OverThere and accept the license
(either comply with the GPL, comply with the open source exception, or
seek a commercial license from XebiaLabs).

My instinct here is that the OverThere license has significant
concerns with it and that we should seek alternatives, to make life as
easy as possible for our users.

Any other thoughts?

Richard.

[1]https://github.com/xebialabs/overthere
[2]https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201501.mbox/%3CCABQFKi1VkauZv%2BQ%3DGCnUSwWUpJiOy7oXOKg6t2DBzFmdmGOM%3Dg%40mail.gmail.com%3E
[3]https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201501.mbox/%3CCAM1oqKp47QD-wktUMGWKZ6x5tx%3DKgbS62vD5ZNPvh4qO33SzQg%40mail.gmail.com%3E

Re: Windows support via XebiaLabs OverThere

[Alex Heneveld <al...@cloudsoftcorp.com>]

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 <ri...@apache.org> wrote:
>
>> On 9 February 2015 at 16:58, Andrew Kennedy
>> <an...@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.
>>

Re: Windows support via XebiaLabs OverThere

[Andrew Kennedy <an...@cloudsoftcorp.com>]

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 <ri...@apache.org> wrote:

> On 9 February 2015 at 16:58, Andrew Kennedy
> <an...@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.
>

Re: Windows support via XebiaLabs OverThere

[Richard Downer <ri...@apache.org>]

On 9 February 2015 at 16:58, Andrew Kennedy
<an...@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.

Re: Windows support via XebiaLabs OverThere

[Andrew Kennedy <an...@cloudsoftcorp.com>]

Hm.

What's wrong with the second option from legal, i.e. making it an optional
dependency?

> 2) make it an optional dependency and allow users to make the decision.

We can have a special 'Windows' build of Brooklyn that includes OverThere
that is not distributed under ASF channels. That is, users must create the
Windows build themselves, or it can be hosted on a non-ASF repository. The
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 *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.

- https://github.com/WinRb/WinRM

Where I think we really *don't* want to go is rolling our own WinRM client,
although it is just XML-RPC/SOAP over HTTP underneath...

Andrew.

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

On 4 February 2015 at 17:11, Richard Downer <ri...@apache.org> wrote:

> All,
>
> I am often asked about Windows support in Brooklyn. The truth is that
> Brooklyn does not yet have a good way of dealing with Windows hosts,
> although some users have had moderate success with installing an SSH
> service on Windows and configuring Brooklyn to not send Linuxy
> commands.
>
> In the pre-Brooklyn years, I had looked at XebiaLabs' OverThere
> library[1]. I recently revisited it to see if it would help us. It
> speaks WinRM, a Windows remote management service that permits remote
> command execution, and is a standard part of recent versions of
> Windows Server.
>
> The problem is the license - it's GNU GPL plus special exceptions for
> open source projects. I suspected that this would not be acceptable to
> us and took it to the Apache legal-discuss list[2] to confirm.
>
> The response[3] confirmed what I thought - we cannot bundle OverThere.
>
> The only thing we can do (apart for dropping it and finding something
> else) is make it an optional dependency so that Brooklyn will work
> cleanly without it. Then it becomes the responsibility of our users to
> decide if they want to install OverThere and accept the license
> (either comply with the GPL, comply with the open source exception, or
> seek a commercial license from XebiaLabs).
>
> My instinct here is that the OverThere license has significant
> concerns with it and that we should seek alternatives, to make life as
> easy as possible for our users.
>
> Any other thoughts?
>
> Richard.
>
> [1]https://github.com/xebialabs/overthere
> [2]
> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201501.mbox/%3CCABQFKi1VkauZv%2BQ%3DGCnUSwWUpJiOy7oXOKg6t2DBzFmdmGOM%3Dg%40mail.gmail.com%3E
> [3]
> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201501.mbox/%3CCAM1oqKp47QD-wktUMGWKZ6x5tx%3DKgbS62vD5ZNPvh4qO33SzQg%40mail.gmail.com%3E
>