You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Uwe Geercken <uw...@web.de> on 2017/02/28 22:47:40 UTC
new Nifi Processors
Hello everyone,
I just wanted to let you know, that I have created four processors for Nifi
1) GenerateData - generates random data (test data) based on word lists, regular expressions or purely random
2) RuleEngine - a ruleengine which allows to process complex business logic. But the logic is maintained in a separate web app and thus outside of the flow. If the logic changes the flow does NOT have to change.
3) SplitToAttribute - splits a single CSV row into flow file attributes
4) MergeTemplate - merges flow file attributes with an Apache Velocity template and writes the result to the flow file content
Please give them a try and let me know your findings and thoughts.
https://github.com/uwegeercken/nifi_processors
rgds,
Uwe
Re: new Nifi Processors
Posted by Uwe Geercken <uw...@web.de>.
Joe,
thanks for your help. You all have been very helpful - it's a joy to work together with you.
As you may or may not know, my main project is the RuleEngine. I started development about 9 years ago (with breaks in between...). So I created a standalone ruleengine in Java which works in any Java application, web apps or Java based script languages. A while ago I wrote a plugin for the Pentaho ETL Tool (called PDI or Kettle). It is available through the Pentaho Marketplace. I have presented the plugin itself and the idea behind it at various events and by now at least two larger companies that I know of are using it.
My latest work was to use the ruleengine in Hadoop mapreduce (you can read about it in my blog) and another candidate I would like to work on is Kafka.
The idea is always the same: Have the business logic outside of the tool or application, so that the IT code or tool is slim and clean. This directly relates to more agile development, easier maintenance and thus higher quality (and less errors). And it promotes the devision of responsibilities: the IT expert for the system and code and the business expert for the business logic/rules.
I hope I can contribute to Nifi in a way that it helps others. I was amazed (really) when I first saw Nifi and quickly came up with the Apache Velocity Template Merge processor. But then I lost a little bit the focus doing other things and I did not really have a use case for Nifi. But now I have started using it again and hope to also introduce it at the company I work for. My goal would be to implement it this year.
Again thanks for the help and I will certainly need more until we have a final version - all the little bits and pieces that need to be observed...
Rgds,
Uwe
> Gesendet: Donnerstag, 02. März 2017 um 22:07 Uhr
> Von: "Joe Witt" <jo...@gmail.com>
> An: users@nifi.apache.org
> Betreff: Re: Re: Re: Re: new Nifi Processors
>
> Uwe
>
> To progress toward a pull request for inclusion in the nifi community
> we will need a LICENSE/NOTICE to end up in the nar bundle itself. You
> can see many examples of this in other nars such as [1]
>
> If you don't need to edit the LICENSE you can not provide it and a
> default one will be provided. Same for NOTICE. The learning curve on
> proper licensing is not pleasant and we're in all the license struggle
> together so we can help get it right.
>
> You're doing some really cool work here. Will be awesome if we can
> work with you to get the things you'd like contributed into formal
> contribution/PR status. Certainly you don't have to do that and can
> instead just publish them outside the nifi community. We're happy to
> help either way.
>
> [1] https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-ignite-bundle/nifi-ignite-nar/src/main/resources/META-INF
>
> Thanks
> Joe
>
> On Thu, Mar 2, 2017 at 3:56 PM, Uwe Geercken <uw...@web.de> wrote:
> > Thanks for all your resposes and help.
> >
> > One last question (at least for the moment ;-) ):
> >
> > Should I place a license file in the nar file? Or is it enough to place it in the code? Any conventions from the Apache side?
> >
> > Rgds,
> >
> > Uwe
> >
> >
> >> Gesendet: Donnerstag, 02. März 2017 um 15:53 Uhr
> >> Von: "Matt Burgess" <ma...@apache.org>
> >> An: users@nifi.apache.org
> >> Betreff: Re: Re: Re: new Nifi Processors
> >>
> >> Uwe,
> >>
> >> If your NAR can be licensed under the Apache Software License 2.0,
> >> then you shouldn't run into any issues with other folks want to
> >> package your software, they can even package it up and license it
> >> under a commercial (paid) license; the ASL 2.0 is pretty permissive.
> >> There are some patent protections in there, as well as some rules
> >> about explicitly specifying any code you've changed, and rules about
> >> use of the project name (like you can't sell a version of NiFi with
> >> your additional NAR and call it "NiFi++").
> >>
> >> Regards,
> >> Matt
> >>
> >> On Thu, Mar 2, 2017 at 7:10 AM, Uwe Geercken <uw...@web.de> wrote:
> >> > Thanks Andrew,
> >> >
> >> > Matt also pointed me to the same direction.
> >> >
> >> > But my question is, what if I switch to the Apache license model and some
> >> > other software or distribution wants to package my software and they use a
> >> > different licence model. Will I have a similar problem there? Do you know?
> >> >
> >> > I will spend some time on the topic on the weekend...
> >> >
> >> > Rgds,
> >> >
> >> > Uwe
> >> >
> >> > Gesendet: Donnerstag, 02. März 2017 um 05:06 Uhr
> >> > Von: "Andrew Grande" <ap...@gmail.com>
> >> > An: users@nifi.apache.org
> >> > Betreff: Re: Re: new Nifi Processors
> >> >
> >> > Basically the GPL license puts restrictions on how one can distribute in
> >> > practical terms. Meaning your work may live under GPL license as long as
> >> > it's not part of the official package. End users will have to download your
> >> > NAR themselves.
> >> >
> >> > Andrew
> >> >
> >> >
> >> > On Wed, Mar 1, 2017, 8:43 AM Matt Burgess <ma...@apache.org> wrote:
> >> >>
> >> >> Uwe,
> >> >>
> >> >> Sorry for misspeaking, by "official Apache NiFi repo" I meant the
> >> >> Apache NiFi codebase (the "built-in" processors, e.g.). For the
> >> >> licensing part, if you distribute something with GPL binary
> >> >> dependencies, I believe the entire distribution must be licensed as
> >> >> GPL or something GPL-compatible. This is not a bad thing, but due to
> >> >> Apache licensing, such a processor could not be accepted as-is into
> >> >> the NiFi codebase. Even LGPL binary dependencies are not allowed.
> >> >> However as you have made your processor available via your own repo,
> >> >> the community is free to download and use your processor under the
> >> >> terms of your license. However if someone packaged up a NiFi
> >> >> distribution with a GPL-licensed processor (for example), they would
> >> >> not be allowed to distribute that package under an Apache 2.0 license;
> >> >> rather I believe the whole package would have to be licensed under the
> >> >> GPL.
> >> >>
> >> >> I am no licensing expert by any means, but I have had experience with
> >> >> these kinds of things, both for NiFi and other extensible open-source
> >> >> projects.
> >> >>
> >> >> Regards,
> >> >> Matt
> >> >>
> >> >> On Wed, Mar 1, 2017 at 7:01 AM, Uwe Geercken <uw...@web.de> wrote:
> >> >> > Matt,
> >> >> >
> >> >> > I did not know there is an official Apache Nifi repo. If you send me a
> >> >> > link, I will have a look.
> >> >> >
> >> >> > Also, is there an official way of tagging, annotating or otherwise
> >> >> > documenting the license model for a processor? At which point in the code,
> >> >> > documentation do I have to place license information?
> >> >> >
> >> >> > I will check if the Apache license fits to my personal ideas of how my
> >> >> > software should be protected. I am not a license expert, so I will have to
> >> >> > spend some time to understand what that means. Also I need to check what it
> >> >> > means for the software (and current users) if I change the license model.
> >> >> >
> >> >> > Anyway, this is still a first version of the processors. So they will
> >> >> > mature over time and I hope at that point the extension registry is there.
> >> >> >
> >> >> > In general - as you know Matt - I am creating open source software
> >> >> > (since 2000). I believe in the idea of open source and of sharing for the
> >> >> > benefit of all of us.
> >> >> >
> >> >> > If I can, I will adjust whatever is necessary, so that the license is
> >> >> > not a hurdle for using the processors. Nifi is a really great product and I
> >> >> > still remember my first impression when I saw it.....
> >> >> >
> >> >> > Greetings,
> >> >> >
> >> >> > Uwe
> >> >> >
> >> >> >> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
> >> >> >> Von: "Matt Burgess" <ma...@apache.org>
> >> >> >> An: users@nifi.apache.org
> >> >> >> Betreff: Re: new Nifi Processors
> >> >> >>
> >> >> >> Uwe G has made his processors available (thank you!) via his own repo
> >> >> >> vs the official Apache NiFi repo; this may be directly related to your
> >> >> >> point about licensing. Having said that, he is of course at liberty
> >> >> >> to license those separate processors as he sees fit (assuming it is
> >> >> >> also in accordance with the licenses he has employed). Apache NiFi
> >> >> >> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
> >> >> >> alternatively and even before an Extension Registry [2] is supported,
> >> >> >> authors can make their NiFi processors and such available under the
> >> >> >> appropriate licenses. If there are commercial (or other) entities
> >> >> >> looking to package such extensions with the official Apache NiFi
> >> >> >> distribution, they would be subject to the same terms of the License &
> >> >> >> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Matt
> >> >> >>
> >> >> >> [1] https://www.apache.org/legal/resolved.html
> >> >> >> [2]
> >> >> >> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
> >> >> >> <an...@gmail.com> wrote:
> >> >> >> > Hi, Uwe,
> >> >> >> >
> >> >> >> > These look useful. However, typically custom processors are either
> >> >> >> > Apache
> >> >> >> > 2.0 or MIT licensed. These don't seem to specify a license, but your
> >> >> >> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not
> >> >> >> > sure that
> >> >> >> > fits with most uses of NiFi.
> >> >> >> >
> >> >> >> > Can you please clarify?
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > -Matt
> >> >> >> >
> >> >> >> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> Hello everyone,
> >> >> >> >>
> >> >> >> >> I just wanted to let you know, that I have created four processors
> >> >> >> >> for
> >> >> >> >> Nifi
> >> >> >> >>
> >> >> >> >> 1) GenerateData - generates random data (test data) based on word
> >> >> >> >> lists,
> >> >> >> >> regular expressions or purely random
> >> >> >> >> 2) RuleEngine - a ruleengine which allows to process complex
> >> >> >> >> business
> >> >> >> >> logic. But the logic is maintained in a separate web app and thus
> >> >> >> >> outside of
> >> >> >> >> the flow. If the logic changes the flow does NOT have to change.
> >> >> >> >> 3) SplitToAttribute - splits a single CSV row into flow file
> >> >> >> >> attributes
> >> >> >> >> 4) MergeTemplate - merges flow file attributes with an Apache
> >> >> >> >> Velocity
> >> >> >> >> template and writes the result to the flow file content
> >> >> >> >>
> >> >> >> >> Please give them a try and let me know your findings and thoughts.
> >> >> >> >>
> >> >> >> >> https://github.com/uwegeercken/nifi_processors
> >> >> >> >>
> >> >> >> >> rgds,
> >> >> >> >>
> >> >> >> >> Uwe
> >> >> >> >
> >> >> >> >
> >> >> >>
> >>
>
Aw: Re: Re: Re: Re: new Nifi Processors
Posted by Uwe Geercken <uw...@web.de>.
Joe,
thanks. I added the LICENCE and NOTICE file to the nar and also licence info in all classes.
Rgds,
Uwe
> Gesendet: Donnerstag, 02. März 2017 um 22:07 Uhr
> Von: "Joe Witt" <jo...@gmail.com>
> An: users@nifi.apache.org
> Betreff: Re: Re: Re: Re: new Nifi Processors
>
> Uwe
>
> To progress toward a pull request for inclusion in the nifi community
> we will need a LICENSE/NOTICE to end up in the nar bundle itself. You
> can see many examples of this in other nars such as [1]
>
> If you don't need to edit the LICENSE you can not provide it and a
> default one will be provided. Same for NOTICE. The learning curve on
> proper licensing is not pleasant and we're in all the license struggle
> together so we can help get it right.
>
> You're doing some really cool work here. Will be awesome if we can
> work with you to get the things you'd like contributed into formal
> contribution/PR status. Certainly you don't have to do that and can
> instead just publish them outside the nifi community. We're happy to
> help either way.
>
> [1] https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-ignite-bundle/nifi-ignite-nar/src/main/resources/META-INF
>
> Thanks
> Joe
>
> On Thu, Mar 2, 2017 at 3:56 PM, Uwe Geercken <uw...@web.de> wrote:
> > Thanks for all your resposes and help.
> >
> > One last question (at least for the moment ;-) ):
> >
> > Should I place a license file in the nar file? Or is it enough to place it in the code? Any conventions from the Apache side?
> >
> > Rgds,
> >
> > Uwe
> >
> >
> >> Gesendet: Donnerstag, 02. März 2017 um 15:53 Uhr
> >> Von: "Matt Burgess" <ma...@apache.org>
> >> An: users@nifi.apache.org
> >> Betreff: Re: Re: Re: new Nifi Processors
> >>
> >> Uwe,
> >>
> >> If your NAR can be licensed under the Apache Software License 2.0,
> >> then you shouldn't run into any issues with other folks want to
> >> package your software, they can even package it up and license it
> >> under a commercial (paid) license; the ASL 2.0 is pretty permissive.
> >> There are some patent protections in there, as well as some rules
> >> about explicitly specifying any code you've changed, and rules about
> >> use of the project name (like you can't sell a version of NiFi with
> >> your additional NAR and call it "NiFi++").
> >>
> >> Regards,
> >> Matt
> >>
> >> On Thu, Mar 2, 2017 at 7:10 AM, Uwe Geercken <uw...@web.de> wrote:
> >> > Thanks Andrew,
> >> >
> >> > Matt also pointed me to the same direction.
> >> >
> >> > But my question is, what if I switch to the Apache license model and some
> >> > other software or distribution wants to package my software and they use a
> >> > different licence model. Will I have a similar problem there? Do you know?
> >> >
> >> > I will spend some time on the topic on the weekend...
> >> >
> >> > Rgds,
> >> >
> >> > Uwe
> >> >
> >> > Gesendet: Donnerstag, 02. März 2017 um 05:06 Uhr
> >> > Von: "Andrew Grande" <ap...@gmail.com>
> >> > An: users@nifi.apache.org
> >> > Betreff: Re: Re: new Nifi Processors
> >> >
> >> > Basically the GPL license puts restrictions on how one can distribute in
> >> > practical terms. Meaning your work may live under GPL license as long as
> >> > it's not part of the official package. End users will have to download your
> >> > NAR themselves.
> >> >
> >> > Andrew
> >> >
> >> >
> >> > On Wed, Mar 1, 2017, 8:43 AM Matt Burgess <ma...@apache.org> wrote:
> >> >>
> >> >> Uwe,
> >> >>
> >> >> Sorry for misspeaking, by "official Apache NiFi repo" I meant the
> >> >> Apache NiFi codebase (the "built-in" processors, e.g.). For the
> >> >> licensing part, if you distribute something with GPL binary
> >> >> dependencies, I believe the entire distribution must be licensed as
> >> >> GPL or something GPL-compatible. This is not a bad thing, but due to
> >> >> Apache licensing, such a processor could not be accepted as-is into
> >> >> the NiFi codebase. Even LGPL binary dependencies are not allowed.
> >> >> However as you have made your processor available via your own repo,
> >> >> the community is free to download and use your processor under the
> >> >> terms of your license. However if someone packaged up a NiFi
> >> >> distribution with a GPL-licensed processor (for example), they would
> >> >> not be allowed to distribute that package under an Apache 2.0 license;
> >> >> rather I believe the whole package would have to be licensed under the
> >> >> GPL.
> >> >>
> >> >> I am no licensing expert by any means, but I have had experience with
> >> >> these kinds of things, both for NiFi and other extensible open-source
> >> >> projects.
> >> >>
> >> >> Regards,
> >> >> Matt
> >> >>
> >> >> On Wed, Mar 1, 2017 at 7:01 AM, Uwe Geercken <uw...@web.de> wrote:
> >> >> > Matt,
> >> >> >
> >> >> > I did not know there is an official Apache Nifi repo. If you send me a
> >> >> > link, I will have a look.
> >> >> >
> >> >> > Also, is there an official way of tagging, annotating or otherwise
> >> >> > documenting the license model for a processor? At which point in the code,
> >> >> > documentation do I have to place license information?
> >> >> >
> >> >> > I will check if the Apache license fits to my personal ideas of how my
> >> >> > software should be protected. I am not a license expert, so I will have to
> >> >> > spend some time to understand what that means. Also I need to check what it
> >> >> > means for the software (and current users) if I change the license model.
> >> >> >
> >> >> > Anyway, this is still a first version of the processors. So they will
> >> >> > mature over time and I hope at that point the extension registry is there.
> >> >> >
> >> >> > In general - as you know Matt - I am creating open source software
> >> >> > (since 2000). I believe in the idea of open source and of sharing for the
> >> >> > benefit of all of us.
> >> >> >
> >> >> > If I can, I will adjust whatever is necessary, so that the license is
> >> >> > not a hurdle for using the processors. Nifi is a really great product and I
> >> >> > still remember my first impression when I saw it.....
> >> >> >
> >> >> > Greetings,
> >> >> >
> >> >> > Uwe
> >> >> >
> >> >> >> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
> >> >> >> Von: "Matt Burgess" <ma...@apache.org>
> >> >> >> An: users@nifi.apache.org
> >> >> >> Betreff: Re: new Nifi Processors
> >> >> >>
> >> >> >> Uwe G has made his processors available (thank you!) via his own repo
> >> >> >> vs the official Apache NiFi repo; this may be directly related to your
> >> >> >> point about licensing. Having said that, he is of course at liberty
> >> >> >> to license those separate processors as he sees fit (assuming it is
> >> >> >> also in accordance with the licenses he has employed). Apache NiFi
> >> >> >> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
> >> >> >> alternatively and even before an Extension Registry [2] is supported,
> >> >> >> authors can make their NiFi processors and such available under the
> >> >> >> appropriate licenses. If there are commercial (or other) entities
> >> >> >> looking to package such extensions with the official Apache NiFi
> >> >> >> distribution, they would be subject to the same terms of the License &
> >> >> >> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Matt
> >> >> >>
> >> >> >> [1] https://www.apache.org/legal/resolved.html
> >> >> >> [2]
> >> >> >> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
> >> >> >> <an...@gmail.com> wrote:
> >> >> >> > Hi, Uwe,
> >> >> >> >
> >> >> >> > These look useful. However, typically custom processors are either
> >> >> >> > Apache
> >> >> >> > 2.0 or MIT licensed. These don't seem to specify a license, but your
> >> >> >> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not
> >> >> >> > sure that
> >> >> >> > fits with most uses of NiFi.
> >> >> >> >
> >> >> >> > Can you please clarify?
> >> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > -Matt
> >> >> >> >
> >> >> >> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> Hello everyone,
> >> >> >> >>
> >> >> >> >> I just wanted to let you know, that I have created four processors
> >> >> >> >> for
> >> >> >> >> Nifi
> >> >> >> >>
> >> >> >> >> 1) GenerateData - generates random data (test data) based on word
> >> >> >> >> lists,
> >> >> >> >> regular expressions or purely random
> >> >> >> >> 2) RuleEngine - a ruleengine which allows to process complex
> >> >> >> >> business
> >> >> >> >> logic. But the logic is maintained in a separate web app and thus
> >> >> >> >> outside of
> >> >> >> >> the flow. If the logic changes the flow does NOT have to change.
> >> >> >> >> 3) SplitToAttribute - splits a single CSV row into flow file
> >> >> >> >> attributes
> >> >> >> >> 4) MergeTemplate - merges flow file attributes with an Apache
> >> >> >> >> Velocity
> >> >> >> >> template and writes the result to the flow file content
> >> >> >> >>
> >> >> >> >> Please give them a try and let me know your findings and thoughts.
> >> >> >> >>
> >> >> >> >> https://github.com/uwegeercken/nifi_processors
> >> >> >> >>
> >> >> >> >> rgds,
> >> >> >> >>
> >> >> >> >> Uwe
> >> >> >> >
> >> >> >> >
> >> >> >>
> >>
>
Re: Re: Re: Re: new Nifi Processors
Posted by Joe Witt <jo...@gmail.com>.
Uwe
To progress toward a pull request for inclusion in the nifi community
we will need a LICENSE/NOTICE to end up in the nar bundle itself. You
can see many examples of this in other nars such as [1]
If you don't need to edit the LICENSE you can not provide it and a
default one will be provided. Same for NOTICE. The learning curve on
proper licensing is not pleasant and we're in all the license struggle
together so we can help get it right.
You're doing some really cool work here. Will be awesome if we can
work with you to get the things you'd like contributed into formal
contribution/PR status. Certainly you don't have to do that and can
instead just publish them outside the nifi community. We're happy to
help either way.
[1] https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-ignite-bundle/nifi-ignite-nar/src/main/resources/META-INF
Thanks
Joe
On Thu, Mar 2, 2017 at 3:56 PM, Uwe Geercken <uw...@web.de> wrote:
> Thanks for all your resposes and help.
>
> One last question (at least for the moment ;-) ):
>
> Should I place a license file in the nar file? Or is it enough to place it in the code? Any conventions from the Apache side?
>
> Rgds,
>
> Uwe
>
>
>> Gesendet: Donnerstag, 02. März 2017 um 15:53 Uhr
>> Von: "Matt Burgess" <ma...@apache.org>
>> An: users@nifi.apache.org
>> Betreff: Re: Re: Re: new Nifi Processors
>>
>> Uwe,
>>
>> If your NAR can be licensed under the Apache Software License 2.0,
>> then you shouldn't run into any issues with other folks want to
>> package your software, they can even package it up and license it
>> under a commercial (paid) license; the ASL 2.0 is pretty permissive.
>> There are some patent protections in there, as well as some rules
>> about explicitly specifying any code you've changed, and rules about
>> use of the project name (like you can't sell a version of NiFi with
>> your additional NAR and call it "NiFi++").
>>
>> Regards,
>> Matt
>>
>> On Thu, Mar 2, 2017 at 7:10 AM, Uwe Geercken <uw...@web.de> wrote:
>> > Thanks Andrew,
>> >
>> > Matt also pointed me to the same direction.
>> >
>> > But my question is, what if I switch to the Apache license model and some
>> > other software or distribution wants to package my software and they use a
>> > different licence model. Will I have a similar problem there? Do you know?
>> >
>> > I will spend some time on the topic on the weekend...
>> >
>> > Rgds,
>> >
>> > Uwe
>> >
>> > Gesendet: Donnerstag, 02. März 2017 um 05:06 Uhr
>> > Von: "Andrew Grande" <ap...@gmail.com>
>> > An: users@nifi.apache.org
>> > Betreff: Re: Re: new Nifi Processors
>> >
>> > Basically the GPL license puts restrictions on how one can distribute in
>> > practical terms. Meaning your work may live under GPL license as long as
>> > it's not part of the official package. End users will have to download your
>> > NAR themselves.
>> >
>> > Andrew
>> >
>> >
>> > On Wed, Mar 1, 2017, 8:43 AM Matt Burgess <ma...@apache.org> wrote:
>> >>
>> >> Uwe,
>> >>
>> >> Sorry for misspeaking, by "official Apache NiFi repo" I meant the
>> >> Apache NiFi codebase (the "built-in" processors, e.g.). For the
>> >> licensing part, if you distribute something with GPL binary
>> >> dependencies, I believe the entire distribution must be licensed as
>> >> GPL or something GPL-compatible. This is not a bad thing, but due to
>> >> Apache licensing, such a processor could not be accepted as-is into
>> >> the NiFi codebase. Even LGPL binary dependencies are not allowed.
>> >> However as you have made your processor available via your own repo,
>> >> the community is free to download and use your processor under the
>> >> terms of your license. However if someone packaged up a NiFi
>> >> distribution with a GPL-licensed processor (for example), they would
>> >> not be allowed to distribute that package under an Apache 2.0 license;
>> >> rather I believe the whole package would have to be licensed under the
>> >> GPL.
>> >>
>> >> I am no licensing expert by any means, but I have had experience with
>> >> these kinds of things, both for NiFi and other extensible open-source
>> >> projects.
>> >>
>> >> Regards,
>> >> Matt
>> >>
>> >> On Wed, Mar 1, 2017 at 7:01 AM, Uwe Geercken <uw...@web.de> wrote:
>> >> > Matt,
>> >> >
>> >> > I did not know there is an official Apache Nifi repo. If you send me a
>> >> > link, I will have a look.
>> >> >
>> >> > Also, is there an official way of tagging, annotating or otherwise
>> >> > documenting the license model for a processor? At which point in the code,
>> >> > documentation do I have to place license information?
>> >> >
>> >> > I will check if the Apache license fits to my personal ideas of how my
>> >> > software should be protected. I am not a license expert, so I will have to
>> >> > spend some time to understand what that means. Also I need to check what it
>> >> > means for the software (and current users) if I change the license model.
>> >> >
>> >> > Anyway, this is still a first version of the processors. So they will
>> >> > mature over time and I hope at that point the extension registry is there.
>> >> >
>> >> > In general - as you know Matt - I am creating open source software
>> >> > (since 2000). I believe in the idea of open source and of sharing for the
>> >> > benefit of all of us.
>> >> >
>> >> > If I can, I will adjust whatever is necessary, so that the license is
>> >> > not a hurdle for using the processors. Nifi is a really great product and I
>> >> > still remember my first impression when I saw it.....
>> >> >
>> >> > Greetings,
>> >> >
>> >> > Uwe
>> >> >
>> >> >> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
>> >> >> Von: "Matt Burgess" <ma...@apache.org>
>> >> >> An: users@nifi.apache.org
>> >> >> Betreff: Re: new Nifi Processors
>> >> >>
>> >> >> Uwe G has made his processors available (thank you!) via his own repo
>> >> >> vs the official Apache NiFi repo; this may be directly related to your
>> >> >> point about licensing. Having said that, he is of course at liberty
>> >> >> to license those separate processors as he sees fit (assuming it is
>> >> >> also in accordance with the licenses he has employed). Apache NiFi
>> >> >> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
>> >> >> alternatively and even before an Extension Registry [2] is supported,
>> >> >> authors can make their NiFi processors and such available under the
>> >> >> appropriate licenses. If there are commercial (or other) entities
>> >> >> looking to package such extensions with the official Apache NiFi
>> >> >> distribution, they would be subject to the same terms of the License &
>> >> >> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
>> >> >>
>> >> >> Regards,
>> >> >> Matt
>> >> >>
>> >> >> [1] https://www.apache.org/legal/resolved.html
>> >> >> [2]
>> >> >> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
>> >> >>
>> >> >>
>> >> >> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
>> >> >> <an...@gmail.com> wrote:
>> >> >> > Hi, Uwe,
>> >> >> >
>> >> >> > These look useful. However, typically custom processors are either
>> >> >> > Apache
>> >> >> > 2.0 or MIT licensed. These don't seem to specify a license, but your
>> >> >> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not
>> >> >> > sure that
>> >> >> > fits with most uses of NiFi.
>> >> >> >
>> >> >> > Can you please clarify?
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > -Matt
>> >> >> >
>> >> >> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hello everyone,
>> >> >> >>
>> >> >> >> I just wanted to let you know, that I have created four processors
>> >> >> >> for
>> >> >> >> Nifi
>> >> >> >>
>> >> >> >> 1) GenerateData - generates random data (test data) based on word
>> >> >> >> lists,
>> >> >> >> regular expressions or purely random
>> >> >> >> 2) RuleEngine - a ruleengine which allows to process complex
>> >> >> >> business
>> >> >> >> logic. But the logic is maintained in a separate web app and thus
>> >> >> >> outside of
>> >> >> >> the flow. If the logic changes the flow does NOT have to change.
>> >> >> >> 3) SplitToAttribute - splits a single CSV row into flow file
>> >> >> >> attributes
>> >> >> >> 4) MergeTemplate - merges flow file attributes with an Apache
>> >> >> >> Velocity
>> >> >> >> template and writes the result to the flow file content
>> >> >> >>
>> >> >> >> Please give them a try and let me know your findings and thoughts.
>> >> >> >>
>> >> >> >> https://github.com/uwegeercken/nifi_processors
>> >> >> >>
>> >> >> >> rgds,
>> >> >> >>
>> >> >> >> Uwe
>> >> >> >
>> >> >> >
>> >> >>
>>
Aw: Re: Re: Re: new Nifi Processors
Posted by Uwe Geercken <uw...@web.de>.
Thanks for all your resposes and help.
One last question (at least for the moment ;-) ):
Should I place a license file in the nar file? Or is it enough to place it in the code? Any conventions from the Apache side?
Rgds,
Uwe
> Gesendet: Donnerstag, 02. März 2017 um 15:53 Uhr
> Von: "Matt Burgess" <ma...@apache.org>
> An: users@nifi.apache.org
> Betreff: Re: Re: Re: new Nifi Processors
>
> Uwe,
>
> If your NAR can be licensed under the Apache Software License 2.0,
> then you shouldn't run into any issues with other folks want to
> package your software, they can even package it up and license it
> under a commercial (paid) license; the ASL 2.0 is pretty permissive.
> There are some patent protections in there, as well as some rules
> about explicitly specifying any code you've changed, and rules about
> use of the project name (like you can't sell a version of NiFi with
> your additional NAR and call it "NiFi++").
>
> Regards,
> Matt
>
> On Thu, Mar 2, 2017 at 7:10 AM, Uwe Geercken <uw...@web.de> wrote:
> > Thanks Andrew,
> >
> > Matt also pointed me to the same direction.
> >
> > But my question is, what if I switch to the Apache license model and some
> > other software or distribution wants to package my software and they use a
> > different licence model. Will I have a similar problem there? Do you know?
> >
> > I will spend some time on the topic on the weekend...
> >
> > Rgds,
> >
> > Uwe
> >
> > Gesendet: Donnerstag, 02. März 2017 um 05:06 Uhr
> > Von: "Andrew Grande" <ap...@gmail.com>
> > An: users@nifi.apache.org
> > Betreff: Re: Re: new Nifi Processors
> >
> > Basically the GPL license puts restrictions on how one can distribute in
> > practical terms. Meaning your work may live under GPL license as long as
> > it's not part of the official package. End users will have to download your
> > NAR themselves.
> >
> > Andrew
> >
> >
> > On Wed, Mar 1, 2017, 8:43 AM Matt Burgess <ma...@apache.org> wrote:
> >>
> >> Uwe,
> >>
> >> Sorry for misspeaking, by "official Apache NiFi repo" I meant the
> >> Apache NiFi codebase (the "built-in" processors, e.g.). For the
> >> licensing part, if you distribute something with GPL binary
> >> dependencies, I believe the entire distribution must be licensed as
> >> GPL or something GPL-compatible. This is not a bad thing, but due to
> >> Apache licensing, such a processor could not be accepted as-is into
> >> the NiFi codebase. Even LGPL binary dependencies are not allowed.
> >> However as you have made your processor available via your own repo,
> >> the community is free to download and use your processor under the
> >> terms of your license. However if someone packaged up a NiFi
> >> distribution with a GPL-licensed processor (for example), they would
> >> not be allowed to distribute that package under an Apache 2.0 license;
> >> rather I believe the whole package would have to be licensed under the
> >> GPL.
> >>
> >> I am no licensing expert by any means, but I have had experience with
> >> these kinds of things, both for NiFi and other extensible open-source
> >> projects.
> >>
> >> Regards,
> >> Matt
> >>
> >> On Wed, Mar 1, 2017 at 7:01 AM, Uwe Geercken <uw...@web.de> wrote:
> >> > Matt,
> >> >
> >> > I did not know there is an official Apache Nifi repo. If you send me a
> >> > link, I will have a look.
> >> >
> >> > Also, is there an official way of tagging, annotating or otherwise
> >> > documenting the license model for a processor? At which point in the code,
> >> > documentation do I have to place license information?
> >> >
> >> > I will check if the Apache license fits to my personal ideas of how my
> >> > software should be protected. I am not a license expert, so I will have to
> >> > spend some time to understand what that means. Also I need to check what it
> >> > means for the software (and current users) if I change the license model.
> >> >
> >> > Anyway, this is still a first version of the processors. So they will
> >> > mature over time and I hope at that point the extension registry is there.
> >> >
> >> > In general - as you know Matt - I am creating open source software
> >> > (since 2000). I believe in the idea of open source and of sharing for the
> >> > benefit of all of us.
> >> >
> >> > If I can, I will adjust whatever is necessary, so that the license is
> >> > not a hurdle for using the processors. Nifi is a really great product and I
> >> > still remember my first impression when I saw it.....
> >> >
> >> > Greetings,
> >> >
> >> > Uwe
> >> >
> >> >> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
> >> >> Von: "Matt Burgess" <ma...@apache.org>
> >> >> An: users@nifi.apache.org
> >> >> Betreff: Re: new Nifi Processors
> >> >>
> >> >> Uwe G has made his processors available (thank you!) via his own repo
> >> >> vs the official Apache NiFi repo; this may be directly related to your
> >> >> point about licensing. Having said that, he is of course at liberty
> >> >> to license those separate processors as he sees fit (assuming it is
> >> >> also in accordance with the licenses he has employed). Apache NiFi
> >> >> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
> >> >> alternatively and even before an Extension Registry [2] is supported,
> >> >> authors can make their NiFi processors and such available under the
> >> >> appropriate licenses. If there are commercial (or other) entities
> >> >> looking to package such extensions with the official Apache NiFi
> >> >> distribution, they would be subject to the same terms of the License &
> >> >> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
> >> >>
> >> >> Regards,
> >> >> Matt
> >> >>
> >> >> [1] https://www.apache.org/legal/resolved.html
> >> >> [2]
> >> >> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
> >> >>
> >> >>
> >> >> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
> >> >> <an...@gmail.com> wrote:
> >> >> > Hi, Uwe,
> >> >> >
> >> >> > These look useful. However, typically custom processors are either
> >> >> > Apache
> >> >> > 2.0 or MIT licensed. These don't seem to specify a license, but your
> >> >> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not
> >> >> > sure that
> >> >> > fits with most uses of NiFi.
> >> >> >
> >> >> > Can you please clarify?
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> > -Matt
> >> >> >
> >> >> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hello everyone,
> >> >> >>
> >> >> >> I just wanted to let you know, that I have created four processors
> >> >> >> for
> >> >> >> Nifi
> >> >> >>
> >> >> >> 1) GenerateData - generates random data (test data) based on word
> >> >> >> lists,
> >> >> >> regular expressions or purely random
> >> >> >> 2) RuleEngine - a ruleengine which allows to process complex
> >> >> >> business
> >> >> >> logic. But the logic is maintained in a separate web app and thus
> >> >> >> outside of
> >> >> >> the flow. If the logic changes the flow does NOT have to change.
> >> >> >> 3) SplitToAttribute - splits a single CSV row into flow file
> >> >> >> attributes
> >> >> >> 4) MergeTemplate - merges flow file attributes with an Apache
> >> >> >> Velocity
> >> >> >> template and writes the result to the flow file content
> >> >> >>
> >> >> >> Please give them a try and let me know your findings and thoughts.
> >> >> >>
> >> >> >> https://github.com/uwegeercken/nifi_processors
> >> >> >>
> >> >> >> rgds,
> >> >> >>
> >> >> >> Uwe
> >> >> >
> >> >> >
> >> >>
>
Re: Re: Re: new Nifi Processors
Posted by Matt Burgess <ma...@apache.org>.
Uwe,
If your NAR can be licensed under the Apache Software License 2.0,
then you shouldn't run into any issues with other folks want to
package your software, they can even package it up and license it
under a commercial (paid) license; the ASL 2.0 is pretty permissive.
There are some patent protections in there, as well as some rules
about explicitly specifying any code you've changed, and rules about
use of the project name (like you can't sell a version of NiFi with
your additional NAR and call it "NiFi++").
Regards,
Matt
On Thu, Mar 2, 2017 at 7:10 AM, Uwe Geercken <uw...@web.de> wrote:
> Thanks Andrew,
>
> Matt also pointed me to the same direction.
>
> But my question is, what if I switch to the Apache license model and some
> other software or distribution wants to package my software and they use a
> different licence model. Will I have a similar problem there? Do you know?
>
> I will spend some time on the topic on the weekend...
>
> Rgds,
>
> Uwe
>
> Gesendet: Donnerstag, 02. März 2017 um 05:06 Uhr
> Von: "Andrew Grande" <ap...@gmail.com>
> An: users@nifi.apache.org
> Betreff: Re: Re: new Nifi Processors
>
> Basically the GPL license puts restrictions on how one can distribute in
> practical terms. Meaning your work may live under GPL license as long as
> it's not part of the official package. End users will have to download your
> NAR themselves.
>
> Andrew
>
>
> On Wed, Mar 1, 2017, 8:43 AM Matt Burgess <ma...@apache.org> wrote:
>>
>> Uwe,
>>
>> Sorry for misspeaking, by "official Apache NiFi repo" I meant the
>> Apache NiFi codebase (the "built-in" processors, e.g.). For the
>> licensing part, if you distribute something with GPL binary
>> dependencies, I believe the entire distribution must be licensed as
>> GPL or something GPL-compatible. This is not a bad thing, but due to
>> Apache licensing, such a processor could not be accepted as-is into
>> the NiFi codebase. Even LGPL binary dependencies are not allowed.
>> However as you have made your processor available via your own repo,
>> the community is free to download and use your processor under the
>> terms of your license. However if someone packaged up a NiFi
>> distribution with a GPL-licensed processor (for example), they would
>> not be allowed to distribute that package under an Apache 2.0 license;
>> rather I believe the whole package would have to be licensed under the
>> GPL.
>>
>> I am no licensing expert by any means, but I have had experience with
>> these kinds of things, both for NiFi and other extensible open-source
>> projects.
>>
>> Regards,
>> Matt
>>
>> On Wed, Mar 1, 2017 at 7:01 AM, Uwe Geercken <uw...@web.de> wrote:
>> > Matt,
>> >
>> > I did not know there is an official Apache Nifi repo. If you send me a
>> > link, I will have a look.
>> >
>> > Also, is there an official way of tagging, annotating or otherwise
>> > documenting the license model for a processor? At which point in the code,
>> > documentation do I have to place license information?
>> >
>> > I will check if the Apache license fits to my personal ideas of how my
>> > software should be protected. I am not a license expert, so I will have to
>> > spend some time to understand what that means. Also I need to check what it
>> > means for the software (and current users) if I change the license model.
>> >
>> > Anyway, this is still a first version of the processors. So they will
>> > mature over time and I hope at that point the extension registry is there.
>> >
>> > In general - as you know Matt - I am creating open source software
>> > (since 2000). I believe in the idea of open source and of sharing for the
>> > benefit of all of us.
>> >
>> > If I can, I will adjust whatever is necessary, so that the license is
>> > not a hurdle for using the processors. Nifi is a really great product and I
>> > still remember my first impression when I saw it.....
>> >
>> > Greetings,
>> >
>> > Uwe
>> >
>> >> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
>> >> Von: "Matt Burgess" <ma...@apache.org>
>> >> An: users@nifi.apache.org
>> >> Betreff: Re: new Nifi Processors
>> >>
>> >> Uwe G has made his processors available (thank you!) via his own repo
>> >> vs the official Apache NiFi repo; this may be directly related to your
>> >> point about licensing. Having said that, he is of course at liberty
>> >> to license those separate processors as he sees fit (assuming it is
>> >> also in accordance with the licenses he has employed). Apache NiFi
>> >> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
>> >> alternatively and even before an Extension Registry [2] is supported,
>> >> authors can make their NiFi processors and such available under the
>> >> appropriate licenses. If there are commercial (or other) entities
>> >> looking to package such extensions with the official Apache NiFi
>> >> distribution, they would be subject to the same terms of the License &
>> >> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
>> >>
>> >> Regards,
>> >> Matt
>> >>
>> >> [1] https://www.apache.org/legal/resolved.html
>> >> [2]
>> >> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
>> >>
>> >>
>> >> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
>> >> <an...@gmail.com> wrote:
>> >> > Hi, Uwe,
>> >> >
>> >> > These look useful. However, typically custom processors are either
>> >> > Apache
>> >> > 2.0 or MIT licensed. These don't seem to specify a license, but your
>> >> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not
>> >> > sure that
>> >> > fits with most uses of NiFi.
>> >> >
>> >> > Can you please clarify?
>> >> >
>> >> > Thanks
>> >> >
>> >> > -Matt
>> >> >
>> >> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de>
>> >> > wrote:
>> >> >>
>> >> >> Hello everyone,
>> >> >>
>> >> >> I just wanted to let you know, that I have created four processors
>> >> >> for
>> >> >> Nifi
>> >> >>
>> >> >> 1) GenerateData - generates random data (test data) based on word
>> >> >> lists,
>> >> >> regular expressions or purely random
>> >> >> 2) RuleEngine - a ruleengine which allows to process complex
>> >> >> business
>> >> >> logic. But the logic is maintained in a separate web app and thus
>> >> >> outside of
>> >> >> the flow. If the logic changes the flow does NOT have to change.
>> >> >> 3) SplitToAttribute - splits a single CSV row into flow file
>> >> >> attributes
>> >> >> 4) MergeTemplate - merges flow file attributes with an Apache
>> >> >> Velocity
>> >> >> template and writes the result to the flow file content
>> >> >>
>> >> >> Please give them a try and let me know your findings and thoughts.
>> >> >>
>> >> >> https://github.com/uwegeercken/nifi_processors
>> >> >>
>> >> >> rgds,
>> >> >>
>> >> >> Uwe
>> >> >
>> >> >
>> >>
Re: Re: new Nifi Processors
Posted by Andrew Grande <ap...@gmail.com>.
Basically the GPL license puts restrictions on how one can distribute in
practical terms. Meaning your work may live under GPL license as long as
it's not part of the official package. End users will have to download your
NAR themselves.
Andrew
On Wed, Mar 1, 2017, 8:43 AM Matt Burgess <ma...@apache.org> wrote:
> Uwe,
>
> Sorry for misspeaking, by "official Apache NiFi repo" I meant the
> Apache NiFi codebase (the "built-in" processors, e.g.). For the
> licensing part, if you distribute something with GPL binary
> dependencies, I believe the entire distribution must be licensed as
> GPL or something GPL-compatible. This is not a bad thing, but due to
> Apache licensing, such a processor could not be accepted as-is into
> the NiFi codebase. Even LGPL binary dependencies are not allowed.
> However as you have made your processor available via your own repo,
> the community is free to download and use your processor under the
> terms of your license. However if someone packaged up a NiFi
> distribution with a GPL-licensed processor (for example), they would
> not be allowed to distribute that package under an Apache 2.0 license;
> rather I believe the whole package would have to be licensed under the
> GPL.
>
> I am no licensing expert by any means, but I have had experience with
> these kinds of things, both for NiFi and other extensible open-source
> projects.
>
> Regards,
> Matt
>
> On Wed, Mar 1, 2017 at 7:01 AM, Uwe Geercken <uw...@web.de> wrote:
> > Matt,
> >
> > I did not know there is an official Apache Nifi repo. If you send me a
> link, I will have a look.
> >
> > Also, is there an official way of tagging, annotating or otherwise
> documenting the license model for a processor? At which point in the code,
> documentation do I have to place license information?
> >
> > I will check if the Apache license fits to my personal ideas of how my
> software should be protected. I am not a license expert, so I will have to
> spend some time to understand what that means. Also I need to check what it
> means for the software (and current users) if I change the license model.
> >
> > Anyway, this is still a first version of the processors. So they will
> mature over time and I hope at that point the extension registry is there.
> >
> > In general - as you know Matt - I am creating open source software
> (since 2000). I believe in the idea of open source and of sharing for the
> benefit of all of us.
> >
> > If I can, I will adjust whatever is necessary, so that the license is
> not a hurdle for using the processors. Nifi is a really great product and I
> still remember my first impression when I saw it.....
> >
> > Greetings,
> >
> > Uwe
> >
> >> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
> >> Von: "Matt Burgess" <ma...@apache.org>
> >> An: users@nifi.apache.org
> >> Betreff: Re: new Nifi Processors
> >>
> >> Uwe G has made his processors available (thank you!) via his own repo
> >> vs the official Apache NiFi repo; this may be directly related to your
> >> point about licensing. Having said that, he is of course at liberty
> >> to license those separate processors as he sees fit (assuming it is
> >> also in accordance with the licenses he has employed). Apache NiFi
> >> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
> >> alternatively and even before an Extension Registry [2] is supported,
> >> authors can make their NiFi processors and such available under the
> >> appropriate licenses. If there are commercial (or other) entities
> >> looking to package such extensions with the official Apache NiFi
> >> distribution, they would be subject to the same terms of the License &
> >> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
> >>
> >> Regards,
> >> Matt
> >>
> >> [1] https://www.apache.org/legal/resolved.html
> >> [2]
> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
> >>
> >>
> >> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
> >> <an...@gmail.com> wrote:
> >> > Hi, Uwe,
> >> >
> >> > These look useful. However, typically custom processors are either
> Apache
> >> > 2.0 or MIT licensed. These don't seem to specify a license, but your
> >> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not
> sure that
> >> > fits with most uses of NiFi.
> >> >
> >> > Can you please clarify?
> >> >
> >> > Thanks
> >> >
> >> > -Matt
> >> >
> >> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de>
> wrote:
> >> >>
> >> >> Hello everyone,
> >> >>
> >> >> I just wanted to let you know, that I have created four processors
> for
> >> >> Nifi
> >> >>
> >> >> 1) GenerateData - generates random data (test data) based on word
> lists,
> >> >> regular expressions or purely random
> >> >> 2) RuleEngine - a ruleengine which allows to process complex business
> >> >> logic. But the logic is maintained in a separate web app and thus
> outside of
> >> >> the flow. If the logic changes the flow does NOT have to change.
> >> >> 3) SplitToAttribute - splits a single CSV row into flow file
> attributes
> >> >> 4) MergeTemplate - merges flow file attributes with an Apache
> Velocity
> >> >> template and writes the result to the flow file content
> >> >>
> >> >> Please give them a try and let me know your findings and thoughts.
> >> >>
> >> >> https://github.com/uwegeercken/nifi_processors
> >> >>
> >> >> rgds,
> >> >>
> >> >> Uwe
> >> >
> >> >
> >>
>
Re: Re: new Nifi Processors
Posted by Matt Burgess <ma...@apache.org>.
Uwe,
Sorry for misspeaking, by "official Apache NiFi repo" I meant the
Apache NiFi codebase (the "built-in" processors, e.g.). For the
licensing part, if you distribute something with GPL binary
dependencies, I believe the entire distribution must be licensed as
GPL or something GPL-compatible. This is not a bad thing, but due to
Apache licensing, such a processor could not be accepted as-is into
the NiFi codebase. Even LGPL binary dependencies are not allowed.
However as you have made your processor available via your own repo,
the community is free to download and use your processor under the
terms of your license. However if someone packaged up a NiFi
distribution with a GPL-licensed processor (for example), they would
not be allowed to distribute that package under an Apache 2.0 license;
rather I believe the whole package would have to be licensed under the
GPL.
I am no licensing expert by any means, but I have had experience with
these kinds of things, both for NiFi and other extensible open-source
projects.
Regards,
Matt
On Wed, Mar 1, 2017 at 7:01 AM, Uwe Geercken <uw...@web.de> wrote:
> Matt,
>
> I did not know there is an official Apache Nifi repo. If you send me a link, I will have a look.
>
> Also, is there an official way of tagging, annotating or otherwise documenting the license model for a processor? At which point in the code, documentation do I have to place license information?
>
> I will check if the Apache license fits to my personal ideas of how my software should be protected. I am not a license expert, so I will have to spend some time to understand what that means. Also I need to check what it means for the software (and current users) if I change the license model.
>
> Anyway, this is still a first version of the processors. So they will mature over time and I hope at that point the extension registry is there.
>
> In general - as you know Matt - I am creating open source software (since 2000). I believe in the idea of open source and of sharing for the benefit of all of us.
>
> If I can, I will adjust whatever is necessary, so that the license is not a hurdle for using the processors. Nifi is a really great product and I still remember my first impression when I saw it.....
>
> Greetings,
>
> Uwe
>
>> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
>> Von: "Matt Burgess" <ma...@apache.org>
>> An: users@nifi.apache.org
>> Betreff: Re: new Nifi Processors
>>
>> Uwe G has made his processors available (thank you!) via his own repo
>> vs the official Apache NiFi repo; this may be directly related to your
>> point about licensing. Having said that, he is of course at liberty
>> to license those separate processors as he sees fit (assuming it is
>> also in accordance with the licenses he has employed). Apache NiFi
>> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
>> alternatively and even before an Extension Registry [2] is supported,
>> authors can make their NiFi processors and such available under the
>> appropriate licenses. If there are commercial (or other) entities
>> looking to package such extensions with the official Apache NiFi
>> distribution, they would be subject to the same terms of the License &
>> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
>>
>> Regards,
>> Matt
>>
>> [1] https://www.apache.org/legal/resolved.html
>> [2] https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
>>
>>
>> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
>> <an...@gmail.com> wrote:
>> > Hi, Uwe,
>> >
>> > These look useful. However, typically custom processors are either Apache
>> > 2.0 or MIT licensed. These don't seem to specify a license, but your
>> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not sure that
>> > fits with most uses of NiFi.
>> >
>> > Can you please clarify?
>> >
>> > Thanks
>> >
>> > -Matt
>> >
>> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de> wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> I just wanted to let you know, that I have created four processors for
>> >> Nifi
>> >>
>> >> 1) GenerateData - generates random data (test data) based on word lists,
>> >> regular expressions or purely random
>> >> 2) RuleEngine - a ruleengine which allows to process complex business
>> >> logic. But the logic is maintained in a separate web app and thus outside of
>> >> the flow. If the logic changes the flow does NOT have to change.
>> >> 3) SplitToAttribute - splits a single CSV row into flow file attributes
>> >> 4) MergeTemplate - merges flow file attributes with an Apache Velocity
>> >> template and writes the result to the flow file content
>> >>
>> >> Please give them a try and let me know your findings and thoughts.
>> >>
>> >> https://github.com/uwegeercken/nifi_processors
>> >>
>> >> rgds,
>> >>
>> >> Uwe
>> >
>> >
>>
Aw: Re: new Nifi Processors
Posted by Uwe Geercken <uw...@web.de>.
Matt,
I did not know there is an official Apache Nifi repo. If you send me a link, I will have a look.
Also, is there an official way of tagging, annotating or otherwise documenting the license model for a processor? At which point in the code, documentation do I have to place license information?
I will check if the Apache license fits to my personal ideas of how my software should be protected. I am not a license expert, so I will have to spend some time to understand what that means. Also I need to check what it means for the software (and current users) if I change the license model.
Anyway, this is still a first version of the processors. So they will mature over time and I hope at that point the extension registry is there.
In general - as you know Matt - I am creating open source software (since 2000). I believe in the idea of open source and of sharing for the benefit of all of us.
If I can, I will adjust whatever is necessary, so that the license is not a hurdle for using the processors. Nifi is a really great product and I still remember my first impression when I saw it.....
Greetings,
Uwe
> Gesendet: Mittwoch, 01. März 2017 um 03:56 Uhr
> Von: "Matt Burgess" <ma...@apache.org>
> An: users@nifi.apache.org
> Betreff: Re: new Nifi Processors
>
> Uwe G has made his processors available (thank you!) via his own repo
> vs the official Apache NiFi repo; this may be directly related to your
> point about licensing. Having said that, he is of course at liberty
> to license those separate processors as he sees fit (assuming it is
> also in accordance with the licenses he has employed). Apache NiFi
> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
> alternatively and even before an Extension Registry [2] is supported,
> authors can make their NiFi processors and such available under the
> appropriate licenses. If there are commercial (or other) entities
> looking to package such extensions with the official Apache NiFi
> distribution, they would be subject to the same terms of the License &
> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
>
> Regards,
> Matt
>
> [1] https://www.apache.org/legal/resolved.html
> [2] https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
>
>
> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
> <an...@gmail.com> wrote:
> > Hi, Uwe,
> >
> > These look useful. However, typically custom processors are either Apache
> > 2.0 or MIT licensed. These don't seem to specify a license, but your
> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not sure that
> > fits with most uses of NiFi.
> >
> > Can you please clarify?
> >
> > Thanks
> >
> > -Matt
> >
> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de> wrote:
> >>
> >> Hello everyone,
> >>
> >> I just wanted to let you know, that I have created four processors for
> >> Nifi
> >>
> >> 1) GenerateData - generates random data (test data) based on word lists,
> >> regular expressions or purely random
> >> 2) RuleEngine - a ruleengine which allows to process complex business
> >> logic. But the logic is maintained in a separate web app and thus outside of
> >> the flow. If the logic changes the flow does NOT have to change.
> >> 3) SplitToAttribute - splits a single CSV row into flow file attributes
> >> 4) MergeTemplate - merges flow file attributes with an Apache Velocity
> >> template and writes the result to the flow file content
> >>
> >> Please give them a try and let me know your findings and thoughts.
> >>
> >> https://github.com/uwegeercken/nifi_processors
> >>
> >> rgds,
> >>
> >> Uwe
> >
> >
>
Re: new Nifi Processors
Posted by Andre <an...@fucs.org>.
All,
It may also be worth to note that JFrazee maintains a list of NiFi related
links here:
https://github.com/jfrazee/awesome-nifi
On Wed, Mar 1, 2017 at 1:56 PM, Matt Burgess <ma...@apache.org> wrote:
> Uwe G has made his processors available (thank you!) via his own repo
> vs the official Apache NiFi repo; this may be directly related to your
> point about licensing. Having said that, he is of course at liberty
> to license those separate processors as he sees fit (assuming it is
> also in accordance with the licenses he has employed). Apache NiFi
> welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
> alternatively and even before an Extension Registry [2] is supported,
> authors can make their NiFi processors and such available under the
> appropriate licenses. If there are commercial (or other) entities
> looking to package such extensions with the official Apache NiFi
> distribution, they would be subject to the same terms of the License &
> Notice (L&N) of Apache NiFi as well as whatever extensions are added.
>
> Regards,
> Matt
>
> [1] https://www.apache.org/legal/resolved.html
> [2] https://cwiki.apache.org/confluence/display/NIFI/
> Extension+Repositories+%28aka+Extension+Registry%29+for+
> Dynamically-loaded+Extensions
>
>
> On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
> <an...@gmail.com> wrote:
> > Hi, Uwe,
> >
> > These look useful. However, typically custom processors are either Apache
> > 2.0 or MIT licensed. These don't seem to specify a license, but your
> > business rule engine (jare) seems to be GPL 3.0 licensed. I'm not sure
> that
> > fits with most uses of NiFi.
> >
> > Can you please clarify?
> >
> > Thanks
> >
> > -Matt
> >
> > On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de>
> wrote:
> >>
> >> Hello everyone,
> >>
> >> I just wanted to let you know, that I have created four processors for
> >> Nifi
> >>
> >> 1) GenerateData - generates random data (test data) based on word lists,
> >> regular expressions or purely random
> >> 2) RuleEngine - a ruleengine which allows to process complex business
> >> logic. But the logic is maintained in a separate web app and thus
> outside of
> >> the flow. If the logic changes the flow does NOT have to change.
> >> 3) SplitToAttribute - splits a single CSV row into flow file attributes
> >> 4) MergeTemplate - merges flow file attributes with an Apache Velocity
> >> template and writes the result to the flow file content
> >>
> >> Please give them a try and let me know your findings and thoughts.
> >>
> >> https://github.com/uwegeercken/nifi_processors
> >>
> >> rgds,
> >>
> >> Uwe
> >
> >
>
Re: new Nifi Processors
Posted by Matt Burgess <ma...@apache.org>.
Uwe G has made his processors available (thank you!) via his own repo
vs the official Apache NiFi repo; this may be directly related to your
point about licensing. Having said that, he is of course at liberty
to license those separate processors as he sees fit (assuming it is
also in accordance with the licenses he has employed). Apache NiFi
welcomes to its codebase Apache-friendly contributions (FAQ [1]), but
alternatively and even before an Extension Registry [2] is supported,
authors can make their NiFi processors and such available under the
appropriate licenses. If there are commercial (or other) entities
looking to package such extensions with the official Apache NiFi
distribution, they would be subject to the same terms of the License &
Notice (L&N) of Apache NiFi as well as whatever extensions are added.
Regards,
Matt
[1] https://www.apache.org/legal/resolved.html
[2] https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
On Tue, Feb 28, 2017 at 9:33 PM, Angry Duck Studio
<an...@gmail.com> wrote:
> Hi, Uwe,
>
> These look useful. However, typically custom processors are either Apache
> 2.0 or MIT licensed. These don't seem to specify a license, but your
> business rule engine (jare) seems to be GPL 3.0 licensed. I'm not sure that
> fits with most uses of NiFi.
>
> Can you please clarify?
>
> Thanks
>
> -Matt
>
> On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de> wrote:
>>
>> Hello everyone,
>>
>> I just wanted to let you know, that I have created four processors for
>> Nifi
>>
>> 1) GenerateData - generates random data (test data) based on word lists,
>> regular expressions or purely random
>> 2) RuleEngine - a ruleengine which allows to process complex business
>> logic. But the logic is maintained in a separate web app and thus outside of
>> the flow. If the logic changes the flow does NOT have to change.
>> 3) SplitToAttribute - splits a single CSV row into flow file attributes
>> 4) MergeTemplate - merges flow file attributes with an Apache Velocity
>> template and writes the result to the flow file content
>>
>> Please give them a try and let me know your findings and thoughts.
>>
>> https://github.com/uwegeercken/nifi_processors
>>
>> rgds,
>>
>> Uwe
>
>
Re: Aw: Re: new Nifi Processors
Posted by Russell Bateman <ru...@windofkeltia.com>.
I too find GPL to be confusing enough that I (and I am not alone)
consider it to be poisonous fruit that I simply do not touch.
I earn my living working as an employee developing software for
companies that sell it, or rights to use it, for money and do not
publish their product source code any more than Coca Cola gives away the
recipe for its flagship beverage.
As I understand it, if I consume a JAR that falls under GPL in my work,
even if I only consume the JAR's functionality and do not modify it,
however small and "insignificant" that JAR's contribution may be to the
whole, that use opens my employer to a lawsuit because my source code is
in essence and in fact built atop that GPL'd component.
Maybe my interpretation is born of irrational paranoia, but it's how it
looks to me. To me, GPL means software to be used by academics and
people who develop software for their health only.
Thoughts? (Yeah, this isn't really the forum for it.)
On 03/01/2017 04:40 AM, Uwe Geercken wrote:
> Hello,
> what would be the appropriate way to license the processors? Is it an
> annotation, a seperate license file or something else?
> To the GPL3: This is what wikipedia says:
>
> The *GNU General Public License* (*GNU GPL* or *GPL*) is a widely used
> free software license
> <https://en.wikipedia.org/wiki/Free_software_license>, which
> guarantees end users <https://en.wikipedia.org/wiki/End_user> the
> freedom to run, study, share and modify the software.^[6]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-blackduck2015-6>
> The license was originally written by Richard Stallman
> <https://en.wikipedia.org/wiki/Richard_Stallman> of the Free Software
> Foundation <https://en.wikipedia.org/wiki/Free_Software_Foundation>
> (FSF) for the GNU Project <https://en.wikipedia.org/wiki/GNU_Project>,
> and grants the recipients of a computer program
> <https://en.wikipedia.org/wiki/Computer_program> the rights of the
> Free Software Definition
> <https://en.wikipedia.org/wiki/The_Free_Software_Definition>.^[7]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-7>
> The GPL is a copyleft <https://en.wikipedia.org/wiki/Copyleft>
> license, which means that derivative work
> <https://en.wikipedia.org/wiki/Derivative_work> can only be
> distributed under the same license terms. This is in distinction to
> permissive free software licenses
> <https://en.wikipedia.org/wiki/Permissive_free_software_licenses>, of
> which the BSD licenses <https://en.wikipedia.org/wiki/BSD_licenses>
> and the MIT License <https://en.wikipedia.org/wiki/MIT_License> are
> widely used examples. GPL was the first copyleft license for general use.
>
> Historically, the GPL license family has been one of the most popular
> software licenses in the free and open-source software
> <https://en.wikipedia.org/wiki/Free_and_open-source_software>
> domain.^[6]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-blackduck2015-6>
> ^[8]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-wheeler1997-8>
> ^[9]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-redhat2000-9>
> ^[10]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-freecode2008-10>
> ^[11]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-mattasay2011-11>
> ^[12]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-waltervanholst2013-12>
> ^[13]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-blackduck2013-13>
> Prominent free software programs licensed under the GPL include the
> Linux kernel <https://en.wikipedia.org/wiki/Linux_kernel> and the GNU
> Compiler Collection
> <https://en.wikipedia.org/wiki/GNU_Compiler_Collection> (GCC). David
> A. Wheeler <https://en.wikipedia.org/wiki/David_A._Wheeler> argues
> that the copyleft provided by the GPL was crucial to the success of
> Linux <https://en.wikipedia.org/wiki/Linux_kernel>-based systems,
> giving the programmers who contributed to the kernel the assurance
> that their work would benefit the whole world and remain free, rather
> than being exploited by software companies that would not have to give
> anything back to the community.^[14]
> <https://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-14>
>
> The ruleengine is under GPL3. So users acan freely use, embed or share
> it. It is only derivative work, that needs to be distributed under the
> same lisence terms. So what would be the problem with the Nifi
> processor? Can somebody explain that to me.
> Also, I would be glad to have a quick explanation of what the core
> differences or advantages are of Apache 2.0 versus GPL3. That would
> help me understand the issue better.
> Greetings and thanks for feedback.
> Uwe
> *Gesendet:* Mittwoch, 01. M�rz 2017 um 03:33 Uhr
> *Von:* "Angry Duck Studio" <an...@gmail.com>
> *An:* users@nifi.apache.org
> *Betreff:* Re: new Nifi Processors
> Hi, Uwe,
> These look useful. However, typically custom processors are either
> Apache 2.0 or MIT licensed. These don't seem to specify a license, but
> your business rule engine (jare) seems to be GPL 3.0 licensed. I'm not
> sure that fits with most uses of NiFi.
> Can you please clarify?
> Thanks
> -Matt
> On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uwe.geercken@web.de
> <ma...@web.de>> wrote:
>
> Hello everyone,
>
> I just wanted to let you know, that I have created four processors
> for Nifi
>
> 1) GenerateData - generates random data (test data) based on word
> lists, regular expressions or purely random
> 2) RuleEngine - a ruleengine which allows to process complex
> business logic. But the logic is maintained in a separate web app
> and thus outside of the flow. If the logic changes the flow does
> NOT have to change.
> 3) SplitToAttribute - splits a single CSV row into flow file
> attributes
> 4) MergeTemplate - merges flow file attributes with an Apache
> Velocity template and writes the result to the flow file content
>
> Please give them a try and let me know your findings and thoughts.
>
> https://github.com/uwegeercken/nifi_processors
>
> rgds,
>
> Uwe
>
Re: new Nifi Processors
Posted by Angry Duck Studio <an...@gmail.com>.
Hi, Uwe,
These look useful. However, typically custom processors are either Apache
2.0 or MIT licensed. These don't seem to specify a license, but your
business rule engine (jare) seems to be GPL 3.0 licensed. I'm not sure that
fits with most uses of NiFi.
Can you please clarify?
Thanks
-Matt
On Tue, Feb 28, 2017 at 4:47 PM, Uwe Geercken <uw...@web.de> wrote:
> Hello everyone,
>
> I just wanted to let you know, that I have created four processors for Nifi
>
> 1) GenerateData - generates random data (test data) based on word lists,
> regular expressions or purely random
> 2) RuleEngine - a ruleengine which allows to process complex business
> logic. But the logic is maintained in a separate web app and thus outside
> of the flow. If the logic changes the flow does NOT have to change.
> 3) SplitToAttribute - splits a single CSV row into flow file attributes
> 4) MergeTemplate - merges flow file attributes with an Apache Velocity
> template and writes the result to the flow file content
>
> Please give them a try and let me know your findings and thoughts.
>
> https://github.com/uwegeercken/nifi_processors
>
> rgds,
>
> Uwe
>