brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrew.kenn...@cloudsoftcorp.com>
Subject Re: Windows support via XebiaLabs OverThere
Date Mon, 09 Feb 2015 16:58:22 GMT
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 <richard@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message