What about Linphone? It seems a lot easier to use and setup, and is also multi-platform. I think if there was a standard way to provision a SIP client using a URL, that would help a lot.
Since otr4j is free software, we can just fork and ignore BlueJimp's CLA, as we have always done. But it would be even better if all parties used a single fork, and we're working on that now. (that's the core idea of starting the otr4j/otrj4 repo) .hc Lee Azzarello: > Heya, > > I just picked up on this thread now, two months too late but I would > like to chime in about my support of ostel.co. I continue to support > the public service, which has 41K registered users and is going > strong. As you may know, end user support is weak due to the project > being a low priority for both GP and Series Digital, though the user > base is active. > > I've done a number of private deployments of the ostel stack. It's > become a pretty standard procedure. My base rate is $3000 and it takes > about two days. That said I haven't done any development on the > backend stack in over a year. The primary reason is that the client > application landscape, while abundant is a mess. Client support is > also the more frequently asked question and it the most important area > for user interest. Jitsi continues to be the most fully featured > client as well as the most frequent request for user support. We at > Series Digital have discussed developing Jitsi to have a more > contemporary user experience, but the complexity of the code base as > well as a growing desire for WebRTC support has pushed that project > down on the priority list. > > So to me this acquisition by a well know enterprise software company > is a good sign for improved client support. Unfortunately it's a bad > sign for freedom. I'm committed to supporting the backend stack as the > world's only fully open source end-to-end secure SIP system. I'm > interested to see where Atlassian takes the development of the WebRTC > front end, especially regarding encryption. > > That's my two sense. It seems the CLA is a very bad sign for freedom > and I agree with Hans that moving away from otr4j in GP applications > would be a good move. > > Regards, > Lee > > > > On Sun, Apr 26, 2015 at 12:19 PM, Hans-Christoph Steiner > <[email protected]> wrote: >> >> >> Tom Ritter: >>> On 22 April 2015 at 08:41, Hans-Christoph Steiner >>> <[email protected]> wrote: >>>> >>>> This is sounding not so promising for the future of jitsi as free software. >>>> Atlassian seems to have no free software projects of their own whatsoever, >>>> and >>>> there page about "open source" is basically a sales pitch: >>>> >>>> https://www.atlassian.com/opensource >>>> >>>> more here, it looks like this is probably the Atlassian press release, >>>> more or >>>> less: >>>> http://techcrunch.com/2015/04/21/atlassian-acquires-open-source-video-conferencing-company-bluejimp-to-power-hipchats-video-chat/ >>>> >>> >>> If they're going to use Jitsi's (open) source code in their closed >>> source environment, and build on it without releasing the >>> contributions (which is possible as they can relicense any additional >>> developments to it) - it makes me wonder if past contributors to Jitsi >>> can assert copyright over their contributions. (I assume Jitsi wasn't >>> requiring contributor agreements like some projects do to clear >>> similar hurdles.) I don't know much about this part of open source >>> licensing though. >>> >>> -tom >> >> BlueJimp has required a CLA for contributions to their jitsi repositories: >> http://bluejimp.com/bca.pdf >> >> With this clause: >> >> "you hereby assign to us joint ownership, and to the extent that such >> assignment is or becomes invalid, ineffective or unenforceable, you hereby >> grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, >> royalty-free, unrestricted license to exercise all rights under those >> copyrights. This includes, at our option, the right to sublicense these same >> rights to third parties through multiple levels of sublicensees or other >> licensing arrangements; " >> >> Which seems to me to say that they can relicense any of the jitsi source code >> as they please. That's part of my objection to having otr4j governed by >> their >> CLA: >> >> https://github.com/jitsi/otr4j/issues/15 >> >> .hc >> >> >> -- >> PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 >> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 >> _______________________________________________ >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >> To unsubscribe, email: [email protected] > _______________________________________________ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: [email protected] > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
