Topic 1: project’s license

Opensource software completely challenged the tech industry strategies on working on projects. It allows individuals to contribute to projects they are using, and passionate about. This aspect of open source is defined by the license used for the project. In this article I will share about my experience contributing to a project with the Apache License and the importance of licenses.

Open Source Licenses define the terms and conditions under which the project can me used, modified and distributed (Open Source Initiative, 2022).

We explored the different types of licenses in class and I was curious to see how projects would choose to apply OSI approved licenses to their projects. The projects goals have to be clear when making this choice.

The license of the project I contributed to (Open Assistant) is the “Apache License 2.0”. It is a popular license part of the OSI approved licenses.
The creation and development of the Apache Software Foundation started in 1993. Since then, they have released three versions of the license. The currently used one is the 2.0 version.
This license is a permissive license, it allows to use, modify and redistribute the software. It also gives right to relicense within license compatibility. This makes it very flexible and interesting to work with(Apache.org, 2019).

Before contributing to the project I had to understand the License so I read it at this link: https://www.apache.org/licenses/LICENSE-2.0

The different sections cover the topics of :

• Redistribution, It is allowed to redistribute copies of the project or modified copies of the project under certain conditions. The main ones are:
  This license has to be given with any copy.
  If changes were done, they need to be notified.
  All of the copyrights and trademarks from the source need to be retained.
• Contributing: Any contribution will be under the terms and conditions of this license unless stated otherwise.

And other topics such as how to deal with trademarks and the absence of liability between contributors in case of being in tort.

This license allowed me to contribute to the code confidently by: forking it and running it locally on my machine and modifying that code. The license also ensured that my contribution will benefit the community and allow other contributors to modify my work and keep improving the project. As the presence of this license gives a legal framework to explore the project safely, it has an impact on the community. The community of this project was very active and a lot of programmers felt happy and confident contributing to this project.

In conclusion, contributing gave me a space to think about licenses and freedom to experiment and learn within a community of developers of different level. The choice of a permissive licence such as Apache raises questions. This choice depends heavily on the goal of the project but I personally think I wouldn’t use this type of license for a project for multiple reasons:

• Maintenance of copyleft: I think this aspect is important to an open source project. Allowing users to distribute under proprietary licenses does not allow the project to keep its freedom and compatibility with other open source projects.
• Maintenance of a cohesive community: I think a cohesive community is very important to an open source project. allowing to create fragmentations of the project under proprietary licenses could create a competitive environment.

For those reasons, I feel more confortable using a copyleft license such as the GNU General Public License.

Open Source Initiative. (2022). Licenses. [online] Available at: https://opensource.org/licenses/.

Apache.org. (2019). Available at: https://www.apache.org/licenses/LICENSE-2.0.