Sunday, December 23, 2012

Red5 New License – Apache Software License 2.0


The Red5 Open Source Media Server has adopted a new license, Apache Software License 2.0. Rather than try and explain our reasoning, I’ve copied my exact email request that I had sent to the team. After a short period, the votes were counted and we had made our decision. Please read the below for more context on why we decided to go with Apache Software License 2.0 (ASL 2.0).
The license change is reflected in r4309 (http://code.google.com/p/red5/source/detail?r=4309#)

Team:
I hope all of you are doing well and living your lives to the fullest. As many of you know, we as a project are maturing as we gather momentum towards our 1.0 Release. It’s hard to believe that we started the project over 6 years ago around September of 2005 (http://code.google.com/p/red5/source/list?num=25&start=25). The motivation behind this email is to ask for your support and approval of a licensing change to the Red5 Project, its’ source code and all accompanying material. I will provide some context and reasoning behind the decision. As some of you are aware, we originally chose LGPLv3 license because it allowed the server to remain open, yet allow for adoption in the industry by groups that could not release their own source code. Generally, we tried to think of Red5 in the same regard as Tomcat. Our goal was to remain open without restricting proliferation among the industry. GPL would have required any code that statically or dynamically linked to the project source be open sourced. This was too restrictive for wide spread use. This then brought us back to LGPLv3 which is where the current codebase stands. It’s been recently brought to my attention that LGPLv3 may be too restrictive for certain use cases that are becoming prevalent in our industry.
I will explain in simplified terms what consequences our license has on an entire industry today.
May I point to Android as the use case involved with this discussion. At the moment, LGPL allows for linking either statically or dynamically to proprietary code. LGPL also ensures that the user of a library has the right to reverse engineer and modifiy the LGPL library in any way they see fit. So for instance, if someone packaged up a web application inside of Red5 and created an installer, the end user could replace the red5.jar with a new version if they so please.  However, with Android, an applicaiton is packaged up as a DEX file which is one file that has many libraries compiled into it. Taken directly from android’s open source page:
Here are some of our specific concerns:
  • LGPL (in simplified terms) requires either: shipping of source to the application; a written offer for source; or linking the LGPL-ed library dynamically and allowing users to manually upgrade or replace the library. Since Android software is typically shipped in the form of a static system image, complying with these requirements ends up restricting OEMs’ designs. (For instance, it’s difficult for a user to replace a library on read-only flash storage.)
  • LGPL requires allowance of customer modification and reverse engineering for debugging those modifications. Most device makers do not want to have to be bound by these terms, so to minimize the burden on these companies we minimize usage of LGPL software in userspace.
  • Historically, LGPL libraries have been the source of a large number of compliance problems for downstream device makers and application developers. Educating engineers on these issues is difficult and slow-going, unfortunately. It’s critical to Android’s success that it be as easy as possible for device makers to comply with the licenses. Given the difficulties with complying with LGPL in the past, it is most prudent to simply not use LGPL libraries if we can avoid it.
For these reasons, LGPLv3 is not suggested. We had not foreseen these restrictions and use cases when the project first started. Android as well as other platforms would be severely restricted and proliferation efforts would be limited. Exposure to these platforms increases visibility of the project and pushes us into uncharted area. We can remain confident that our service to the community will continue and that the project may find new and interesting uses.
Given that these conditions and restrictions do exist as stated above, we should identify what licenses could suit our needs. I propose that we evolve our license to a less restrictive license such as Apache Software License 2.0. This license allows for such use cases as stated above while allowing us to remain true to our original intentions. It should be noted that the Apache Software License is used by complimentary projects such as Tomcat which as you know is our default embedded servlet container. Taken directly from the Apache Foundation site:
Apache License, Version 2.0 (current)http://www.apache.org/licenses/LICENSE-2.0 ( TXT or HTML )The 2.0 version of the Apache License was approved by the ASF in 2004. The goals of this license revision have been to reduce the number of frequently asked questions, to allow the license to be reusable without modification by any project (including non-ASF projects), to allow the license to be included by reference instead of listed in every file, to clarify the license on submission of contributions, to require a patent license on contributions that necessarily infringe the contributor’s own patents, and to move comments regarding Apache and other inherited attribution notices to a location outside the license terms (theNOTICE file ).The result is a license that is supposed to be compatible with other open source licenses, while remaining true to the original goals of the Apache Group and supportive of collaborative development across both nonprofit and commercial organizations. The Apache Software Foundation is still trying to determine if this version of the Apache License is compatible with the GPL.All packages produced by the ASF are implicitly licensed under the Apache License, Version 2.0, unless otherwise explicitly stated. More developer documentation on how to apply the Apache License to your work can be found in * Applying the Apache License, Version 2.0 *.
If you support and approve of the license change, please respond with your approval. If you would like to discuss the ramifications before voting, you may contact out of band and I would be happy to go over these changes. Below are several links which provide useful information and add to the discussion. Please respond as soon as you can. We are looking here for a unanimous vote. If users are unavailable, we will move forward with the majorty vote and continually try to contact previous contributors.
Last, I want to thank you all for all of your hard work. Your contributions are appreciated. You should be proud of these accomplishments. May you continue living your life to the fullest.  Thank you.
ADDITIONAL INFORMATION
Apache Software License 2.0 looks nice too (ASL
The best explanation as to why LGPLv3 doesn’t work with Android
http://source.android.com/source/licenses.html

outlining a simplified explanation of dynamic linking code with LGPLv3
http://www.gnu.org/licenses/lgpl-java.html

how VideoLAN changed their license
http://www.videolan.org/press/lgpl.html

GNU’s take on who would need to sign off on a license change
http://www.gnu.org/licenses/gpl-faq.html#LGPLJava

for context, our license
http://www.gnu.org/licenses/lgpl.html
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts