@douwe_maan I mentioned we were clean-rooming cookiecutter templates with Meltano specifics and friendlier licenses. Those are available here: https://github.com/Qualytics/extractor-template and https://github.com/Qualytics/loader-template. Not much to them really - very similar to the Singer counterparts but might make it easier on users to point to these template repos instead of the Singer ones in Meltano tutorials & such. They use the terms “extractor” and “loader” which provides some clarity.

@eric_simmerman Awesome! I just filed https://gitlab.com/meltano/meltano/-/issues/2447 yesterday, which these would be perfect for

I’m not the author but the intent was to produce cookie cutter templates without referencing the Singer templates but instead referencing MIT licensed source (Meltano itself & existing extractors/loaders). It’s certainly possible that spirit was violated - but also so much out there that’s self-referential it’s tough to know where a concept was borrowed. These projects are so simple - we can easily wipe clean and redo - but can you point to an extractor and a loader that are properly MIT licensed that I can point a developer to for guidance in the effort?

I appreciate the effort and agree that it's hard to separate the skeleton/boilerplate set up by the template from the concept of a Singer tap in general, but technically all of those lines of boilerplate in the template repo (together) have the AGPL license, and I wouldn't expect what's effectively a fork (as far as the

__init__.py

code goes at least) to be able to so easily shake the stickiness of the license on conceptual grounds 😄 And I think the same would go for projects derived from that template source, although it could be argued that while the template repo source code may be AGPL, the output of that program doesn't necessarily keep the license, even though the AGPL

LICENSE

file is part of the output

hey hey

@peter_kosztolanyi Aren't licenses fun? 😄 There are only so many ways to use the (Apache 2)

singer-python

library and implement a valid fully-featured Singer tap, so some degree of overlap between taps with different implementation histories is expected even if no code is copied directly. I guess it could be argued, though, that if the Apache 2 PPW taps still contain lines of code that exactly match those in the templates, a claim that these taps should also be AGPL could be valid until those lines are refactored away. Of course, if those line are just

singer-python

import statements or method invocations, or things like

if args.catalog:

, I doubt anyone could (or would try to) argue that simply having those lines in common makes something a derivative of the template. If we believe that it's possible to cut the connection to AGPL at all, I think our best bet is to follow the plan in https://meltano.slack.com/archives/C013Z450LCD/p1605127755020400?thread_ts=1605114925.017600&cid=C013Z450LCD and apply a few extra iterations of refactoring and adding helper methods, until we end up with code looking nothing like the original template repos (and to a lesser extent the PPW taps/targets) that served as their historical inspiration, beyond superficial similarities due to their use of the

singer-python

library.

the funny thing is that the singer-python lib is apache2 - and this is why we safely forked it here -, but the templates are AGPL

Yeah that simplifies things for sure, otherwise we'd need to do a black box reimplementation like we're considering for tap_tester: https://gitlab.com/meltano/meltano/-/issues/2403

I support with two hands to have common tap and targets templates under MIT/Apache2

Agree with the thinking here and our best option. I’ll ask a couple interns working with Qualytics to take a crack at templates based upon the snowflake tap and see where that gets us as a next step.

@eric_simmerman Awesome, thanks!

I'm late to this thread but would be happy to help in this effort. I like the idea of starting with an Apache2 tap and trim it down to a reusable cookiecutter template. I think I'd actually go much further and I would love to develop and iterate on an interface where only a few things need to be overriden. More thoughts here: https://gitlab.com/meltano/meltano/-/issues/2401#note_450317761

The new templates and new framework (singer-python alternative) go hand in hand as far as I'm concerned 🙂 Looking forward to collaborating on it!