Refactoring CICD for GitLab and licensing question #27829
Unanswered
timothystone
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm undertaking a refactoring of the GitLab templates in the
ci-cd
subgenerator. As part of this refactoring, I'm considering using the excellent work of the To Be Continuous (TBC) project, TBC is "a set of GitLab CI templates developed and maintained by DevOps and technology experts to build state-of-the-art CI/CD pipelines in minutes." The TBC templates were recently made available to the GitLab CI/CD Catalog.I'm a contributor to TBC, having written the Maven Jib template variant—to support our enterprise use of JHipster!—and besides seeing some overdue updates needed in the
ci-cd
subgenerator as a whole, i.e., should Artifactory really be the default in the sub generator, when all that is being set in thedistributionManagement:url
? If it's a GitLab choice, default to GitLab registries—which is the TBC default behavior by design—and provide documentation for using Artifactory, Nexus, Archiva (Apache), &etc.The question I have is how JHipster is licensed vs. TBC. TBC is licensed with the LGPL. Before we pick up our torches and wander into the rabbit hole of "viral-ness" I want to see if there is a general consensus that using TBC as licensed is not a show-stopper.
I have had informal (non-retainer) conversations with an IP-in-IT lawyer friend (we're actually quite close as he is my gamemaster in a multi-year RPG campaign). He advises that following the LGPL §4 Combined Works I should include the LGPL license file and note the use of LGPL code in the generator file and that the refactored code would have a boundary on the "viral-ness" to the GitLab template of the generator. TBC is agnostic across the board on all things if only taking a GitLab-first approach.
Beta Was this translation helpful? Give feedback.
All reactions