Twitter github

Openfire switches to the Apache License 2.0

I was having my morning caffeine fix and saw a tweet go by…

OpenFire goes Apache 2.0

I quickly went to the front page and noticed it hasn’t been updated yet:

OpenFire

However, this is interesting news to say the least. When established open source projects backed by some company switch licenses, there’s usually a business model change afoot. Or was there pressure from Google to switch the license since Google Wave uses Openfire under the covers>?

Thankfully, Matt Tucker’s explanation hints at some of the reasons:

I’m happy to announce that Openfire will be moving to a more liberal open source license — Apache 2.0. Apache 2.0 provides significantly more flexiblity than the GPL in virtually every way, so it should be a big win for the community all around. We expect to get all the source code headers updated for the next release. There were several motivations for making this change:

  1. The GPL license was preventing some companies from using Openfire due to corporate policies
  2. There was no reason to keep using GPL and end-users generally seem to prefer Apache
  3. We’d like to encourage a broader range of commercial companies to contribute to the project and the Apache license is a good way to help make that happen

Would be happy to answer question or comments.

It was delightful to see the Openfire community be notified of the license change, with reasons why and a request for feedback. Scratch this one for the proper way of doing a license change in an open source community. In the open source world, we hold transparency sacred. Don’t be like Aptana when they switched from EPL to GPL and told no one until it was too late.

It’s important to be upfront and transparent.

  • There are also other projects changing licensing:
    I’m using Logback (http://logback.qos.ch) as native SLF4J implementation.
    just from the logback mailing list:

    Ceki Gülcü:
    After a very long investigation resulting in a better understanding of
    licensing issues, I think dual-licensing logback under EPL 1.0 and
    LGPL 2.1 would help with the project’s adoption.
    Licensees can then choose either the terms of the EPL or the terms of
    the LGPL when they use logback. The EPL license will placate
    organizations which refuse the restrictions imposed by the LGPL
    whereas the LGPL license ensures continuity in licensing and also
    keeps the door open for licensees already bound by the terms of
    (L)GPL.

    So much good news these days about licensing!

  • There are also other projects changing licensing:
    I’m using Logback (http://logback.qos.ch) as native SLF4J implementation.
    just from the logback mailing list:

    Ceki Gülcü:
    After a very long investigation resulting in a better understanding of
    licensing issues, I think dual-licensing logback under EPL 1.0 and
    LGPL 2.1 would help with the project’s adoption.
    Licensees can then choose either the terms of the EPL or the terms of
    the LGPL when they use logback. The EPL license will placate
    organizations which refuse the restrictions imposed by the LGPL
    whereas the LGPL license ensures continuity in licensing and also
    keeps the door open for licensees already bound by the terms of
    (L)GPL.

    So much good news these days about licensing!

  • Thanks Ekke, I didn’t know about Logback! That’s great news!

    We should add projects who use to EPL on Eclipsepedia

  • Thanks Ekke, I didn’t know about Logback! That’s great news!

    We should add projects who use to EPL on Eclipsepedia