Keeping track of Software Licenses for third-party code on our packages
Closed this issue · 7 comments
Package
N/A
Description
In some cases, we may prefer to have code from third-party libraries copied over to our repos rather than have them as dependencies of our packages (see example here).
We must respect licensing when using such code, so it would be useful to keep track of licenses used in our projects.
What would be an ideal way to keep track of all them? For starters, the information that would be required is as follows:
- package where we're using some third-party code
- license that third-party code is under
Github's documentation on licensing repos:
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository
Other questions that come to my mind as of now:
- is there any license or type of license we should avoid?
Steps to Reproduce
N/A
Expected behavior: N/A
Actual behavior: N/A
Reproduces how often: (only for bugs) N/A
Additional Information
This discussion was brought up by @oegea on this PR https://github.com/SUI-Components/sui/pull/1528/files#r1009160711 and we believe that the best course of action is to reach an agreement and define a convention for our projects.
IMHO having a list containing a relation between dependencies and used software and their licenses and restrictions could be good. As some licenses enforce to include a manual notice in the project, maybe it's better to include it in a centralized file.
As said by Jordi, this could be a great opportunity to make a list of licenses we should avoid to avoid incompatibilities between them.
i.e. Using an GPL or AGPL licensed third-party lib or software, could result in the requirement of adopting that license as ours in the entire project. This could be fine as soon as we already have in mind to be compatible with those licenses or to adopt them, but if we are seeking to use a simpler license (like the MIT license), it could be a problem and could force us to adopt a non-wanted license.
I have standardised all packages with MIT license here.
It is difficult to have a track of the licences of all the 3rd party packages we are using, and I don't know if there is a way to keep a register of this...
I have standardised all packages with MIT license here. It is difficult to have a track of the licences of all the 3rd party packages we are using, and I don't know if there is a way to keep a register of this...
It wouldn't really be about all third-party packages we're using but rather third-party code we may decide to import to our repo and keep maintaining ourselves for whatever reason... @arnau-rius does it make sense to you?
I have standardised all packages with MIT license here. It is difficult to have a track of the licences of all the 3rd party packages we are using, and I don't know if there is a way to keep a register of this...
It wouldn't really be about all third-party packages we're using but rather third-party code we may decide to import to our repo and keep maintaining ourselves for whatever reason... @arnau-rius does it make sense to you?
Do we need to keep track of the license of a piece of code we 'forked' or 'imported' in our codebase?
I have standardised all packages with MIT license here. It is difficult to have a track of the licences of all the 3rd party packages we are using, and I don't know if there is a way to keep a register of this...
It wouldn't really be about all third-party packages we're using but rather third-party code we may decide to import to our repo and keep maintaining ourselves for whatever reason... @arnau-rius does it make sense to you?
Do we need to keep track of the license of a piece of code we 'forked' or 'imported' in our codebase?
I believe so, especially for pieces of code from projects with non-permissive licenses. We may want to seek some legal advice to confirm this.
I don't have any idea / suggestion on how to do it.
So maybe you can make some research and make a proposal...
Example: keeping a LICENSE.md containing the original license of the imported 3rd party package.
What do you think?
I don't have any idea / suggestion on how to do it. So maybe you can make some research and make a proposal... Example: keeping a
LICENSE.mdcontaining the original license of the imported 3rd party package. What do you think?
I'm not really sure if keeping the entire original license is strictly necessary. It will probably depend on what we are required to comply by the license used by the third-party dependency. Maybe just keeping a file with a set of textual notices will be enough for most cases, and relating each notice with its related package could be useful for maintenance purposes.
i.e. I've seen that some systems offer a section in which they list open source libs used on it, and licenses under which these libs have been released. I'm not sure if we could achieve something similar within our repository, as a markdown file or something similar, or maybe we could find examples in other open source repositories. The idea is not to track all third-party licenses used by our dependencies, but just include notices required by some specific third-party dependencies (like the one found by Jordi when requiring a new dependency).
IMHO The other thing could be interesting to discuss, is if we should avoid requiring third-party software licensed under some specific terms.
i.e. GPL, AGPL, and similar licenses enforce to adopt them on derivative work. And these licenses could be more restrictive than MIT license. Additionally they could be incompatible with other inherited licenses or third-party clauses, so from the "legal" perspective could be an interesting thing to know if we should avoid using any of them.
Maybe as @jordevo said, we could ask for legal advice related to this.
BTW, I'm just giving my opinion as per things I've heard and seen, but expect some kind of error on this comment as I do not have a huge background on this field 😓 .