[guardian-dev] jitsi's parent company BlueJimp becoming part of Atlassian

Fri Jun 5 13:46:53 EDT 2015

I've only used Linphone on iOS and Android.

Secure calling is not a low priority for us, but unfortunately it is not the
top priority since other people are in a better position to take that work on.
 But I would really like to help get more coordination of efforts so that we
can see all of the long tail services that operate on free software using open
standards succeed.

That's the big question: how can we gather lots of little bits of funding and
effort to improve the clients?  I think that's the big blocker on secure SIP
stuff taking off.

.hc

Lee Azzarello:
> how was your user experience with Linphone on the desktop?
> 
> -lee
> 
> On Friday, June 5, 2015, Hans-Christoph Steiner <hans at guardianproject.info>
> wrote:
> 
>>
>> 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
>>> <hans at guardianproject.info <javascript:;>> wrote:
>>>>
>>>>
>>>> Tom Ritter:
>>>>> On 22 April 2015 at 08:41, Hans-Christoph Steiner
>>>>> <hans at guardianproject.info <javascript:;>> 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:  guardian-dev-unsubscribe at lists.mayfirst.org
>> <javascript:;>
>>> _______________________________________________
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>> <javascript:;>
>>>
>>
>> --
>> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81
>>
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81