Author Topic: FPP, OPP, what's the deal??  (Read 623 times)

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
FPP, OPP, what's the deal??
« on: May 15, 2019, 10:11:17 PM »
Grab a cup of coffee and you may want to sit down, this is a bit of a long post.  It is partially based on an email I sent out to the FPP contributors this morning, but I also wanted to post a thread here so I've removed a few irrelevant parts and added others more relevant to the audience.

For those of you that aren't on FaceBook and don't stay current on some of the other forums, I wanted to post a thread to bring you up to speed on something the FPP developers were made aware of recently.  I also wanted to clarify what is going on and our stance.

Recently, it has come to the attention of the FPP developers that the FPP repository and all other FPP related repositories under the FalconChristmas github organization have been forked by Jeremy McElroy who runs the getjboards.com online store.  This mass-fork also currently includes some other repositories such as my MatrixTools FPP plugin.

Forking our repositories itself is not an issue, it's what git, the GPL, and Open Source are all about.  The problem that we have with this is that Jeremy has decided to rename his fork of FPP to 'OPP' aka the 'Open Pixel Player' and started systematically going through and removing references to FalconChristmas github, FalconChristmas.com, and has even removed the list of FPP developers from the credits page and replaced this info with a line that says merely that OPP is a 'derivative' of FPP.  He has also registered the domain name "openpixelplayer.com" to distribute his forked copy of software.

For those who haven't been around 6 years since the beginning, here's a brief history of FPP.  David Pitts originally created FPP back in 2013 with help from Tony (mykroft).  I started working with them shortly afterwards and before the end of 2013, David turned over development of FPP to me so that he could concentrate on the hardware side of things, making great controllers for the lighting community.  Along the way, Dan started diverting some of his attention from working on xLights and came over to FPP to help and over the past 2+ years, he has totally revamped the BBB pixel and matrix support and also made numerous major enhancements and optimizations to FPP.  David created the PiCap for the Pi and F4-B/F16-B capes for the BBB.  The original octoscroller design was created by Trammell Hudson and published on oshpark and we used Trammell's design for the original octoscrollers we distributed for use with FPP.  A couple/few years back, Dan wanted to bring the BBB cape support to the next level and with David's blessing, Dan created new BBB capes most recently adding the new F8-B, F32-B, F8-PB, F40D-PB, and PocketScroller, all of which have been designed to work with FPP.  The slim "profits" from sales of the PiCap and Dan's boards help defer a little bit of the development costs as we continue to enhance FPP to support additional hardware and add features.

Over the past year or so, Jeremy has started creating and selling his own clone versions of most of these boards as well as the other pixel and serial expansion boards for the F16v2/F16v3/F4v3/F48 which are sold in David's PixelController.com store.  After Dan's recent group buy for the new BBB boards, Jeremy started making cloned versions of some of those boards and started selling them in his store, again undercutting the group buy price partially by removing some features and creating what we believe are inferior products.

David and Dan reached out to Jeremy and asked that he not take money out of the FPP developers' pockets by creating the knock-off clone boards and selling them cheaper trying to take away sales of the PiCap and BBB-based boards.  At first Jeremy said he would stop selling the new BBB boards.  Dan added some code to FPP to detect cloned boards and limit their capabilities.  At this point Jeremy decided to take the FPP code, clone our git repositories, and start removing our names and Falcon/FalconChristmas references from the source and UI.

The GPL allows this kind of copying of source code as long as our original copyright notices are kept in place and the modified code is GPL and the source code to any distributed work is also distributed allowing for potential enhancements to flow back into the original code.  Most of the code in FPP is covered under the GPL except for some parts we have included from others.  We are now at a point in time though where we believe that releasing FPP under the GPL may not be the best license for the community.  In this case, the GPL has allowed Jeremy to take FPP and start distributing a renamed copy which will just fragment the community.  We would not condone it if this were to happen to xLights or Vixen and don't condone it happening to FPP.  I have started a discussion going with Dan and the other minor FPP contributors to get their input on re-licensing FPP using a little more restrictive license such as the Creative Commons BY-ND (Attribution - NoDerivative) License.  We have no desire to "take FPP private", we want FPP to remain Open for the community to use and enhance.  The FPP source will always remain Open Source.  Switching to something such as the CC BY-ND license would allow us to prevent others from taking our source code and renaming it and distributing a competing, fragmenting version of the Falcon Player.

I wanted to give our FPP users a heads up on what is going on and our view point on the issue.

FPP is and will always continue to be a free, Open Source product.  I have made every effort over the past 6 years to keep it so and I will continue to do so.


For further info, backstory, you can visit the following links:

https://www.facebook.com/groups/xLights/permalink/2254514004584342/

https://diychristmas.org/vb1/showthread.php?9871-No-more-FPP-for-the-BBB  (this thread has a misleading subject as noted in the thread)

http://doityourselfchristmas.com/forums/showthread.php?53022-Wow-all-I-can-say-is-Wow

Chris Pinkham aka CaptainMurdoch
-
Chris

Offline AAH

  • Hero Member
  • *****
  • Join Date: Jul 2014
  • Location: Australia
  • Posts: 728
  • Kudos: 19
  • Blinky blinky blinky
    • I love blinky lights
Re: FPP, OPP, what's the deal??
« Reply #1 on: May 16, 2019, 01:38:27 AM »
Thanks for sharing the info Chris and I don't envy you and the FPP team with the choices that you have to make. I knew about some of the nasty goings on through conversations with Dan and then the forking that took place via David's FB post. It is fairly criminally wrong to use what has been developed by the community and rebadge it as being your own development. If the code development had been done as an addition to the actual FPP code then that is all well and good. The step that made it something of a clear violation of trust is when a board design is blatantly copied from the person who developed it. In the case of Dan's boards he put in the effort of designing the boards and then writing the code to support them. For someone to just duplicate the boards is just wrong. I have had personal experience of blatant board copying. Someone bought 1 of my boards off of me as a kit and a few weeks later released a duplicate board right down to appearance and dimensions.

Offline K-State Fan

  • Sr. Member
  • ****
  • Join Date: Dec 2014
  • Location:
  • Posts: 313
  • Kudos: 5
Re: FPP, OPP, what's the deal??
« Reply #2 on: May 16, 2019, 05:23:03 AM »
Thanks for the info

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,586
  • Kudos: 92
    • KulpLights.com
Re: FPP, OPP, what's the deal??
« Reply #3 on: May 16, 2019, 06:51:36 AM »

I've stayed fairly quiet in all of this so far...  it's realy not my style to get involved in these types of arguments.  I tend to be the "speak softly and carry a big stick" type of person.   In this case, my "big stick" likely was the trigger that started a lot of this, and for that I sincerely apologize.


To give a bit more "recent context" in addition to the FPP history that Chris provided:  as many of you know, I've run a yearly group buy on controller boards for the BeagleBones.   2 years ago, I did one for the full size Beagle which included the original F8-B and F32-B.   Last year, after the introduction of the PocketBeagle, I designed the PocketScroller and F8-PB to leverage the PocketBeagle and sold those in a group buy.   This year, I added the F40D-PB and then did some major updates to the other and offered 5 different boards as part of the group buy.   That is a LARGE undertaking.


As part of the group buy boards this year, I decided to "upgrade" the functionality of the boards a bit to make them closer to full featured controllers with some of the features that the "high end" boards have.  Obviously, the big one from the Falcon's is the cute little OLED screen.  At about $3 for an OLED and something that doesn't even need to ship with the board so adds only like 10 cents to the cost to manufacture the board (4 pin header), it was pretty much a no brainer.  However, having a cute little display that doesn't display anything isn't very useful.  Thus, I've spent 10's of hours working on the software side of things to make the display useful.  It's way more complex than you think. The pictures you have seen in the forums are only the "first page" of the display and that was pass one of the code.    As I was waiting for the group buy to complete, Ken at Wired Watts contacted me and offered to buy a bunch to stock in his store IF I put a "test button" on the board.   Thus, I spent some time looking into that and ended up adding 2 buttons to all the boards and writing a complete 2 button menu system for the OLED.   For those with my group buy boards, the OLED displays the basic network/status info by default, but press a button and it does SOOO much more.   Someone really should create a small video showing the functionality on the OLED.   There is a lot there.   Note: the group buy boards also have various sensors (Voltage, temperature) that display on the OLED.


Anyway, the above functionality was specifically written for the folks that purchased boards in my group buy.   They are my customers.   They should be the ones that get the most benefit from that work.  The hope really was that the group buy folks would be the first people to really experience those features.   Jeremy then comes along, designs a cheap imitation, and has his customers start using my new functionality before I can even get my boards manufactured and shipped.  Yes it pissed me off.   This is all code I spent a lot of time developing for MY boards and my users and he starts ripping it off even before I could get it into the hands of my users.


This is where the "big stick" comes in.   In a couple of posts on the forums, I did alude that we were investigating ways to limit functionality on Beagle based boards.  I investigated a bunch of options.   I will admit that Dave and I did talk about a nuclear option of completely removing the "pinout" files for all the BBB capes which would disable everyones BBB capes.  We would ship out a virtual "firmware" for free to anyone that had one of the "good" BBB capes (which, to be honest, isn't a ton of folks).  That was a last resort and certainly not something we wanted to do.  We eventually settled on a "restricted mode" for BBB capes.   What does that mean?  Well, we turned off support for DMX.  This wouldn't affect Jeremy's cheaper board as this doesn't even have DMX at all.   Not a LOT of users use the DMX on the BBB capes anyway as it requires creating a custom cable.   The RJ45 is generally better used for a 4 port differential receiver.  Anyway, likely doesn't affect many people.  The OTHER restriction was to limit it to 200 pixels per port.   We did talk about a lower number, but 200 felt reasonable.   On the BBB, that is still a LOT of pixels.   I know there are many people who run entire shows with 1k's of pixels that never go above 200 pixels per port.   Heck, it wasn't that long ago that controllers couldn't span universes so ports were limited to 170.  Anyway, a restriction enough to draw attention to the matter, yet still result in a capable controller.   However, we also wanted to make sure that any of Jeremy's customer could come to use and "fully enable" their boards.  That functionality is there.   If any of his customers would like the restrictions removed, we can work something out.


Anyway, with 2.7, we enabled the restrictions.  His customers are obviously affected.  They see a nice red warning on the BBB strings page.   And that was the trigger for his fork.   Rather than have his customers contact us to work something out (which would involve educating them of his business practices), he decided to fork. So yes, this whole mess is stems from actions I took and thus some of the blame can be put on me.   I'm really sorry for all the drama that has unfolded the last couple days.  It's "not fun", to put it mildly.


Basically, if I'm developing some new features specifically for my boards and my users, it seems reasonable to me that my boards and my users should be able to experience those features first.   THEY are the ones I'm trying to please.  Yes, it was all GPL so someone can definitely grab the code and ship it faster than me.  But it comes down to an age old saying:  "just because you can do something doesn't mean you should do something."   To me, Jeremy doesn't understand that at all.  He focuses on the "can" and really has a "can = should" viewpoint.   However, there is another cliche that comes to mind:  "Don't bite the hand that feeds you".   If FPP and xLights are important for your ability to sell your products, why the hell would you piss off one of the top contributors to BOTH of those projects.  Seriously doesn't seem wise to me.


Anyway, word to the wise: please support the reputable vendors.  Obviously Dave's Falcon controllers are top notch.  Yes, my boards somewhat compete with his, but for standalone boards, his really cannot be beat.   For other supplies, consider the vendors carefully.   Boscoyo is excellent.   Wired Watts is excellent.  If your in the southern hemisphere, Hanson is a good guy. (well, he's still a good guy even if you're in the northern hemisphere, but a bit harder to get ahold of)   There are a bunch of other good vendors.  DIYLedExpress, CFOL, etc...  Please support them.  They deserve it.
« Last Edit: May 16, 2019, 07:03:29 AM by dkulp »

Offline Driver

  • Newbie
  • *
  • Join Date: Sep 2014
  • Location: Brisbane, Australia
  • Posts: 11
  • Kudos: 0
    • Brad's Xmas Lights
Re: FPP, OPP, what's the deal??
« Reply #4 on: May 16, 2019, 07:23:15 AM »
With AusChristmasLighting Brisbane meet this weekend; and Sydney at the end of the month; rest assured I'll be recommending people to stick to genuine falcon boards + FPP; and not any knock off clone.

You guys are the ones who have done the hard yards over many years for the Xmas Lights community.
BradsXmasLights.com - Wi-Fi Interactive Display, Brisbane, Australia

Offline pixelpuppy

  • Hero Member
  • *****
  • Join Date: Aug 2015
  • Location: Dallas, TX
  • Posts: 1,420
  • Kudos: 45
Re: FPP, OPP, what's the deal??
« Reply #5 on: May 16, 2019, 09:22:58 AM »

I understand and support the position FPP developers are taking.   Countless man-hours have gone into the development for FPP (and continues to be) and is absolutely worthy of proper recognition and protection.  But I do have a question....

... Well, we turned off support for DMX.  This wouldn't affect Jeremy's cheaper board as this doesn't even have DMX at all.   Not a LOT of users use the DMX on the BBB capes anyway as it requires creating a custom cable.   The RJ45 is generally better used for a 4 port differential receiver.  Anyway, likely doesn't affect many people... 


I guess I'm one of those few people who use DMX on the Genuine Kulp capes and on my Falcon controllers too.  ???   Every one of my BBB pixel capes has a small 4-port dmx board hanging off of it to control non-pixel floods/icicles/strobes/etc.   I'm not sure if I'm reading that correctly.  Is that saying DMX serial output will no long be availalbe on FPP 2.7 and above? :o
-Mark

Offline dkulp

  • Moderator
  • *****
  • Join Date: Sep 2013
  • Location: Framingham, MA
  • Posts: 1,586
  • Kudos: 92
    • KulpLights.com
Re: FPP, OPP, what's the deal??
« Reply #6 on: May 16, 2019, 09:33:33 AM »
I guess I'm one of those few people who use DMX on the Genuine Kulp capes and on my Falcon controllers too.  ???   Every one of my BBB pixel capes has a small 4-port dmx board hanging off of it to control non-pixel floods/icicles/strobes/etc.   I'm not sure if I'm reading that correctly.  Is that saying DMX serial output will no long be availalbe on FPP 2.7 and above? :o

Only if FPP detects it as an unsupported cape... so it depends on the cape.  In general, unless you've made "modifications" to my previous capes or Dave's previous BBB capes, it should continue to be considered a supported cape.  And even if it does detect it as unsupported, please contact me and I'll be more than happy to provide an updated "firmware" for any of my past boards which would fully re-enable everything. 

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 9,856
  • Kudos: 214
Re: FPP, OPP, what's the deal??
« Reply #7 on: May 16, 2019, 12:03:01 PM »
This immediate issue appears to be resolved for now.  Rather than put it in my own words, I'll link to David's post on DoItYourselfChristmas.com:

http://doityourselfchristmas.com/forums/showthread.php?53026-I-am-so-sorry

I'm happy that we've been able to come to a resolution.  It still has opened our eyes a little and we will likely still continue forward to investigate options for re-licensing FPP in the future to allow FPP to remain Open Source and freely available but also try to prevent fragmentation of the community.

I'm locking the thread now.  If you have questions, PM me and we can either have a discussion in private or we can start another thread for non-OPP talk.

 

Back to top