I like the idea of a plugin repository too. Some plugins will be part of Hop, and others will be external and merely referenced from a “marketplace”.
In case anyone is thinking of creating a ‘hop-plugins’ Git repo that’s outside of Apache, let’s not go there. If the plugins are managed by the Hop PMC (e.g. if Hop does the releases) then it is Apache code. A separate Git repo within Apache is fine, though. Many projects do that. Now, regarding the original question, importing source code. Apache requires that a "substantial contribution that was not developed within the ASF's source control system and on our public mailing lists” goes through IP clearance. This policy applies to incubator and top-level projects alike, and is similar to the clearance process that we went though at the start of incubation. We need to follow that policy. No doubt you are wondering: what is “substantial”? Have a look at the table in [1] to see what other projects have done. Julian [1] https://incubator.apache.org/ip-clearance/ > On Jun 24, 2021, at 8:37 AM, Brandon Jackson <[email protected]> wrote: > > I like Bart's idea of separating the repositories completely having an > apache-hop-plugins repository along side the separate repository for things > that may not be compatible from a license standpoint. > > Since there are no autobuilds or packages sitting around of these other > plugins, I think it makes it very difficult to discover and put the plugins > to use. Matt's idea of a marketplace of sorts would be nice. > I liked the marketplace from prior times, even if it was built off an XML > submission. It was something usable. > > Brandon > > > On Thu, Jun 24, 2021 at 2:45 AM Bart Maertens <[email protected]> wrote: > >> Hi All, >> >>>>> - Neo4j: The Neo4j Output plugins. I do believe that Bart Maertens >> wrote >>>>> the original version of that code so if he agrees to donate that code >> we're >>>>> fine there. >> There's probably no original code left, but absolutely fine by me >> >> Agreed on the process to let new plugins move through the hop-plugins >> repository. We could use that repository as some sort of internal >> incubating repository, where plugins have to mature before they are >> accepted in the incubator-hop repository. >> >> We may need to think of a way to separate incubator-hop candidate plugins >> from plugins that can never make it into Apache Hop because of license or >> dependency incompatibilities (which is currently the case for all plugins >> in the repository). That is not an issue at the moment, but may get harder >> once the number of external plugins starts to grow. >> One option could be to keep the current hop-plugins repository for >> incompatible plugins and create an additional >> apache-hop-plugins repository. >> >> Regards, >> Bart >> >> On Wed, Jun 23, 2021 at 6:48 PM Matt Casters <[email protected] >> .invalid> >> wrote: >> >>> Hello Devel-hoppers, >>> >>> Over the course of the last couple of months we've imported some >> additional >>> 3rd party source code. >>> As was mentioned earlier during release voting we need to do a better job >>> of making sure that we have permission to donate said code to Apache. >>> For everything related to my own code and the Neo4j plugins I can be >> formal >>> the following are donated: >>> - Code we imported: kettle-beam, pentaho-pdi-dataset, >> kettle-debug-plugin, >>> kettle-needful-things, kettle-environment, kettle-splunk, kettle-kafka >>> - Neo4j: The Neo4j Output plugins. I do believe that Bart Maertens wrote >>> the original version of that code so if he agrees to donate that code >> we're >>> fine there. >>> >>> Obviously for as far as myself is concerned: everything I added to the >>> incubator-hop source code is also covered by my ICLA and a number of >>> sources were mentioned in the incubation proposal. >>> I'm just trying to be complete since apparently I've been a proficient >>> coder lately :-) >>> >>> Recently we removed some old SQL parser code (good riddance). >>> >>> Since everything in Hop is a plugin anyway I suggest that if we're even a >>> little bit uncertain about the origin of the plugin source code (apart >> from >>> the original source code import/rewrite) that we simply move it out into >>> the external plugins <https://github.com/project-hop/hop-plugins> until >> we >>> have clear permission of the original authors to use the code. Going >>> forward I suggest we do the opposite. Let's add code to the external >>> plugins project first and only then incorporate it into incubator-hop >> when >>> we have a more formal permission to donate the code to the ASF. >>> >>> I believe that the list of debatable plugins is this: >>> - MQTT input/output (originally from Hitachi) >>> - Google Sheets (informal permission received from JF Monteil, need to >>> formalize) >>> - Google Analytics (originally from Hitachi) >>> - Dropbox (permission needed from L. Coelho) >>> >>> The other new plugins were written from scratch and are fine I believe. >>> >>> Personally I think it's just not worth it to even have these discussions >>> for a couple of obscure plugins so I would suggest moving this code out >> of >>> our way until we have clear SGAs for these plugins. >>> >>> Let me know what your thoughts are! Perhaps if we have more external >>> plugins it forces us to build a software marketplace at some point. >>> >>> Question for our mentors: in what forms do these agreements need to come? >>> Where are they stored and how are they communicated? >>> >>> Cheers, >>> Matt >>> -- >>> Neo4j Chief Solutions Architect >>> *✉ *[email protected] >>> >>
