Please, what is the licence (MIT, ...) used by LittleShoot ? Regards.

[AlainLavoie]

Please, what is the licence (MIT, ...) used by LittleShoot ? Regards.

[adamfisk]

LittleShoot is under the GPL v2 license, although we'll likely move to GPL v3 at some point. If you're interested in alternative licenses, feel free to contact us directly at in...@littleshoot.org.

[Alain Lavoie]

Hello,

I am looking for a base product to launch a service.
I have no problem displaying and publishing that my base is from a known or public source,
but I do not wish to continue the open source philosophy.
I will certainly not sale that service, but, I do not wish to open the source.
I am searching for C# (which I do not know at all, yet), but c++ is good also.
I am looking for an MIT licence, which, I believe, is providing me enough
freedom.  Your product looks good.  If you are open for that situation,
let me know, or if you are kind enough to redirect me on some equivalent
product with the MIT philosophy, I would be delighted.

Thank you for your quick response.

Regards.

On Fri, May 27, 2011 at 1:39 PM, adamfisk <a...@littleshoot.org> wrote:

GPL v2 license,

--
Alain Lavoie

Dexto inc.

[adamfisk]

We currently only offer LittleShoot under the GPL, and we're unlikely to offer it under Apache or MIT licenses any time soon, unfortunately. LittleShoot is primarily written in Java on the client side, with the server side written primarily in Python. There has bee considerable development on the LittleShoot core over the last six months or so, and we now fully support XMPP for the signaling layer in addition to a number of optimizations and additional security layers.

Many of these changes are still undocumented, although the API has undergone several iterations. You can access LittleShoot running locally from an HTTP REST API outlined in more detail here:

http://dev.littleshoot.org:8084/display/LSDOCS/LittleShoot+Client+Documentation

-Adam

[Alain Lavoie]

Again, thank you for your quick responses.
I will respect the licence you are displaying.
I though aiming on a XMPP platform, but, it seems, from my readings, that it always
imply a middle man (the server) to transfer one message from peer A to peer B.
I do not mind having communication channel negociated with a server, but I
want to let each machine send messages to each other, without the server intervention after
that initial step.  All readings represent the middle server as acting in the shadow, but
I do not wish that infrastructure, as it require more cpu, and server management.
I did not persue the XMPP study for that reason.

Since you are at the heart of that implementation, can you confirm my observations ?

Regards, and good luck in your development.

--
You received this message because you are subscribed to the Google Groups "LittleShoot" group.
To post to this group, send email to littles...@googlegroups.com.
To unsubscribe from this group, send email to littleshooter...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/littleshooters?hl=en.

[adamfisk]

You can't generally create direct connections between peers without initially negotiating those connections through a publicly addressable signaling layer. The signaling layer (XMPP, SIP, whatever) is used to initially negotiate that connection, essentially allowing those firewalls to be traversed.

LittleShoot's XMPP integration initially sets up a direct control socket, negotiated over XMPP, and then uses that control socket to establish all future connections.

-Adam