[BuildStream] BuildStream license compliance: taking steps further

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi,

I have been checking the headers of BuildStream files. I think there is some extra effort we can do to 
improve the current state of Buildstream compliance with the license.

## Why should we put effort in the compliance field?

1.- Compliance is a hygiene factor. It does not shine but it is definitely a problem when it is not there.
2.- Every atom of effort we put on compliance upstream is time and money we save downstream, specially in 
commercial environments.
3.- License compliance is an important (negative) factor for more and more decision makers in commercial 
environments when it comes to choosing a tool/technology.
4.- It says more than we might think about the professionals and stakeholders behind the project to more and 
more people.

## What to do?

I suggest to focus some energy in the following areas for now:

A.- Analyze our current situation. There is tooling to do this. Check below.

  * Run the reuse program (check below) and publish the results.
  * Evaluate the examples and define a standard license file, file header and bill of materials.  

B.- Add/Modify the information required to comply today following the Reuse Initiative best practices. See 
links below.

There are three basic areas of work:

   * The license file. Please consider this point as per repository when they can be consumed independently.
   * The file headers. Please consider code, documentation and tests files.
   * The bills of materials. In our case this point might be related with our plugin strategy and Buildbox. 

C.- Define a policy that should be followed to keep over time the standards set in the previous step.

 * We should publish it as any other policy.
 * We should make a reference to the best practices we are following on the website (community) targeting 
decision makers and compliance experts.
 * It would be ideal to point to examples in the technical documentation so newcomers that are not familiar 
with these best practices can follow them.

E.- Define a mechanism that ensure that whatever file we add or modify, it follows the compliance policies 
previously defined.

 * I suggest to create a test stage prior to our current "prepare" stage where compliance tests are run to 
identify if the header has been correctly added when a new file is submitted or that the headers has been 
properly modified when an existing file is modified.
   * The idea to create a new "initial stage" is to save compute time when the homework is not done. We can 
use this stage for further future static analysis/tests.
 * Treat the Bills of Materials as an artifact that is re-created with every commit and tests it has been 
done correctly.
   * We need to define how we can include plugins in the Bills of Materials.

F.- Stay up to date with new best practices in the area of software compliance since it is a field that is 
receiving a lot of attention nowadays.

   * We need to consider that in the case of SPDX or the bill of materials, there has been some 
improvement/changes the last couple of years. This field is receiving a lot attention lately so most likely 
we will need to adapt to further changes in the current best practices and recommendations.

## Best practices and tools

I recommend at this stage to follow the recommendation from the Free Software Foundation Europe[1] (FSFE) 
summarise in the Reuse initiative[2]. The following resources are of interest:

* Description of how the header should look like (best practices).[3].
   * I have included a .pdf version of the Best Practices document in our repository (version 2)[4] so you 
can download it and use it offline.

* The tool "reuse"[5] will help us to analyze our current state (step A.)

* Examples:
   * Repo that automatically generate a bill of materials after each commit[6].
   * Repo which is REUSE compliant.[7]

## Final remark

Compliance should be taken as a process. The above steps will put us in a better position but it will require 
to include the associated practices as any other development and delivery practice in order to keep and 
improve the current state. So I recommend to consider compliance as a something that happens in master not 
just in releases. Additional measures can be taken for releases but we can focus on them once the above are 
implemented and we feel comfortable enough.

On an aside note, based on the number of contributors we have (check the metrics study) I recommend also to 
consider the need of have a Certificate of Origin[8] (CoO) from every contributors or a measure in that 
direction[9]. These kind of measure are easier to implement earlier in the life cycle of a project.

[1] http://www.fsfe.org
[2] https://reuse.software/
[3] https://reuse.software/practices/2.0/
[4] 
https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/compliance/best_practices_publishing_code_licenses_reuse_initiative.pdf
[5] https://gitlab.com/reuse/reuse/tree/master
[6] https://git.fsfe.org/reuse/spdx-hello
[7] https://git.fsfe.org/jonas/curl/src/branch/reuse-compliant
[8] https://elinux.org/Developer_Certificate_Of_Origin
[9] https://fsfe.org/activities/ftf/fla.en.html

Best regards
-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html