search

GoogleCloudPlatform / cloud-sql-jdbc-socket-factory

A collection of Java libraries for connecting securely to Cloud SQL
Apache License 2.0
234 stars 119 forks source link

One transitive dependency, `jnr-posix`, uses 3 licenses, and 2 are "problematic" for business purposes #2082

Open detro opened 4 days ago

detro commented 4 days ago

Bug Description

We use Snyk to restrict the allowed licenses across the company, and to ensure we don't accidentally include "undesired" licenses.

I'm planning to start using this library to connect internal Java services to GCP Cloud SQL PostgreSQL, and I got an issue report because a transitive dependency, jnr-posix, uses multiple licenses:

com.github.jnr:jnr-posix Multiple licenses: EPL-1.0, GPL-2.0, LGPL-2.1

As a lot of businesses will likely have the same issue, I was wondering if you have a strategy to replace or limit this.

I'm currently experimenting with explicitly force Maven not to download jnr-posix. But I don't know if that is going to entirely brake the Socket Factory or not.

Example code (or command)

No response

Stacktrace

No response

Steps to reproduce?

  1. Setup tool to enforce/limit the usable licenses of dependencies, and mark GPL-2.0, LGPL-2.1 as disallowed
  2. Include library: 
    <dependency>
<groupId>com.google.cloud.sql</groupId>
<artifactId>postgres-socket-factory</artifactId>
<version>1.21.0</version>
</dependency>
  3. Confirm issue

Example tool: https://snyk.io/product/open-source-security-management/license-compliance/

Environment

  1. OS type and version: any
  2. Java SDK version: any
  3. Cloud SQL Java Socket Factory version: 1.21.0

Additional Details

No response

jackwotherspoon commented 3 days ago

@detro Thanks for opening an issue on the Java Connector 😄

I am not sure this is worthy of being a type: bug label... I wonder if this more of a bug for Snyk? I would assume that a distribution with multiple licenses would default to the one with the least sensitive or restrictive permissions... is this what you would expect?

I say this because jnr-posix says you can use any of the licenses...

This is also probably somewhat related to #1921 as it touches our dependency graph.

I'll chat with the team about removing the dependency on this lib but as you said its transitive which makes me think this should not be a bug on the Java Connector.

detro commented 3 days ago

@jackwotherspoon Hello!

I was indeed conflicted: this should probably not be a "bug", but when I opened the issue all the other presets didn't seem to fit either. So I'm ok with the retagging of course.

In terms of this being actually a Snyk's issue, I'm able to work around it, but telling the scanner to ignore the issue.

What I'm really trying to convey here is that a library like this one, is very likely to be used by businesses that depend on GCP. And it's unlikely that they are OK with anything but EPL of the 3. At first adoption, if they have a scanner for license usage (and they should!), they are going to hit this (unless GPL licenses are somehow allowed in those businesses 🤷).

So, for this library, it could create unnecessary friction.

I totally understand if you think it's circumventable by telling your own scanner, but I thought I'd raise this.

PS I left Google in March, so consider this a "professional hug" for my ex-colleagues :)

jackwotherspoon commented 2 days ago

Thanks @detro

In terms of this being actually a Snyk's issue, I'm able to work around it, but telling the scanner to ignore the issue.

I was more meaning should Snyk scanners have a flag to enable taking the least restrictive license for software that has a "choice-of-license" model, like this dependency does? You shouldn't have to tell Snyk to ignore the issue, you should be able to choose the EPL license and the Snyk scanner should be happy. Seems like a good feature request... what do you think?

And it's unlikely that they are OK with anything but EPL of the 3. At first adoption, if they have a scanner for license usage.

This is fair, and to be honest the dependency causing this issue is not one that the default usage path of this library even hits/uses. It is used when a unix socket is required for use with the Cloud SQL Proxy.

So it may be worth us looking at branching it off into its own artifact so that the default usage path of this library is in the clear by scanners.

jackwotherspoon commented 2 days ago

@hessjcg we should discuss if we can branch off the Proxy usage required deps to a separate artifact or JAR maybe?