Open source licensing

Introduction

Open source software is “software that can be freely used, changed, and shared (in modified or unmodified form) by anyone.”[1] The Open Source Initiative is a corporation founded in 1998 in California that reviews and approves licenses as conformant to the Open Source Definition(OSD). The OSD is a set of 10 criteria that software must meet to be classed as open source. These include free distribution which means the license should not “restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.” The full list can be found here http://opensource.org/docs/osd.

Licences

There are a number of licences that are widely used and each can have different rules regarding its use. These include the Apache 2.0 License[2] and the GNU General Public Licence[3]. The OSI has to approve a new licence via its review process which makes sure that it conforms to the OSD and proper categorisation into a category defined here http://opensource.org/proliferation-report such as “special purpose licenses”, for example licenses relating to government use. There are reasons for an open source project to be licensed under any particular licence, I will discuss the reasons for why some of these licenses are so popular.

Apache 2.0

The full definition can be found here http://www.apache.org/licenses/LICENSE-2.0 along with a list of projects that are licensed under it such as OpenOffice[4] and Hadoop[5]. It is a free software license by the Apache Software Foundation. This license allows anyone to distribute, or modify and redistribute software licensed under it without any royalties.

The licence also allows these modifications to be redistributed under a different licence. This is in contrast to copyleft licences such as the GNU GPL which does require the licence to apply to any modifications.[6] However, the Apache License 2.0 is compatible with the GNU GPL version 3 but any combined software must be licensed under the GPL.

 Android is another major software project that is mainly licensed under the Apache License. Google’s reasons for choosing this over some other license such as LGPL include that LGPL requires that the customer be able to modify and reverse engineer but usually the device makers do not want to comply with this. Also LGPL requires “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.” The nature of Android being that it is generally just a static system image, it would be hard to comply to this requirement. Other reasons can be found here http://source.android.com/source/licenses.html#why-apache-software-license.

GNU GPL

This is the free software licence that is most widely used.[7] As mentioned previously it is a copyleft licence, written by Richard Stallman of the Free Software Foundation. It means that users are free to either modify and redistribute the software or just redistribute it without changes, as long as it is still licensed under the GPL. There are a number of major software projects that are licensed under the GPL, these include WordPress[8] and VirtualBox[9].

 In the case of VirtualBox, it is developed by Oracle, one of the biggest technology companies in the world. You may be wondering how does it make money from this software if it is released for free. This is because it is actually dual-licensed, meaning that individuals are free to use it without paying for it as long as they respect the GPL license. However, if it is being used in a commercial setting, then it is encouraged to buy the commercial licence which offers “access to enterprise features and support for mission-critical use of VirtualBox.”[9] This is a way for companies to make money from open source software in general. Allowing the source code to be free and openly modified and improved benefits everyone, while having commercial licences allows the company to offer extra features or support to customers, giving added benefits to those customers while also making money for the company.

Conclusion

Developers must be careful in which licence they choose to release their software under. In some cases they might not have a choice if they are extending a particular piece of software that is licensed under a copyleft licence for example GPL. They must take care to make sure they know if they want to monetize the product, and how they would achieve that if is released under an open source licence. As shown above, it has been done in the case of VirtualBox, but not all applications will have a widespread commercial use.

It might be a good idea to study projects that may be similar, and/or carried out by successful companies to try and give an idea of which licences would be best to use. Also, the rights of end users have to be taken into account, as the project may be something that you are willing to let others modify and sell, possibly in the case of game mods, on the other hand you may not want that to happen.

References

1. http://opensource.org/

2. http://opensource.org/licenses/Apache-2.0

3. http://opensource.org/licenses/gpl-license

4. http://openoffice.apache.org/

5. http://hadoop.apache.org/

6. https://www.gnu.org/copyleft/

7. http://www.blackducksoftware.com/resources/data/top-20-open-source-licenses

8. http://wordpress.org/about/license/

9. https://www.virtualbox.org/wiki/Licensing_FAQ

 

Response to Why Pair Programming Is The Best Development Practice?

Response to https://blog.inf.ed.ac.uk/sapm/2014/02/17/why-pair-programming/ by s1369981.

Summary of article

The author discusses why pair programming is the best development practice. First of all there are reasons stated for not carrying out this practice such as a quote from Steve Wozniak advocating working alone, not on a team.Also other reasons such as programmers being more likely to be introverts and therefore may not be suited to pair programming. Then there are the reasons as to why pair programming is such a good development practice. I agree in the main with this article and have a few additional points to support this, yet also have some opinions that differ from what is originally written.

Personal experience

Having completed the System Design Project in my third year here, I have experienced first hand working in a team and knowing how well pair programming worked for us. Everyone was working towards building a robot that could play football and this task required lots of collaboration. There were many different parts to the overall system such as vision, artificial intelligence and movement of the robot. Therefore a decision was made early on to use pair programming as much as possible as we felt this would greatly increase our speed of development. This was especially important as there were deadlines every few weeks that required new capabilities in the robot to gain credit overall.

There are two points in this article under the heading “We need a proof my dear Watson”, the first is “a huge percentage of bugs and defects can be caught before release” and also “there is a lot of knowledge sharing and project ownership involved in the process.” I found this to be true in both instances as there were bugs that were definitely caught and fixed quicker by working in pairs rather than one person working on it and testing it themselves. I also found out that when working by myself it is much harder to make progress as I felt I needed to communicate with another team member. Therefore I also found the second point about knowledge sharing also to be true. In the end our team performed well, with a good performance in the final tournament, so I think using pair programming helped contribute to that success.

Pair Programming 101, do you always need to follow the rules?

The author also discusses 5 important rules about pair programming. One of which is “Pairs should be formed flexibly and naturally, rather than by fixed assignment.” They also state that a strategy should be followed when matching pairs, suggesting matching people with similar skills first and then trying junior developer plus senior developer. I would argue that there is a benefit to having pairs formed by assignment in some cases as if for example joining a new company or a graduate scheme, it is common for the junior developer to be paired with a senior developer. This allows the junior developer to learn from someone who has the experience of working at the company for years and who has experience of technologies that the junior developer has not used before.

Another rule is “Collaborate with your partner, do not critique his work.” I agree with this as if you are all working towards the same goal as part of a team, you want to be getting on together not critiquing the other person’s work. I know personally from working on other projects that this can lead to arguments which doesn’t help in achieving the goal you are supposed to be working towards.

Also stated is “Always use a big monitor(or more) and two keyboards.” I agree in the use of multiple monitors, in the case of the System Design Project we weren’t able to do this, but from my own experience of programming outside of this I have found this to help me be more productive. However, I don’t feel that using two keyboards is necessary, in fact I have never heard of this being used anywhere, but multiple monitor set ups are used in many companies.

Conclusion

In the main pair programming is a great development practice, and I have found it to work personally. However, some rules don’t always need to be followed and others are maybe better to be broken, depending on the type of project that is being undertaken. Care should be taken in matching people into pairs to give the best benefit to both developers and also to help the project in the best way, not just chosen because two people get along with each other or their skill level is the same.