Jitsi switching to the Apache open source license is what the doctor ordered.
Blue Jimp, and with it Jitsi, was acquired by Atlassian in April this year. I wrote at the time about Jitsi’s open source license:
The problem with getting the Jitsi Videobridge to larger corporations was its open source license
- Jitsi uses LGPL. A non-permissive license that is somewhat challenging for commercial use. While it is suitable for SaaS, many lawyers prefer not to deal with it
- This reduces the Jitsi Videobridge’s chance to get adopted by enterprise developers who can pour more resources into it
- This may limit Jitsi from building the ecosystem Atlassian wants (i.e – outsourcing some of the development effort to an external developers community)
- Using BSD, MIT or Apache licenses would have been a better alternative. Will Atlassian choose that route? I am not sure
- Did Atlassian leave the open source offering due to legal issues or real intent in becoming an open source powerhouse?
You can read my explanation on open source licenses. If you read the comments as well, you’ll see how complex and mired with landmines this domain is.
Last week, an announcement was made in the jitsi-dev mailing list: Jitsi is switching from LGPL to Apache license:
LGPL, our current license allows everyone to integrate and ship our various jars. Once you start making changes and distributing them however, then you you need to make sure these changes are also available under LGPL, AKA the LGPL reciprocity clause.
What I found interesting weer the next two paragraphs:
As the copyright holder, in BlueJimp we have been been exempt from this reciprocity clause. Even though we rarely use it, we had the liberty to modify our code without making our changes public. No one else had this option.
Switching to Apache ends our advantage in this regard, and allows everyone to use, integrate and distribute Jitsi with a lot less limitations.
Some things to notice here:
- People who made changes to the Jitsi code base had to contribute back the code to Blue Jimp if they wanted these changes to be a part of the official Jitsi distribution, along with the ability for Jitsi not to act the same – Jitsi maintained a different “license” for itself – this works well when your business model is consulting and customization of the open source project you maintain – not so good for a large enterprise
- Atlassian took a different approach here by switching to Apache:
- Atlassian internally has the same decision making processes as other large enterprises. LGPL is harder to adopt than Apache, making a switch to the Apache license for Jitsi a reasonable step to take – preferential treatment for Apache license in Atlassian and elsewhere played a key role here
- It removed the possible nightmare of maintaining all of the existing CLAs (contributor license agreements) – they might have found them inaccurate, requiring a modification in their terms, needing a reassignment to Atlassian, etc – it was a good time to make the switch to Apache anyway
- It gives a strong signal to the market, and especially to large enterprises that Jitsi is something they can use – if this turns out well, there will be additional contributors to this software package, as it is a popular one in the WebRTC industry
- This switch from LGPL to APL (Apache) changes nothing in the ability of Blue Jimp and Atlassian to modify the base code and not contribute it back to the open source package
- This kind of a thing has happened before during acquisitions of open source project teams
- It also happens when competition starts using your own open source against you (think Google’s Android)
- It is unlikely to happen in the short or medium term, based on the signals coming from Atlassian and their current focus
- This opens up a powerful WebRTC media server (an SFU actually) to a larger number of vendors
All in all, this is a great move to our WebRTC ecosystem. Atlassian is doing the right moves in maintaining the Jitsi community happy and engaged while attracting the larger players in the market. I wouldn’t have done it any other way if I were in their shoes.
Can’t decide which open source media server to use? Towards that goal, I created a Media Server Framework Selection Sheet. Use it when the need comes to select an open source WebRTC media server framework for your project.