[jitsi-users] Switching to the Apache Licenses

emcho · June 18, 2015, 8:25am

Hey all,

As you all know Blue Jimp has joined Atlassian. With this new partnership, we are making changes, due to expected growth - thanks to more eyes than ever on the Jitsi Community.

The first update we will be making is that we are changing our license.

In order to lower adoption barriers, Blue Jimp is switching to the Apache license and contributor agreement.

Most of you on this list are familiar with differences between Apache and LGPL, but we wanted to make sure everyone is on the same page:

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.

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.

We’ll also be using DocuSign for the Apache Contributor License Agreement, so we need all existing contributors to sign the Apache CLA, but thanks to DocuSign, signing up for the new license will be just a few clicks.

Cheers,
Emil

···

--
https://jitsi.org

Philipp_Hancke · June 18, 2015, 7:47pm

Hey all,

As you all know Blue Jimp has joined Atlassian. With this new
partnership, we are making changes, due to expected growth - thanks to
more eyes than ever on the Jitsi Community.

The first update we will be making is that we are changing our license.

In order to lower adoption barriers, Blue Jimp is switching to the
Apache license and contributor agreement.

[...]

Switching to Apache ends our advantage in this regard, and allows
everyone to use, integrate and distribute Jitsi with a lot less
limitations.

I'd note that you had also switched from MIT to Apache for meet.
This has been reverted now (thank you), but I think the rationale you give here does not apply. Apache is more restrictive than MIT.

If you add copyright notice to existing individual files, I do not think it is sufficient to add just the new license and copyright owner as it was done in some commits which are now reverted

We’ll also be using DocuSign for the Apache Contributor License
Agreement, so we need all existing contributors to sign the Apache CLA,
but thanks to DocuSign, signing up for the new license will be just a
few clicks.

IANAL, but don't you need this agreement before making changes? To me the bluejimp CLA looks like you might not actually so you can avoid a multi-year period of waiting for agreement, but asking reasonably is more polite.

···

Am 18.06.2015 um 01:25 schrieb Emil Ivov:

James_Cloos · June 18, 2015, 5:31pm

In order to lower adoption barriers, Blue Jimp is switching to the
Apache license and contributor agreement.

This of course means that anyone using jitsi in a gpl2 project cannot
update to any new version.

I don't know whether that applies to anyone, but the announcement should
refect that fact just in case.

-JimC

···

--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

Michael_Diordiev · June 18, 2015, 3:38pm

Hey Emil,

Thanks for good news and the detailed explanation. Could you please explain
also about differences between MIT and Apache? In case we've already use
jitsi-meet in production, do we need to update all the files with this
license header or may use it as MIT till we don't need to merge from
upstream?

Regards,
Zalmoxisus

···

On Thu, Jun 18, 2015 at 11:25 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

As you all know Blue Jimp has joined Atlassian. With this new partnership,
we are making changes, due to expected growth - thanks to more eyes than
ever on the Jitsi Community.

The first update we will be making is that we are changing our license.

In order to lower adoption barriers, Blue Jimp is switching to the Apache
license and contributor agreement.

Most of you on this list are familiar with differences between Apache and
LGPL, but we wanted to make sure everyone is on the same page:

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.

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.

We’ll also be using DocuSign for the Apache Contributor License Agreement,
so we need all existing contributors to sign the Apache CLA, but thanks to
DocuSign, signing up for the new license will be just a few clicks.

Cheers,
Emil

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Ron_W · June 18, 2015, 6:07pm

Maybe jitsi could be dual licensed?

Also, if "included" means jitsi is merely launched by exec(), there is no
problem.

Further, a Remote Procedure Call interface can be used to allow jitsi
functionality to be used by a GPLv2 application - or vice-versa.

···

On Thu, Jun 18, 2015 at 1:31 PM, James Cloos <cloos@jhcloos.com> wrote:

> In order to lower adoption barriers, Blue Jimp is switching to the
> Apache license and contributor agreement.

This of course means that anyone using jitsi in a gpl2 project cannot
update to any new version.

emcho · June 18, 2015, 3:45pm

Hey Zalmoxisus,

Whatever you have retrieved under a specific license you can continue
using under that license.

I don't believe there are significant differences between MIT and
Apache BUT I am not a lawyer so you shouldn't trust me on that.

Emil

···

On Thu, Jun 18, 2015 at 5:38 PM, Michael Diordiev <zalmoxisus@gmail.com> wrote:

Hey Emil,

Thanks for good news and the detailed explanation. Could you please explain
also about differences between MIT and Apache? In case we've already use
jitsi-meet in production, do we need to update all the files with this
license header or may use it as MIT till we don't need to merge from
upstream?

Regards,
Zalmoxisus

On Thu, Jun 18, 2015 at 11:25 AM, Emil Ivov <emcho@jitsi.org> wrote:

Hey all,

As you all know Blue Jimp has joined Atlassian. With this new partnership,
we are making changes, due to expected growth - thanks to more eyes than
ever on the Jitsi Community.

The first update we will be making is that we are changing our license.

In order to lower adoption barriers, Blue Jimp is switching to the Apache
license and contributor agreement.

Most of you on this list are familiar with differences between Apache and
LGPL, but we wanted to make sure everyone is on the same page:

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.

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.

We’ll also be using DocuSign for the Apache Contributor License Agreement,
so we need all existing contributors to sign the Apache CLA, but thanks to
DocuSign, signing up for the new license will be just a few clicks.

Cheers,
Emil

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

emcho · June 18, 2015, 7:02pm

Hey James,

Thanks for commenting! I don't believe what you are saying is entirely
accurate. You might want to have a look at this:
http://www.apache.org/licenses/GPL-compatibility.html

In other words, you should be totally fine using Jitsi in GPL-ed projects.

Emil

···

On Thu, Jun 18, 2015 at 7:31 PM, James Cloos <cloos@jhcloos.com> wrote:

> In order to lower adoption barriers, Blue Jimp is switching to the
> Apache license and contributor agreement.

This of course means that anyone using jitsi in a gpl2 project cannot
update to any new version.

I don't know whether that applies to anyone, but the announcement should
refect that fact just in case.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

--
https://jitsi.org

emcho · June 18, 2015, 8:49pm

Hey Fippo,

Hey all,

As you all know Blue Jimp has joined Atlassian. With this new
partnership, we are making changes, due to expected growth - thanks to
more eyes than ever on the Jitsi Community.

The first update we will be making is that we are changing our license.

In order to lower adoption barriers, Blue Jimp is switching to the
Apache license and contributor agreement.

[...]

Switching to Apache ends our advantage in this regard, and allows
everyone to use, integrate and distribute Jitsi with a lot less
limitations.

I'd note that you had also switched from MIT to Apache for meet.
This has been reverted now (thank you),

This was only temporary though as we needed to consult with legal
counsel. We will be bringing the change back shortly.

but I think the rationale you give
here does not apply.

True. That's an exception. In the case of Meet there is no similar
privilege to give up. The main reason for the change there is
consistency. As the potential maintainer of a large number of open
source projects, it would be unreasonably hard for Atlassian to have
to manage them under a variety of licenses and contributor agreements.

Apache is more restrictive than MIT.

Could you please be more specific about the restrictions you are
referring to? Better yet, could you please give examples that
specifically apply to Jitsi Meet?

I have heard Apache being preferred to BSD and MIT because it (Apache)
is apparently a better-framed legal document/contract. It uses
terminology that maps to defined categories of IP, like copyright and
patent, and has the required language. MIT and BSD are good at showing
the intent behind the license but do not use the technical legal
language to do it.

If anything, there's an argument that under Apache, the licensee's
rights are actually a little broader in that it includes an explicit
patent license.

(Both of these points are being made in the post that George linked to
earlier in the thread)

If you add copyright notice to existing individual files, I do not think it
is sufficient to add just the new license and copyright owner as it was done
in some commits which are now reverted

We’ll also be using DocuSign for the Apache Contributor License
Agreement, so we need all existing contributors to sign the Apache CLA,
but thanks to DocuSign, signing up for the new license will be just a
few clicks.

IANAL, but don't you need this agreement before making changes? To me the
bluejimp CLA looks like you might not actually so you can avoid a multi-year
period of waiting for agreement,

Yes, this is correct. This is where the BlueJimp CLA comes into play.
The one exception being the Jitsi Meet pre-fork part of the code. The
difference there is that that code was originally MIT. The whole point
about MIT is that it allows you to redistribute under "whatever".
"Whatever" including proprietary licenses or, obviously, other open
source licenses like Apache.

but asking reasonably is more polite.

I have personally been hearing complaints about our use of LGPL for
*years*! I wouldn't have imagined that a switch to the more permissive
Apache would elicit anything but enthusiasm.

We live to learn.

Still, let's clarify something important.

We are all free to make our own choices.

The future of Jitsi as an open source project is very important to
Atlassian. The company believes that Apache is the best license for
this future and it is eager to contribute its resources and maintain
the project under the Apache software license. Everyone who agrees is
welcome to continue helping us.

Everyone who disagrees with the choice of the new license, and does
not wish to be a part of it under such conditions, is very much
welcome to take yesterday's version of the corresponding Jitsi
projects under the terms of the LGPL, fork them and continue
maintaining it under that license.

At the end of the day, we are all free to decide how we spend our own time.

I am not telling you where to invest yours. Please, don't tell me what
to do with mine.

Emil

···

On Thu, Jun 18, 2015 at 9:47 PM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

Am 18.06.2015 um 01:25 schrieb Emil Ivov:

Philipp_Hancke · June 18, 2015, 9:56pm

Emil,
[...]

Apache is more restrictive than MIT.

Could you please be more specific about the restrictions you are
referring to? Better yet, could you please give examples that
specifically apply to Jitsi Meet?

since you asked:
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and

So if I change the CSS to include my custom branding, I have to prominently say so. This is not required by the MIT license. It just adds to the hassle and will cause unintentional license violations.

[...]

IANAL, but don't you need this agreement before making changes? To me the
bluejimp CLA looks like you might not actually so you can avoid a multi-year
period of waiting for agreement,

Yes, this is correct. This is where the BlueJimp CLA comes into play.
The one exception being the Jitsi Meet pre-fork part of the code. The
difference there is that that code was originally MIT. The whole point
about MIT is that it allows you to redistribute under "whatever".
"Whatever" including proprietary licenses or, obviously, other open
source licenses like Apache.

It do not think it allows you to remove the copyright notice which you did. Even if it did, doing so is very rude.

[...]

but asking reasonably is more polite.

I have personally been hearing complaints about our use of LGPL for
*years*! I wouldn't have imagined that a switch to the more permissive
Apache would elicit anything but enthusiasm.

I doubt anyone would have refused to sign the new agreement for the LGPL licensed projects.

[...]

Still, let's clarify something important.

let me as well: by making the license change without announcing the intent to change the license (and listening to feedback), you show that the opinion of anyone else does not matter. That's not really what you intend, right?

As a counterexample, look at how you've done the votes for committer in the past. You always had that, even if you probably knew the result in advance

James_Cloos · June 18, 2015, 9:02pm

Thanks for commenting! I don't believe what you are saying is entirely
accurate. You might want to have a look at this:
http://www.apache.org/licenses/GPL-compatibility.html

In other words, you should be totally fine using Jitsi in GPL-ed projects.

If you read that page you'll see that apache2 is only compatible with
gpl3; I specifically noted gpl2.

My research showed that you had been using lgpl 2.1, which is compatible
with gpl2. But doing more I see that deb's copyright file shows that
you use some code which is apache2 (lib/src/java-jml/*, lib/src/
smack_src_3_2_2/*, lib/src/irc-api/*) so you already were incompatible
with gpl2.

So the chnage only affects any gpl2 projects which only use the lgpl2.1
parts of your code, which seems like it'd be no-one. Apologies for
the time waste; I should have looked deeper before replying.

I hope I didn't (unintentionally) imply any distaste for Jitsi or
Bluejimp. Lots of sip libs and endpoints in several languages and
environments successfully interacting together is tremendously important
for the sip community.

-JimC

···

--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

emcho · June 18, 2015, 9:07pm

James,

Thanks very much for your kind words!

Emil

···

On Thu, Jun 18, 2015 at 11:02 PM, James Cloos <cloos@jhcloos.com> wrote:

> Thanks for commenting! I don't believe what you are saying is entirely
> accurate. You might want to have a look at this:
> http://www.apache.org/licenses/GPL-compatibility.html

> In other words, you should be totally fine using Jitsi in GPL-ed projects.

If you read that page you'll see that apache2 is only compatible with
gpl3; I specifically noted gpl2.

My research showed that you had been using lgpl 2.1, which is compatible
with gpl2. But doing more I see that deb's copyright file shows that
you use some code which is apache2 (lib/src/java-jml/*, lib/src/
smack_src_3_2_2/*, lib/src/irc-api/*) so you already were incompatible
with gpl2.

So the chnage only affects any gpl2 projects which only use the lgpl2.1
parts of your code, which seems like it'd be no-one. Apologies for
the time waste; I should have looked deeper before replying.

I hope I didn't (unintentionally) imply any distaste for Jitsi or
Bluejimp. Lots of sip libs and endpoints in several languages and
environments successfully interacting together is tremendously important
for the sip community.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

--
https://jitsi.org

emcho · June 18, 2015, 10:28pm

Emil,
[...]

Apache is more restrictive than MIT.

Could you please be more specific about the restrictions you are
referring to? Better yet, could you please give examples that
specifically apply to Jitsi Meet?

since you asked:
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and

So if I change the CSS to include my custom branding, I have to prominently
say so. This is not required by the MIT license. It just adds to the hassle
and will cause unintentional license violations.

We are talking about a Copyright line or an @author tag here ... I am
sorry, I can't agree this can be considered significant hassle.

IANAL, but don't you need this agreement before making changes? To me the
bluejimp CLA looks like you might not actually so you can avoid a
multi-year
period of waiting for agreement,

Yes, this is correct. This is where the BlueJimp CLA comes into play.
The one exception being the Jitsi Meet pre-fork part of the code. The
difference there is that that code was originally MIT. The whole point
about MIT is that it allows you to redistribute under "whatever".
"Whatever" including proprietary licenses or, obviously, other open
source licenses like Apache.

It do not think it allows you to remove the copyright notice which you did.
Even if it did, doing so is very rude.

As I already answered in your comment on GitHub, the copyright notice
is not removed. It is now simply in the README file.

As for rudeness, acknowledgement to your initial contribution is given
in far more prominent places. Such as the project home page, the
project contributor's page, the README file (even prior to the change)
of the project.

[...]

Emil

···

On Thu, Jun 18, 2015 at 11:56 PM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

--
https://jitsi.org

Ingo_Bauersachs · June 18, 2015, 7:41pm

Emil, James is correct. From your link:

"Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license."

So it is relevant whether a GPL-project has the "either version 2 or newer" statement in the license header or not. E.g. Jitsi could not be included into the Linux Kernel anymore (this isn't about the usefulness or the technical possibility).

In that regard dual-licensing sounds reasonable. And contrary to others, I don't like the change.

Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 19.06.2015, at 00:34, Emil Ivov <emcho@jitsi.org> wrote:

Hey James,

Thanks for commenting! I don't believe what you are saying is entirely
accurate. You might want to have a look at this:
http://www.apache.org/licenses/GPL-compatibility.html

In other words, you should be totally fine using Jitsi in GPL-ed projects.

Emil

On Thu, Jun 18, 2015 at 7:31 PM, James Cloos <cloos@jhcloos.com> wrote:

> In order to lower adoption barriers, Blue Jimp is switching to the
> Apache license and contributor agreement.

This of course means that anyone using jitsi in a gpl2 project cannot
update to any new version.

I don't know whether that applies to anyone, but the announcement should
refect that fact just in case.

-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

--
https://jitsi.org

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

Philipp_Hancke · June 18, 2015, 10:51pm

It do not think it allows you to remove the copyright notice which you did.
Even if it did, doing so is very rude.

As I already answered in your comment on GitHub, the copyright notice
is not removed. It is now simply in the README file.

Which IMO is relicensing and I still doubt you can do that without consent from all copyright holders.

I have shown you what I consider the proper way out of this in the commit comment. Your call.

As for rudeness, acknowledgement to your initial contribution is given
in far more prominent places.

Giving credit to me as an individual does not mean you can remove the attribution of a copyright holder.

emcho · June 18, 2015, 7:54pm

Hey Ingo,

Emil, James is correct. From your link:

"Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license."

I'd have to educate myself on the "patent termination and
indemnification provisions" and why the FSF have a problem with them
but right now this sounds to me as mostly a problem of interpretation
and perspective. Likely ideology as well.

So it is relevant whether a GPL-project has the "either version 2 or newer" statement in the license header or not. E.g. Jitsi could not be included into the Linux Kernel anymore (this isn't about the usefulness or the technical possibility).

Well it is about the usefulness as well though.

In that regard dual-licensing sounds reasonable.

The Apache article I mentioned does quote the inconveniences of dual
licensing. It's basically a logistical issue that makes it much harder
to determine which license people are bound to.

And contrary to others, I don't like the change.

Sorry to hear that. Are the above arguments your only reasons?

Emil

···

On Thu, Jun 18, 2015 at 9:41 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

--
https://jitsi.org

emcho · June 18, 2015, 10:57pm

It do not think it allows you to remove the copyright notice which you
did.
Even if it did, doing so is very rude.

As I already answered in your comment on GitHub, the copyright notice
is not removed. It is now simply in the README file.

Which IMO is relicensing and I still doubt you can do that without consent
from all copyright holders.

You may want to read the MIT license again *and* get legal counsel. I
have done both and am comfortable with the current situation.

[...]

Giving credit to me as an individual does not mean you can remove the
attribution of a copyright holder.

Which is why it hasn't been removed and original ESTOS copyright
statement and MIT license are still there in the README file.

Emil

···

On Fri, Jun 19, 2015 at 12:51 AM, Philipp Hancke <fippo@goodadvice.pages.de> wrote:

--
https://jitsi.org

Ingo_Bauersachs · June 18, 2015, 8:12pm

-- sent from my mobile

Hey Ingo,

Emil, James is correct. From your link:

"Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license."

I'd have to educate myself on the "patent termination and
indemnification provisions" and why the FSF have a problem with them
but right now this sounds to me as mostly a problem of interpretation
and perspective. Likely ideology as well.

Same for me, but when it comes to the GPL, the FSF does have some authority I guess.

So it is relevant whether a GPL-project has the "either version 2 or newer" statement in the license header or not. E.g. Jitsi could not be included into the Linux Kernel anymore (this isn't about the usefulness or the technical possibility).

Well it is about the usefulness as well though.

That was solely meant about integrating Jitsi into the kernel (which out of my mind is the only project I know that is GPLv2 only).

In that regard dual-licensing sounds reasonable.

The Apache article I mentioned does quote the inconveniences of dual
licensing. It's basically a logistical issue that makes it much harder
to determine which license people are bound to.

Well sure it is more complicated. But anyone who actually bothers to deal with a license text should IMO be able to deal with it.

And contrary to others, I don't like the change.

Sorry to hear that. Are the above arguments your only reasons?

No. There's e.g. a specific fork of libjitsi we talked about over a year ago that most likely wouldn't be public without the LGPL. And I believe in copyleft.

(That said, I may have to move dnssecjava to Apache as well to get a contributor on board at all. You know who.)

Emil

Ingo

···

On 19.06.2015, at 01:26, Emil Ivov <emcho@jitsi.org> wrote:

On Thu, Jun 18, 2015 at 9:41 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

--
https://jitsi.org

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

Philipp_Hancke · June 18, 2015, 11:23pm

Can you explain your rationale for removing this from the LICENSE?
Making clear that any future contributions are subject to APL can be achieved in other ways.

But I am glad you agree that they can not be be removed, which offended me in the initial change. Thank you.

···

Am 18.06.2015 um 15:57 schrieb Emil Ivov:

On Fri, Jun 19, 2015 at 12:51 AM, Philipp Hancke > <fippo@goodadvice.pages.de> wrote:

It do not think it allows you to remove the copyright notice which you
did.
Even if it did, doing so is very rude.

As I already answered in your comment on GitHub, the copyright notice
is not removed. It is now simply in the README file.

Which IMO is relicensing and I still doubt you can do that without consent
from all copyright holders.

You may want to read the MIT license again *and* get legal counsel. I
have done both and am comfortable with the current situation.
[...]

Giving credit to me as an individual does not mean you can remove the
attribution of a copyright holder.

Which is why it hasn't been removed and original ESTOS copyright
statement and MIT license are still there in the README file.