lucasgonze/attribution compliance.md Secret

## attribution compliance.md

      
    Raw
  

              attribution compliance.md
            
          
    This document is a record of a conversation on how to do open source attribution.
Lucas Gonze
Are there conventions for attributing third party open source code that requires attribution? I have seen a variety of ad hoc solutions. 
For example, New Relic encourages a file named THIRD_PARTY_NOTICES.md in the root of a repo, such as https://github.com/newrelic/node-newrelic/blob/main/THIRD_PARTY_NOTICES.md. That contains a listing of components requiring attribution and inline license statements to satisfy requirements for licenses to be distributed.
In another case, there is a NOTICE.md file in the root that contains roughly the same information.
How do you approach it? What is your ideal?

KPF said:
if you're taking about vendored (copied) third-party code in the source code repo, there's no need for any attribution since the source code is there and should contain its original copyright and attribution notices.
if you're talking about assisting third parties who will later distribute binaries or other derived content from the repo, without distributing the source code, that's more complicated because if you provide inaccurate or incomplete information and that third party relies on it, they could still be held liable for infringement if such is found. as an enterprise consumer i would never have used an intermediary's conclusions as to what my obligations were unless i had paid them for their advice and they provided me with indemnity.

Lucas Gonze:
So your approach is that (1) an untouched original copy is guaranteed to be at least as good as the original and (2) anything that isn’t an untouched original copy is useless.
In that case the optimal approach is to vendor everything.
And the compliance work when validating a corporate OSS project is to make sure that all sources are complete.
How do you do attribution on work that is copied and pasted, like from Stack Overflow?

SK:
Our approach is to have a LICENSE file that contains the license for our code, and a NOTICE file for the licenses and attributions of any third-party content that we include in the repo.
KPF:
Lucas: as i mentioned above, all code in the repo which originated from third parites should have its own copyright/license notices, so code copied from Stack Overflow should be marked that way. what I would not rely on is any sort of 'summary of obligations' provided by the repo owners, unless my company has a business relationship with those owners and can rely on them to provide a backstop to me if their 'summary of obligations' turns out to be incorrect and i'm sued for infringement of some obligation they failed to include in their summary.
if the NOTICE file is incomplete or inaccruate, and you rely solely on it when redistributing the code, you're accepting liability for the work done by the repo owners to populate that NOTICE file.
in the end this is all a risk-management issue of course; your tolerance for risk, the amount of code with attribution obligations, the way you are distributing it, etc. in my opinion the simplest solution is to just always ship the source code, which then meets all possible attribution obligations.

In a separate email chain with a different expert, ML, I asked:
Do you have a few minutes at some point to give informal advice on how to comply with attribution requirements? I have seen two approaches:


Programmatically generating something like https://github.com/newrelic/node-newrelic/blob/main/THIRD_PARTY_NOTICES.md


Vendoring third-party dependencies in exactly the version used, with licenses and NOTICE files intact. (With some version of the first approach for packageless sources like Stack Exchange).


ML replied:
It depends? For typical repo, neither as dependencies are by reference. I guess the new relic notices files may be included with some artifact. That's typical, most prominently in things like chrome://credits. 2 only works if your distributed artifact will include source, but if that's the case seems reasonable.
Summarizing:
SK's approach is in line with the New Relic guideline. I have seen that same approach at a third company as well. I have taken this same approach in the past.
KPF’s idea is elegant: pass along whatever the rights holders provided. Then it’s their responsibility to declare the license and attribution properly. It’s interesting that his approach completely disavows the value to recipients of notice and license files from any source but the original creator.
I recently read through licenses and attribution files for quite a few projects. They were an unbelievable mess. It was often hard to make a simple statement about the license or the attribution. Including the original source code and any licenses or attributions included is a way to avoid that problem.
The third person who commented, the one who did it offline, took the position that you should almost always avoid redistributing code. Let the package manager do the work. This sidesteps the issue in many ways.
I came to this conversation with the same perspective as Stephen, but came away impressed with the other two arguments. In the future I think I’ll use this prioritized approach:

Avoid vendoring code. Don’t do notices or licenses for non-vendored code.
If you must vendor code, include the original package verbatim, with licenses and attributions intact.
Have a LICENSE file that contains the license for original code, and a NOTICE file for the licenses and attributions of any third-party content.