Hi all, I was one of the person that initially brought up this topic to GitLab's Legal counsel. To put it simply, we decided to decouple the Meltano codebase and the Singer components with a plugin system so that the Meltano codebase cannot be treated as "derivative work" of the Singer components. Any work done on a Singer component would have to be public and shared with the extended community.

Hi @micael_bergeron 👋 , in that scenario, are the Singer components taps and targets? The separation being that tap/target code is not in the same repo as meltano? It looks like SingerPlugin invokes the taps using a subprocess. Which is what most orchestrators do.

in that scenario, are the Singer components taps and targets?

Yes.

The separation being that tap/target code is not in the same repo as meltano?

Yes; thus, if a user clones or install Meltano there is no Singer code in the codebase.

It looks like SingerPlugin invokes the taps using a subprocess. Which is what most orchestrators do.

Yes. I've seen other use a Docker image but it is the same underlying idea.

@micael_bergeron Hmmm, if wonder if provideding a Dockerfile or Docker image with taps/targets preinstalled, or having the Dockerfile in the repo would be an issue.

Providing a Dockerfile no, but providing docker images yes.

@micael_bergeron Wouldn’t the docker image contain GPL code? Eg linux / linux programs etc.

Docker basically opened a pandora's box for copyleft licenses.

Mhmm