Ch.10_Introduction.tex

\chapter{Introduction\label{intro}}
% setting
Public software licenses are central to the distribution of works in software engineering. In open source there must be an appropriate public software license attached to the source code in order for the piece of software to be freely available for possible modification and redistribution. Because open source is central to software engineering the licenses enabling open source should also be considered important in the same context.

% objective shortly
The objective of this thesis is to have an understanding on how to retrieve all public licenses in software engineering by conducting a multivocal literature review (detailed goals are outlined in Sections \hyperref[background]{1.3 Thesis goal and contributions}, \hyperref[rqs]{2.1 Research questions}).

% slr guidelines
The review follows Kitchenham and Charter's guidelines for systematic literature reviews \citep{kitchenham2007}. Furthermore, the review takes into account insights from practical experiences with systematic reviews \citep{mahdavi-hezahevi}\citep{nurmivaara}.

\section{Background}\label{background}\label{sec:bg}
% intro to section
In this section we briefly describe the terminology and background of public software licenses which we use in this thesis. It is worth to note that the terminology is largely unestablished in the academics and heavily debated in the industry.

% define public license
The definition of a public license is a license by which a copyright holder as licensor can grant additional copyright permissions to any and all persons in the general public as licensees \citep{hietanen2007license} which is what we use in this thesis. By applying a public license to a work, provided that the licensees obey the terms and conditions of the license, copyright holders give permission for others to copy or change their work in ways that would otherwise infringe copyright law.

% define public software license
In this thesis we refer public software licenses as such public licenses that apply to software source code and the like. An example of the latter are fonts which are considered to be software and thus public software licenses can be applied to them. The public license types provided by the GNU Project \citep{gnu:licenselist} and listed in \hyperref[table:non-software-licenses]{Table 1.1} are outside the scope when we use the term ''public software license'' in this thesis.
\begin{table}[t]
  \begin{center}
    \begin{tabular}{ |m{25em}| } 
      \hline
      public licenses in documentation for example architecture documentation of a project that may or may not be software or even publicly licensed \\
      \hline
      public licenses in artistic works for example digital art, music or videos \\
      \hline
      public licenses in educational works \\
      \hline
      public licenses in viewpoints \\
      \hline
      public licenses in physical objects \\
      \hline
      public licenses in other works \\
      \hline
    \end{tabular}
  \caption{Scope of public non-software licenses}
  \label{table:non-software-licenses}
  \end{center}
\end{table}

% explain copyleft
Another example of term inconsistency is the term ''copyleft'',which is defined by \citet{mustonen2003} in the following way:
\begin{quote}
	''Copyleft is a novel licensing scheme. It facilitates open and decentralized software development. Its key feature is that once a program is licensed by the inventor, the subsequent programs based on the original must also be licensed similarly.''
\end{quote}
Like with the definition of sustainability \citep{weak-sustainability}, copyleft also has the definitions of weak and strong within the term \citep{wikipedia:copyleft}. Weak copyleft licenses are often used to cover software libraries. This allows other software to link to the library and be redistributed without the requirement for the linking software to also be licensed under the same terms. Strong copyleft shares the same features \cite{mustonen2003} presents regardless of the library nature of a piece of software. The general use of the term ''copyleft'' without the prefix also leads to inconsistency in the term usage.

% free vs open
In this thesis we will use the following definitions for open source and free software. Open source is defined as any software source code that is licensed under a public software license that the Open Source Initiative (OSI) has approved as ''open source''. Free software is software that has source code licensed under a public software license that the Free Software Foundation (FSF) has approved as ''free software''. Since the most recognized public licenses in software engineering are either open-source licenses or free software licenses, let us explore further the differences and similarities between open source and free software at the software engineering level of public licenses. This is a crucial step since majority of public software licenses are either open source, free software or both. We glanced over the free software definition in the beginning of \hyperref[intro]{Chapter 1}. Open Source Initiative defines open-source licenses in the Open Source Definition briefly in the following way \citep{osi:licenselist}:
\begin{quote}
	''Open source licenses are licenses that comply with the Open Source Definition - in brief, they allow software to be freely used, modified, and shared.''
\end{quote}
Like the FSF with free software, OSI has the final word on what passes as open source and what does not. For example a new public software license will not classify as free software nor open source until the corresponding organization has acknowledged the public software license as either free software, open source or neither. If a public software license is accepted by both FSF and OSI, in this thesis it will fall under the term FLOSS. It is possible for an organizatin like the OSI or the FSF to accept a public software license, ignore it or actively reject it at any given point in history. In general the strong copyleft free software license requirements are considered more strict than the open source license requirements. For the sake of perspective and the viewpoint present in \hyperref[discussion]{Chapter 4} we could simplify the differences like so: free software requires the redistributions of the licensed software to be open as well but open source licenses do not usually require this. The terms free software and open source are in general often misunderstood or just thought of as FLOSS collectively because the terms have a hard time conveying their paradigms in the natural language. A common mistake in understanding these two paradigms is that free software means software free of charge or that open source means that we can see the source code. We will glance over the impacts on the industry of these two terms in \hyperref[discussion]{Chapter 4}. For example The Open Source Initiative (OSI) classifies \texttt{GPL-3.0} under the term ''open source'' whereas the Free Software Foundation (FSF) classifies \texttt{GPL-3.0} under the term ''free software'' (\cite{osi:gplv3}; \cite{rms:opensource}). Some parts of the two definitions are mutually exclusive. This thesis will not use the terms free software and open source interchangeably.

\section{Lack of license knowledge}
% problem
Understanding public software licenses can be difficult. This could stem from the legal nature of the license texts and the large number of already-existing public software licenses. The license texts usually favors correctedness over the readability for the developer. This is because the license text has to act as a valid legal instrument otherwise it cannot be endorsed \citep{ferguson2006gpl}. The lack of understanding of public software licenses leaves too much room for interpretation. In 2023 IBM's Red Hat seemingly violated the spirit of a popular public software license, the GNU General Public License version 2 (\texttt{GPL-2.0}) \citep{ibm:rhel, sfc:rhel}. This was an unpleasant surprise to the public. If the public software licenses would be more easily understood, the proprietarization of Red Hat Enterprise Linux (RHEL) would have been less of a surprise to the users. To give some context on the violation of the spirit of the \texttt{GPL-2.0}, the project behind GNU General Public License (\texttt{GPL}), GNU Project initially attempted to ensure the users via the GPL have to the following three freedoms \citep{gnu:free}:
\begin{itemize}
	\item Freedom 1:	The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
	\item Freedom2: The freedom to redistribute copies so you can help others
	\item Freedom 3:	The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
\end{itemize}

% easier sub-problem
On top of the legal details of public software licenses, based on the coverage of the incident we suspect that software engineers in general have a tough time understanding the pragmatic freedoms and restrictions of public licenses used in software engineering. In the instance of the RHEL incident it could have been even lesser of a surprise to software engineers if they would have known about other public software licenses. In the example of RHEL This knowledge could have inspired the industry and the academic to seek answers to why \texttt{GPL-2.0} has been succeeded by GNU General Public License version 3 (\texttt{GPL-3.0}) in the first place.

% legal aspect scope
As significant point of clarification, it is essential to acknowledge that public licenses are generally meant to be used as valid legal instruments. The question whether or not a public license can act as a legal instrument is critical to the main function of these licenses. However, this thesis will not focus on the legal doctrine aspects either. The enforceability of public licenses has seen discussion in the academic field of law since the dawn of these licenses and since there's already an academic base for research it is likely the discussion seems to continue on with a healthy amount of activity \citep{duisburg2011gpl}.

\section{Thesis goal and contributions}
% primary object of this research
The primary goal is to have an understanding on how to retrieve all public licenses in software engineering by conducting a multivocal literature review. The research aims to provide a novel perspective on relevant licenses and to extract key findings through a rigorous literature review process.

% thesis contribution
The target audience of this thesis' contributions is twofold. The first major contribution is to provide a rigorous multivocal research on public software licenses to the academic field. Because this thesis already does the multivocal work on public licenses in software engineering, the researches of the future can cite the results of this thesis without having to mark their study a multivocal one. The second main contribution is to provide insights and general metrics to the professional field of software engineering on public software licenses. Hopefully this makes conversation on public licenses in software engineering easier.

\section{Thesis structure}
% thesis structure
\hyperref[intro]{Chapter 1} introduces the problem, this thesis' contributions and some further background. We state definitions and terminology used in the scope of this thesis. We go over the reasons why there does not exist consistent terminology in this area. \hyperref[methods]{Chapter 2} goes over the process and the methods of the multivocal literature review. This is where most of the actual research takes place in. \hyperref[results]{Chapter 3} presents results to the research questions. \hyperref[discussion]{Chapter 4} discusses implications for research. We include our own suggestions and basic knowledge for professionals and academics in the industry to enhance the understanding of public licenses in software engineering. The chapter also discusses software engineering professionals in the thesis' context and the validity of the thesis' research. \hyperref[conclusions]{Chapter 5} concludes this thesis with the help of the research questions and the future of the research.