Last Thursday, I was given the opportunity to do and present a case study on Intellectual Property (IP) in Opensource for the PSIA — Philippine Software Industry Association. My subject was the Apache Software Foundation. I thought I’d give a summary of my presentation here.. enjoy! ;-)  (I’d also like to take this opportunity to thank Mykol and my Exist family for all their support at the PSIA event Cheers to everyone!)

What is the ASF?

"We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users" –that is the motto of the ASF. The Apache Software Foundation is a 501(c)3 non-profit and community-centric entity whose aim is to be the ideal environment in the development of open source projects.

Short History of the ASF

Everything started with the HTTPD server, when its users started patching and fixing the server after the original developers lost interest in the project. They’ve setup a mailing list where they conducted their discussions regarding issues that they are encountering in the project. After some time, other users also began participating in the list and were contributing fixes and patches. These group of users called themselves the Apache Group, with the term Apache coming from the Apache tribe of the Native American Indians which were known for their superior skills in warfare strategy. As time went by, the group began hosting other projects and the need for a more formal and legal entity became obvious. Thus, in 1999 the ASF was born.

The ASF Structure

The ASF structure is divided into two sections — the administrative side and the development side. The administrative side is focused on the overall welfare of the foundation, while the development side is more focused on the welfare of their respective projects in the foundation. The administrative side are the board, the officers and the members of the ASF. The development side is composed of the PMC members, the committers, the contributors and the users.

ASF Licensing

1. Distribution Licenses
   • Apache License 1.0 - specifies that the copyright text and the conditions list must be retained or indicated in each file of the project. It should also be acknowledged in the documentation and advertising materials that the the project uses an ASF license. It also restricts the project or product from using the term ‘Apache’ in its name.
   • Apache License 1.1 - is the same as version 1.0, except that it is no longer required to attribute in their advertising materials that the project is using an ASF license.
   • Apache License 2.0 - revised and more detailed version of 1.1. With 2.0 though, it is no longer required that the copyright licenses and conditions list be specified in each file, but instead just have them referenced so as to prevent alterations or modifications in existing sources. It also aims to move comments regarding Apache and other inherited attribution licenses to a Notice file.
   • The ASF also has this rule that all projects under the ASF license cannot include a library that has a more restrictive license than the ASF license in the project distributions. We had this issue in Apache Archiva a couple of months ago. The project is using jasper reports which has a more restrictive license than the ASF license therefore we couldn’t include that in the distribution. What the project team did was to just give out instructions to the users on how to build the project from source if they want to use that reporting api with Archiva. Another workaround the team has been considering was switching to an ASF licensed api instead.
2. Contributor License Agreement (CLAs)
   • Individual CLA. This is the agreement for an individual contributor, meaning the contributor gives the foundation permission to distribute their contributions, modify it or add something to it.
   • Corporate CLA. This covers the whole company. For example, a company has a set of developers whose working on an open source project in the foundation. This agreement assures the foundation that the company’s developers has the company’s permission to contribute their code to the community. Each of these developers must also have an individual CLA, aside from the corporate CLA.
3. Software Grants
   • This is the agreement when a company donates software to the ASF. It just means that a company is giving the ASF permission to redistribute the software, modify it, add new features to it, etc. One good example of this is the OpenJPA, which was donated by BEA to the foundation in 2006 and has officially became a top level project in 2007.

Open Source Software Licenses

Here are a couple of open source software licenses that are commonly used:

1. Apache Licenses. Code can be redistributed, modified, changed or charge a fee for these changes. You just have to acknowledge that you’re using an ASF licensed project and retain or reproduce the copyright notices and conditions list if redistributing the project.
2. BSD (Berkeley Software Distribution). This has the same conditions as the Apache License, just different in wordings. You have to acknowledge that you’re using a BSD licensed project and retain or reproduce the copyright notices if redistributing a BSD licensed project.
3. EPL/MPL (Eclipse Plugin Licenses/Mozilla Plugin Licenses). A project under an EPL can be redistributed, modified and changed, but the part which is covered by the EPL must be retained under an EPL license. Only the parts that have been changed or added can be applied under a different license. A project under MPL, on the other hand, must always be under MPL even those parts that you’ve modified or added.
4. GPL and LGPL (General Public License and Lesser GPL). A project under the GPL can be re-distributed, modified or you could even charge fees for the modifications but you have to keep everything open sourced. This means that it cannot be used in proprietary software because you cannot close source it. A LGPL licensed project, on the other hand, can be used in proprietary software, meaning it’s for proprietary developers.

For more details about the above licenses and the other open source software licenses, please visit opensource.org/licenses

Leveraging Open Source Software

Below are some of the rewards and obstacles that I’ve personally experienced while doing open source development work

Rewards:

• Wide variety of people involved. People from all over the world are involved in the community, so there are lots of different ideas, opinions and approaches on how to tackle things. Everyone is willing to give and share their opinions and suggestions specially on critical things that would affect the project.
• Quality of code. As mentioned in the previous point, there are a wide variety of people involved therefore there are more sets of eyes that looks out for the quality of code. Aside from this, since it’s open source and everyone can see your code.. some developers tend to be more careful or meticulous in their coding.
• More people can pitch in the development. Everyone in the community is ready to lend a helping hand. Just ask, and people will be happy to give their feedback and if you have a blocker that’s preventing you from moving forward to what you’re doing, the community is there to help out.
• Driving the development in the community. When a private company develops a certain feature of the project and donates or contributes it back to the community, it benefits both the community and the company.

Obstacles:

• Scheduling the roadmap. The community has their own roadmap schedule and a company developing a product from that open source project also has their own set of scheduled deliverables to their clients. It’s hard reconciling these schedules since open source projects are not really time-boxed. The project gets released whenever it is ready to be released, while a commercial product is time-boxed and has a client waiting for deliverables of the product.
• In community vs. what the client wants. Since the community has it’s own roadmap and the client has their own set of deliverables that they are expecting, it’s hard to reconcile what gets included in the actual deliverables. Of course, what the client needs is still the priority so what can happen is a compromise to the client that not everything listed in the community roadmap might be included given their required deliverables and the time restriction.
• Technology used. It’s the community that decides what technologies to be used in the project. So if you’re building a commercial product from that open source software, you don’t have much control over what technologies to use. You could make suggestions in the community, but it’s still the community which makes the decision.

Some Real Life Examples

• MySql - MySql
• Jboss - Jboss
• Redhat - Redhat
• Gluecode - Gluecode Joe (Geronimo/Jetty/Jasper/ActiveMQ/Pluto/Derby)
• LogicBlaze - ActiveMQ/Service Mix
• Maestro - Maven/Continuum/Archiva/Redback
• q4e - Eclipse IDE for Maven

Posted on 04.28.08 to Tech blogs by oching. Tagged apache, apache license, archiva, ASF, bsd, cla, epl, gpl, intellectual property, lgpl, licensing, mpl, open source, psia, software. Subscribe to follow comments on this post. 2 comments. Add your thoughts or trackback from your own site.

• BROWSE / IN TIMELINE
• « Tinkering Around with Elgg..
• » Interested in Open Source Software Development? Here’s How You Can Get Involved..

• BROWSE / IN Tech blogs
• « Tinkering Around with Elgg..
• » Interested in Open Source Software Development? Here’s How You Can Get Involved..