Occurrences of GPL boiled down to: * libs that supports GPL and something else, as in "MIT and GPL" * "GPL" strings in repo as in "... this license is 100% compatible with GPL ...", in other instances, it could catch a copy/pasted function with a GPL annotation in the code/docstring * dev dependencies, things like sphinx (to build our docs), or pylint, a linter, that doesn't ship or installs with the package
Also FOSSA did a good job of showing missing/dubious licenses, flagging files or function that have license text in them, and showing where that dependency (sometimes many nodes deep) fits in the tree. It also is good at whitelisting and adding notes / context. I looked into fossology a little, and it's unclear whether they offer a Github-centric service with webhooks and all. It may require adding a check in CI, which seems less desirable for our use case. More generally, 3rd party Github services are becoming more and more compelling and it's been empowering to use them, from things like probot, codecov, travis, simon, requires.io, just to name a few, and clearly has a place in high-velocity open source development. I'd love if we didn't have to open ASF-INFRA tickets to set and tune those up. Fundamentally this would probably require for the ASF to allow project to use their own Github orgs & repos, where they can be admins. Linux Foundation allows for that for example, so this may do doable. This is probably controversial, and I'm guessing that's been discussed here before... Max On Tue, Jul 9, 2019 at 10:35 AM Ted Dunning <ted.dunn...@gmail.com> wrote: > License scans like this are great, particularly for software that will > eventually be scanned by some commercial user anyway. Hopefully most > projects are simpler than Superset, though. > > Looking at the scan results, however, immediately raises the question about > all the GPL licenses turned up in the scan. Is the Superset project aware > of those dependencies? > > > > On Mon, Jul 8, 2019 at 11:30 PM Maxime Beauchemin < > maximebeauche...@gmail.com> wrote: > > > Hi all, > > > > [this is not a promotional email in any way, I'm not affiliated with the > > service/company discussed here] > > > > I just discovered fossa.com, self described as "Realtime license and > > vulnerability management > > for open source dependencies". > > > > For context, Apache Superset has a dependency tree rich of 700+ deps > (crazy > > right?), at that scale license management is huge burden at best, or > worse: > > a legal risk for the ASF. > > > > Oh btw I tried searching the ASF mailing lists for existing threads on > this > > topic but failed miserably, apologies if this has been discussed already. > > > > I couldn't set up the FOSSA service on the projects repo I'm PMC on as I > > don't have the required Github rights, but I set it up against my fork > and > > it's all you could ever hope for in terms of license-related automation. > > See it in action here: > > > > > https://app.fossa.com/projects/git%2Bgithub.com%2Fmistercrunch%2Fsuperset/refs/branch/master/396a655de13ced6e25f4e793b0eb281bf4f4cd79/issues/licensing?status=resolved > > > > It seems like we may want to set this up against most if not all ASF > > projects. As the ASF is in the line of fire for legal troubles around > > licensing, it seems like automation/prevention would be strategic, > > especially in a world where micro packages and frequent releases are > > trending. Without using a service like this one, bumping a release, or > even > > just allowing an open version range can result in integrating > > non-permissive licenses in a bundle, in ways that could take months to > > catch, if ever. > > > > For the record I opened a ticket with ASF infra to set it up on > > `apache/incubator-superset`: > > https://issues.apache.org/jira/browse/INFRA-18719 I'm hoping this goes > > smoothly, and that Apache Infra is ok granting the required perms to > FOSSA. > > > > I wanted to bring the attention to this as this seems like something very > > useful for most projects. > > > > Thoughts? > > > > Max > > >
