End of an Era

[freezy]

As you might know, there have been disagreements lately between @lucky1 and myself about how to handle DMD coloring in the future. There are a few technical things I'd like to explain, but also a bit of history and how our opinions differ. I try to be as neutral as possible, everything described is to the best of my knowledge, and I try not to exclude anything of relevance.

 

I'm an open source enthusiast. Everything I develop in my free time, I publish on GitHub for others to use freely. There is only one thing I want in return: If you use my code in a project, your project must be open source as well. The goal is to promote free software (free as in "freedom", not "beer" ;)). For example, it avoids that a corporation grabs the software, improves and sells it, without publishing their improvements (they're allowed to sell it). All this is legally described in a license called the GPL. It's quite a common license, for example the Linux kernel uses it, but also smaller projects like the Kodi media center (the first open source project I contributed to).

 

Most of my pinball-related projects are GPL-licensed. Dmdext is GPL, VPE, even the source of vpdb.io is GPL and fully available on GitHub. Doing open source for backend-services has its risks, people find vulnerabilities quicker, but in my experience, people seek more often to create than to destroy (or "rip off"). Neither dmdext nor VPE would be what they are today were they closed source.

 

Lucky1 had a different experience. His first firmware for PIN2DMD was open source, and soon some guy came around, used his code and loaded it on another device he built and sold (and claimed credit for). This wasn't to be tolerated, and soon after, the PIN2DMD firmware became closed source. Not only that, while you were free to build your own PIN2DMD hardware, the firmware had to be purchased from Lucky1. So the firmware became commercial software and its revenue was donated to a charity of Lucky1's choice (and still is today).

 

To understand why that's relevant, let me explain dmdext's origins. After I built my cab, I decided to purchase a PinDMDv3 from VirtuaPin. Russ (the developer who was commissioned to create VirtuaPin's PinDMDs) had already written a driver for VPM, so it was plug and play. What Russ created was an API that would be used when loading DmdDevice.dll (if available), and output the frame data to the hardware device. Lucky1 also used this interface for the PIN2DMD.

 

But my DMD didn't work with all the other simulators (PinballFX, Pinball Arcade, and Pro Pinball). So I looked at how the PinDMD3 driver was done, and started screen grabbing the PinballFX DMD to be able to use my hardware DMD in those games. But because development takes time, and I didn't want to spend time coding on my cab, I implemented another output driver: The virtual DMD. I put some effort to make it render nicely (later on, @vbousquet improved this shader even more), since I was gonna be looking at it every day. This was the inception of dmdext.

 

Since PinDMDv2 devices were still out there, I also implemented an output driver for PinDMDv2, PinDMDv1, and later PIN2DMD. The architecture of dmdext was designed in a way that it was easy to add new input or output drivers: Implement a bunch of interfaces depending on the frame formats, add the config, done.

 

I largely ignored VPM/VPX, because there were already drivers for that. That was until Lucky1 approached me and introduced me to his colorization project. At that point, PIN2DMDs where already being used in real pins, and there was more demand in colorized games than available. So Lucky1's idea was in order to find more colorization authors, the project should be accessible to more people (LCD and PinDMD3 owners, in the virtual pinball community).

 

It was already established that real pin owners were paying for getting access to the colorization files. However, since that wouldn't be a realistic model for the virtual pinball community, colorizations would be free for v-pins (but for v-pins only). In order to prevent real pin owners from using the files from the virtual pin community, Lucky1 used a different format.

 

So the idea was that I would port the colorization code into dmdext in a way difficult to port back to C which is the programming language usually used for embedded devices (at that time, the coloring was done on the actual PIN2DMD device, through the firmware). And I did exactly that, commented the code in Swiss German so not even Google translate would output anything useful, and spent weeks long debugging, until we finally introduced DMD coloring in dmdext 1.7.

 

And the plan worked. DMD coloring took the community by storm, and out of thousands of new users, a handful of new coloring authors emerged.

 

With time, Lucky1 added new features, and those features were also ported back into dmdext, mainly by other contributors like @DJRobX and @Funkyman. It usually worked like that: A new feature dropped, and PIN2DMD users started testing it. Remember, there were two implementations: Lucky1's original, closed-source version, and the open source dmdext port. Once the feature was stable, Lucky1 would send me his changes to be ported back to dmdext, so LCD and PinDMD3 users could use it too.

 

The very inconvenient thing though was that there was a significant time gap between new features in PIN2DMD, and their port into dmdext. This was mainly because I was (and still am!) busy with VPE, but also because it's hard for me to get into the context. See, I don't follow every new coloring feature, and without some documentation, it's hard to know what changed, let alone debug problems.

 

But we always managed to keep up, until version 1.10 which introduced 64-color support (thanks to the efforts of Lucky1 and Funkyman).

 

Then, in March, we got a question from @zedrummer, who was working on a new, cheaper hardware DMD and wanted to integrate it with dmdext. I pointed him into the right direction, which soon ended up in a PR which is still open to this day, due to a few changes I wanted him to implement.

 

Shortly after, I got an email from Lucky1, titled "copycats", with a request to add a clause to the dmdext license that forbids anyone to use dmdext's coloring code for "other projects" without the approval of him and Steve (the author of the PIN2DMD editor).

 

At first I thought this might have something to do with the zedrummer's new DMD, but after inquiring what this was all about, Lucky1 pointed me to this thread where somebody got dmdext running on a real pin (for the record, that was when I first learned about that project).

 

See, once you publish code in a given license, you cannot retroactively change that license. The "deal" I had with Lucky1 was that it should be difficult for non-programmers to re-implement coloring, but the license was clear from the beginning. That sooner or later someone would come and port it back into another language to use in other projects has always been a risk.

 

In the email, Lucky1 mentioned that the problem of such a project was that the "donations [to the coloring authors] can be circumvented", and he announced that in the future, the VNI files would be encrypted so they couldn't publicly be decrypted anymore. He proposed to use a different DLL than dmdext's DmdDevice.dll for VPM and use dmdext's DLL for RGB24 output. It only dawned to me until later what that actually meant.

 

Around the same time, another thing happened: @Dazz got an email from an IP holder, where they inquire whether VPU is selling colorizations for real pins (they are not). Along with a note that redistributing their IP (in this case, the frame data of their games) would be illegal.

 

From my understanding, neither the VNI nor the PAL file were including any of the original frame data. The PAL just contains color palettes, and the VNI contains hashes and the coloring data that was added by the author. The only data that links back to the original frames are CRC32 checksums, which are not, by any definition, proprietary IP.

 

But be that as it may. One more reason to further restrict the coloring, Lucky1 spent two weeks implementing his DRM, which resulted in the new PAC format you probably know by now. There were two more problems to solve:

 

1. The old VNI/PAL files had to disappear
2. It had to be done quickly

 

The first point was more or less accomplished by asking all the coloring authors to update their files (i.e. remove the PAL/VNI and replace them by PAC). The second point was more difficult, because of dmdext's notoriously long periods of back porting code (although to be fair, Funkyman is still active and would have been a lot quicker compared how long it took for 64-color support).

 

So, why not get rid of dmdext entirely? But dmdext is still useful for the nice LCD rendering. So Lucky1's approach was to change the paradigm: Instead of dmdext's DmdDevice.dll, everybody should use his own DmdDevice.dll, which does the coloring and loads dmdext for the LCD output. It was only then when I started to understand the consequences, and the more I thought about it, the less I started to agree with it.

 

First of all, dmdext is GPL-licensed. It's actually illegal to ship a non-GPL binary together with GPL-licensed code. Lucky1 is doing exactly that.

 

The second problem that I have with this approach is that it's what's called a hostile fork. Lucky1 is actually instructing users to not use the original dmdext project anymore, but his own modified copy of it (his "fork"). He's creating a competing product, based on dmdext. This has a negative impact on the community:

 

• Confusion. "freezy" is suddenly not freezy's anymore, but Lucky1's "freezy". Years of forum posts and videos become invalid. An enormous effort has to be done to rectify this.
• Control. All new changes that go into dmdext will have to go back into Lucky1's fork, otherwise they won't be available for users using the fork. That makes Lucky1 the gate keeper for new features (for a project he didn't create).

 

The third problem is compatibility. Any new hardware support that goes into dmdext must be signed-off by Lucky1 before it gets the coloring feature. Imagine a newer, cheaper technology for a DMD, like zedrummer's project. That would be a benefit for the community, right? Well, coloring support would be at the mercy of Lucky1.

 

Finally, the fourth problem is that it's just bad software design. It doesn't separate concerns, resulting in a chain of programs that doesn't make logically any sense. Coloring cannot be used for anything but VPM. I'm working on VPE, and I can't use an API made for DMD hardware to implement coloring, because that would mess up everything.

 

Well, there are three solutions for these problems:

 

1. Lucky1 publishes his coloring code as open source. This would make it legally compatible and give us a way to port it back into dmdext. It would also allow us to provide cross-platform support when VPE comes out.
2. We change the license of dmdext to something less restrictive, for example MIT or BSD. That's pretty hard to do because the copyright of the dmdext code still applies to each individual contributor, and I cannot change the license without their consent. So I would need to contact them each individually.
3. A compromise: we create an API that does coloring only (an API is like a contract of how different pieces of software communicate with each other). The API supports all the frame formats used today (not just RGB24). Dmdext implements that API. Lucky1 converts his code to match the API as well. Dmdext loads any library that implements the API at runtime, if available. But both programs need to be shipped separately, in order to respect the GPL.

 

Now, if you look at Lucky1's motives why solution one is unlikely to be happening, you'll see two patterns:

 

1. He despises "copycats". It seems likely that the main purpose of the DRMed PAC format is to lock out any future hardware DMDs the community might come up with.
2. He wants to "protect" the coloring authors. Or otherwise said, coloring authors still need to be able to sell the colorizations to real pin owners.

 

I think we can all sympathize with pattern one. It's always hard to see others profiting off your work. But I really don't think that DRM is the solution. It didn't work in any of the entertainment industries, and they have much larger budgets. It nearly always goes at the expense of the user. Another reason why I personally won't spend a second on DRMizing anything is that the task sucks, and I rather focus on the fun and innovative parts of my projects (if possible, of course).

 

About pattern two, I'm very skeptical. I talked to coloring authors, and I don't think the compensation is that important. None of us here get compensated, and we all pour a ridiculous amount of time into the hobby. We're doing just fine. If you're in for the money, you're better off investing in some NFT pyramid scheme or buying some crypto (now is a good time, I heard, haha!).

 

Additionally, DRM can and will be cracked. If you encrypt stuff, you need to decrypt it with a key. Unless you issue a personal key for every user, you need to store it in the binary you're shipping. That means it can be extracted. Providing individual keys doesn't solve key sharing. Unless you have some kernel-level shit going on, it's just impossible to protect.

 

Solution number two is also very unlikely. It boils down to changing the license of my project so others who don't even contribute to this project can make money. With all the consequences that come with it, like tensions between community members, VPU getting angry letters, more complexity for the user. That's something I'm opposed against, not in favor of.

 

I'm trying to pitch solution number three for a few days now. A couple of other software developers from the community like @NailBuster and Funkyman also chimed in why this is the solution to go, under the circumstances. Lucky1 announced that he won't work with me anymore because I called his arguments BS. And sadly, through intermediary communication with Funkyman, Lucky1 insists on shipping a single binary with both his proprietary code and dmdext, and wants me to change the license.

 

So I guess we'll part ways. I'll keep PAL/VNI support in dmdext for some time, but PAC colorizations will only be available for current devices. Dmdext will be used against my will. VPE will most likely not support colorizations at all.

 

All that is left for me to do is to appeal to the coloring authors to make a statement about their "donations" from real pins. Guys, if you're really in for the money, so be it. But if you're not, please speak out now, maybe there's a still chance for solution three.

 

Cheers,

 

   -freezy.

 

[MrGrynch]

Wow.. it's a shame its come to that.  I hope you guys work something out.  Thank you @freezy for all you and other do for this community out of a love for the game.

Edited May 21, 2022 by MrGrynch

[NailBuster]

I'm guessing a workaround/solution now would be to get color-authors to 'push' for the coloring tools/editor to allow export-to-legacy vni/pal/etc files.  That way it will work with current 'freezy' dmdext and future revisions(next gen).   So hopefully color authors can choose not to add the new DRM stuffs then if they choose.

 

 If the color author only want $$$ then they can keep them private/commercial...and maybe after a while they may choose to release a community-friendly version of legacy files (ones that will work with open-source 'freezy' dmddevice.dll).

[bord]

Thanks @freezy for the well-reasoned explanation. Really appreciate your efforts to keep things open source.

[jeffh]

freezy - just want to chime in here and take the opportunity to thank you as well for all you have done and continue to do for the community.

 

Also, thanks for taking the time to explain what is transpiring. Unfortunate to say the least.

 

 

[SoupNazi]

I support you Freezy, you have done a lot of amazing work, which me and many vpin users have loved when it comes to color dmd! I hope that there will be a solution , so that you can keep going with dmdext and 64 colors support for LCD/vpins. Best wishes! 👍

[InfntyX2]

Unfortunately it always seems like for any person/group that has something awesome to share, there will always be some cretin(s) that will try to take advantage and profit off someone else’s hard work.  Some people just don’t have a conscience nor a soul.  I see the points from both sides knowing only the high level arguments.  I hope you can get things worked out.  In the meantime, I want to personally thank you for all your creativity, talent, and heart.  You help make this such an awesome hobby for so many people!

[Nikodemus]

Thank you Freezy for all you’ve contributed and for the detailed explanation. I’m just sad that the situation has developed as it has and will hope that a solution can be found. Best wishes.

[ViriiGuy]

I am behind Freezy on whatever he feels needs to be done.

[Thalamus]

Thanks @freezy for this thorough post about what is really going on. I've always been the open source guy myself; but, well, my code is shit Love you ❤️

I still hope that this can be resolved in the best possible way for the community. I really hope that your "last" suggestion can come through, though, I 'm now getting worried. Or - well, am I ? I still got a very well working install of the freezy in my cab and it works very well with the collection of vni/pal files I've already collected. I have no no real plans for "jumping the ship"; so to speak ... even though I got a beta of roadshow pac. For me, it would just feel wrong - starting to use the lucky1's version w/pac at this time.

[greatjava]

Thanks for all your hard work and keeping things open source! New to the hobby and surprised to see such a mix of closed and open source working together fairly well (well, until this example). Most my career has been working with open source tools/libraries and can't agree more with your views above.  I had to laugh at the notion of a checksum value being IP! I was wondering what rationale was behind the vpforums takedown of colorized files.  Colorized DMD is cool, but I agree with you, spending time on VPE sounds WAY more fun! I only recently tried out colorizations and was really surprised to see they were for sale for real pins - seems like a niche solution in a small market.  To your point - this isn't a great hobby to get rich at . Sorry you have to waste time on fighting such matters!

[gtxjoe]

It’s a shame to see this happen within the VPinball community. It’s all about having respect among developers and authors.   Freezy has made efforts to work this out with lucky
 

I hope lucky will reconsider and make the right decision to not illegally package his coloring project with a fork of freezy’s GPL licensed dmdext tool

[Smaug]

I really appreciate the transparency, and the history here. I agree with Freezy and Nailbuster, and thank you to everyone who continues to give free support or content to this wonderful hobby. 

Edited May 20, 2022 by Smaugdragon

[MydknyteStyrm]

As a color author for three tables now with a fourth in the works, I can say that compensation for the real pin2dmd files hasn’t exactly been a second income. I did the colors for TFTC, Batman and Cirqus out of the love I have for my own VPin, and it was an actual perk to find out people would pay for their real table’s DMD. I haven’t updated my files to the PAC format yet and it looks like I won’t at this point. I’m not sure what’s the whole deal here, but it sounds like Lucky1 is running something that doesn’t agree with the VPin community. I’m for whatever the masses in the VP world need, not the real pin users. Thanks Freezy for everything you’ve done to catapult this hobby into new territory. I await what happens next. As of now I won’t be selling my files anymore to the real pin world. 

[JasonDH]

Thank you freezy for everything you do for this hobby. I hope both parties find a solution and I support open source and the transparency that goes with it. 

[bzimmermann1000]

So sad to see the separation of two of the most brilliant people in this community. I only wish the best ethical outcome for the sake of the hobby and the people who are involved. Thanks for all your hard work, I ultimately hope this gets sorted out in the end with the sake of money behind the morals of our hobby.

[Ashram56]

Just to clarify one point in DRM: the new colorization files are encrypted using a unique key which is bound to the HW (actually the same key used to register pin2dmd firmware). So yes author need to provide each user with an encrypted set of files. 

 

At least this is the case for real pins

 

The most active colorization authors already made the transition. So I guess they do see the benefits of this architecture. 

 

That said, encrypting the virtual pin files is definitely not going to work on the long run (not sure how it can even work)

Edited May 20, 2022 by Ashram56

[flpennstater]

As an Engineer, I'm always going to side with open source and posting on Github

[Neil82591]

I appreciate all the hard work that everyone puts into this VPin community. The countless hours and heart and soul poured into the open source used in the community is amazing. I hope everyone can find a way to work things thru as the VPin community just grows and grows and that brings in new generations of coders developers and new players and even real pin owners into this wonderful hobby we cherish. 
 

Thank you all and I hope we can continue to see the increasing level of work that creates such amazing experiences for us all!!

[sudsy7]

I hope whatever final solution is implemented will allow for timely updates as new Pin2DMD features are developed.  Obviously, it's a difficult task without a dedicated caretaker integrating changes.

[MikeDASpike]

Thanks for the background information and all the good you and everyone else brings to us.

It would be a shame if VPE doesn't support colorisation, but I understand your point.  I still hope that you will implement the pindmd3 hardware for it.

 

Keep up the good working. And goodluck to the complete VPE dev team. I hope this doesn't delay anything for that project, as I'm looking forward for a long time to use it as an end user.

 

 

 

 

[bushav]

I refrained from updating to PAC thank goodness. I felt there was bad juju going around when the VNI/PAL files started disappearing. I did a lot of work on Batman Forever and can say that Lucky1 hasn’t tried to get me to pull down my files from the linked repository. I have no expectations of “receiving” compensation of any kind so anyone is free to use what I have done. It was just fun and rewarding and a good way to give back. 
 

please authors, find a way to keep this moving in the tradition of everyone helping each other. If it becomes closed source we are at the mercy of one persons health, interests, feelings, motives etc etc. 

[drkhrse]

thanks for the info Freezy and especially thanks for the hard work you put into this and into VPE.

[LynnInDenver]

I've been... reluctant to even look at what Lucky was doing with the new PAC format - it struck me as being a lot of extra pieces just to support a "better" format. It's really disheartening as he shows that, unfortunately, Noah at VPF was actually right about him on a certain level, and while it is the "broken clock is still right twice a day", it still annoys me that this is the case.

 

Lucky needs to show a more compelling reason than "colorization authors need to make money from physical pin owners" to make changing the license worth the effort.

 

I can fully understand not wanting to support colorization right now in VPE - Lucky added a LOT of added complexity to even attempting to support colorization, and given the extra noises being made on it lately, this is potentially poisoning the well in terms of colorization going forward.

 

...so, in the spirit of this, I will still not be upgrading to the mess that Lucky is making of the software. I'm also going to not use Pin2DMD for any pinball we may eventually purchase that has a DMD - I'd rather pay the premium to ColorDMD and not even make an attempt at DIY. The same goes for any effort at making a homebrew physical pinball - I'll just use a 4:1 LCD if I need something like a DMD.

 

Also, I now need to drastically rethink whether or not I use colorization on tables I stream on Twitch. The last thing I want to do is funnel potential new users into the absolute hot mess that installing colorization support now is.

[usul27]

And some more information: I was the guy who ran the coloring code on a real pin. Why? Because I needed to add features that are not available with Pin2DMD today. I didn't really use the dmdext algorithms, but basically the data structures. The only reason to do so was the fact that no other documented file format was available and requests for it were refused.
It had nothing to do with being a "copycat", but the simple fact that contributions weren't even welcomed (and the fact that I won't contribute to projects that are closed source and charge for it). 
I even agreed NOT to publish my colorisation code.

 

The code (today WITHOUT the colorisation) is GPL-licensed. The initial code was under an MIT license and I usually prefer this license, because I like to give other developers the full freedom. However after I saw what happened here with dmdext, I changed the license to GPL. And it is quite clear to me that dynamically linking closed-source coe with a GPLv3 library is illegal. 

There's another thing that you should be aware: If authors require to be paid for their colorisations (that's NOT "donations", but simply payments), this might end up also in VPins. A closed source API with encrypted content can potentially be used for this. The fact that it's not today doesn't mean it won't be tomorrow.  Nobody knows.

I would rather like to see people creating colorisations because it's fun than to make money (and let's be clear here: nobody will become rich with some colorisations). But sometimes the world isn't as you like it to be 😉
Unfortunately in the "Realpin" community there are some interesting projects that started as open sources and ended up as closed source some time later. Luckily, there are still some great open source pinbal projects around and I hope it will become much more in the future. I definitely see a a growing community of developers creating interesting projects. Therefore I'm quite optimistic that this will happen.

Some of my stuff can be found on Github:

https://github.com/pinballpower

Disclaimer: In my "real life" I make money from hardware. Therefore, it might be possible that some software projects come up in the future that run on hardware that's not open source for various reasons (one might be recycling function blocks from other projects that are not open source). 

Edited May 21, 2022 by usul27