We just completed some fairly deep coding on WebRTC video ourselves and began hosting the video and broadcasting our weekly call right to youtube.

https://youtu.be/Nt4Y5PFdf7w

Sorry, you are right. I made a mistake in that part about inheritance they do consider it similar to linking in a library in C.

Anyway, what I’ve seen from Jitsi it seems great product/project. I would think that is the best reason for Atlassian to be interested in it and the rest is just details. 🙂 I wish both companies and the open source community a lot of success.

Your interpretation seems to contradict some of the mainstream ones: https://www.gnu.org/licenses/lgpl-java.html

While inheritance does imply a derivative work, it alone does not trigger LGPL’s reciprocity clauses.

That said, while I agree a debate on licensing is always fun to have, I suggest you read the second part of my comment above.

I was just hoping I’d clear out the doubts on one of the questions Tsahi raised and that second part is potentially even more relevant.

I have felt little need to modify the JVB source code. It just works and since its usual mode of operation is running in a standalone process the license is not a big concern.

If you want to be exact (which you have to with licensing) there is no such thing as ‘modules’ in these licenses.

The LGPL (as does the GPL) talks about ‘derivative works’. Which means as it’s most basic form: a derivative work is when you take the code and then modify it.

So if you have a LGPL C-library and you link to it then you are fine. You are just using the library. You can obviously change the library, but when you distribute the changed library you need to include the source of said library (you can charge for your product of course, but you have to include the code of the LGPL parts).

In Java it’s a bit more complicated because how people are used to working with it. In the case of Java it means: you can only load and use a library. You can not use inheritance because that too is clearly a ‘derivative work’. So if you want to create a new interface for a LGPL library, you’ll need to include the source (or in this day and age you can also make it available for download) of that new interface when you distribute it.

As Tsahi says, businesses might not like the LGPL as much as the BSD-license because of this.

But the goal of the Free Software foundation is to give the receiver of the program more rights. Not the developer. Not a completely stupid idea or crazy idea, just a different philosophy.

Even most businesses rely on more software developed by others than just by themselves. Every receiver of software prefers to have the source of the program they are using in case the interests of the original developers don’t align with their own any more.

Emil, Thanks – and congrats on the acquisition 🙂

From my experience working in traded companies and dealing with due diligence processes through acquisition processes, I can say that LGPL is always regarded as a troublesome license. Not as much as GPL, but a lot more than BSD or MIT.

Simon,

Thanks. At this point in time, there are no alternatives that are as complete. There are other frameworks that can be used, but they require more work. Unless I am missing some specific alternative you want to mention.

> you must contribute everything back to the community –
> including all the parts you have unrelated to it.

That’s actually GPL. LGPL differs from GPL on exactly that point: you only need to give back the modifications. Not the newly added modules.

Also, to remove the doubt on whether Atlassian will be throwing all these efforts by obligation or because it believes in the future of the Jitsi community, you may want to check these two links:

https://jitsi.org/faq/patch (last paragraph of the question)
http://bluejimp.com/bca.pdf

P.S. And yeah, nice post!