Re: [BuildStream] BuildStream license compliance: taking steps further

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

Hi,

On Wednesday, 19 December 2018 15:58:39 WET Paul Sherwood wrote:
> Hi Agustin,
> please see my comments inline...
>
> On 2018-12-18 11:20, Agustín Benito Bethencourt via BuildStream-list 
> wrote:
> > 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.
>
> While I appreciate that world and dog are taking increasing interest in 
> this (not least as a result  of OpenChain and other initiatives), I 
> personally think that BST licensing is in a mess (wrong license was 
> chosen originally) and we'd be better placed trying to unravel that 
> before expending effort on compliance.

Since I assume that you are talking about a difference Open Source license, what I propose would work too.

Obviously sorting out the license before complying to it is the right thing to do.

> > ## 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.
>
> I'd be interested to hear how you justify this claim. bst is primarily 
> tooling for construction of software - downstream would not normally 
> distribute bst, so it's not clear to me what time/costs you're referring 
> to?

Let me explain it with a simple (so inaccurate) example.

If as downstream you include in one of your products a FOSS file without the proper header, for instance, a 
license scan tool will reflect it as a positive.

In order to clear out that positive, you will have to act manually the first time, checking upstream-level-1 
project to find out what is the license of the file.

If the software was done by that upstream-level-1 project, then it might be a easy enough step. But it was 
developed by upstream-level-0 project, then it might not be such an easy task.

Once you know the license of the file and have cleared up the positive in the license checking tool, in order 
to ensure you do not have a false positive again when you update the file or when a different version of the 
file is consumed, you will have to either:
a.- Create a script that adds the right header to the file in your mirror repo so when the file gets updated 
your scanning tool treat it as a known license.
b.- Request upstream to add the right header to the file (even better is to help them).

All the above mean costs. The ideal situation would be that one in which there are no positives for 
"missing/unknown information" about the licenses. 

> > 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.
>
> There are other, arguably more important factors. Not sure why you're 
> flagging this one specifically.

In my experience, more and more, corporations are understanding the responsibilities and risks associated to 
distributing Open Source software.  Those risks are perceived as higher when it is hard to find who did the 
(upstream) software, when or under which license, specially in complex/long supply chains. 

> > 4.- It says more than we might think about the professionals and
> > stakeholders behind the project to more and more people.
>
> I represent a stakeholder, and I completely failed to even notice the 
> licensing adopted by the project. That reflects badly on me, obviously, 
> but I don't see how focusing any effort on compliance is going to help 
> in the slightest. i Please enlighten me :-)

I think Ibrahim Haddad[1] nailed it in his book edited in 2016[2] 

"One of the major differences between the proprietary and the multi-source development models has been that 
the licenses of open source software are not negotiated. There are no contracts to sign with the software 
providers (i.e., open source developers or projects). Rather, the individuals who initiate the project chose 
a given open source license, and once a project reaches a certain scale, the licenses are virtually 
impossible to change. When using the multi-source development model, companies must understand the 
implications of tens of different licenses (and combinations of licenses) coming from hundreds or even 
thousands of licensors or contributors (copyright holders). As a result, the risks that companies previously 
managed through company-to-company license and agreement negotiations are now managed through robust 
compliance programs and careful engineering practices."

Serving as example in those "careful engineering practices" is right approach to me to face the 
responsibility I have as a professional in this business . I understand this position is harder than being a 
follower. And yes, we are not consistent with our own beliefs every time. I am not so I do not expect anybody 
to be. I just would like to see BuildStream taking this topic as one of those in which we are perceived as 
"better than the average". This is the reasoning behind my proposal.

[1] https://www.linkedin.com/in/ibrahimhaddad/
[2] https://www2.thelinuxfoundation.org/open-source-compliance-ebook

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