End of an Era

[usul27]

After some discussions with different people I have decided to stop my implementation of Pin2DMD colorisation now. While initially I supported the idea to have an encrypted version of archives, I wasn't aware what this would mean for the VPX community. Therefore, I will stop working on this at all. My software had no direkt link to VPX/Freezy, but was designed to run on a Raspberry Pi. As VNI-Files have been removed it is useless and I won't implement any undocumented and/or encrypted file formats. 

 

If you have a look at the code you will clearly see the Freezy's roots of the source, but lots of stuff had been rewritten as I didn't fully understand the C# code 😉
https://github.com/pinballpower/code_colorize

Some remarks about this:
- It is NOT fully working, lots of stuff that might be used in some projects might not work at all.
- Code quality not very good
- it requires stuff from dmdreader that's also available on Github

- It was solely developed based on blackbox reverse engineering and existing open source code.
- It is licensed under GPLv3.
- It is practically useless in the current state, don't think you can just compile it and run the stuff on a Pi (even thought it MIGHT work with a few files)

- I won't give any comments and support for other developers. You have the code, that's all.

I won't spend any time on adding features or improving this code. If there is a common understanding in the community to support open source (from users, developers, but also colorisation authors), I might help in one or the other project in the future.  As I don't see this today, I'll spend my time on other stuff. 

One important note: If something is licensed under an open source license, there is no control of what users can do with it. You can run it on your PC, Pinball, mobile phone or toaster. I don't care and the license doesn't care. If you think you need to make sure that some features should not be available for some devices, users, countries - do it, but it's not open source. If the community feels that closed-source software is the way to go - feel free to do so. I'm not using any VPX-based stuff anymore myself, therefore I'm not personally impacted by anything. 

I hope, the VPX community finds a good way in the future, whatever it might look like.
 

[freezy]

I learned a new word today: FUD.

 

Someone in a private message mentioned it. Completely unrelated, of course.

[sudsy7]

I understand that some people have chosen to not publish in .vni format.  Again, that is their option.

 

And I can tell you that I personally have been waiting not a "couple of months", but more like 14 months for the freezy dll to be updated with all the 64-color functionality.

[usul27]

1 hour ago, sudsy7 said:

Maybe I'm missing something, but I'm not sure what this kerfuffle is all about.  Users have the option to use freezy... or lucky dll.

Users should just be aware the the "lucky dll" you're talking about isn't the lucky DLL, it's a a Freezy DLL that has been misused against the will of the author(s) and most likely violating the license of this code. If you want to use the "Lucky code", just buy a Pin2DMD and a license from him and use his closed source software. Nobody here has any problem with this. Just stop using any code from Freezy.

[usul27]

6 minutes ago, sudsy7 said:

I understand that some people have chosen to not publish in .vni format.  Again, that is their option.

Sure, it definitely is. And if they choose that this should only work with closed-source software, that's totally fine. The authors and the users should also just accept that these files can't be used with Freezy's software anymore. You want to use .pal colorisations: get the closed-source software and a Pin2DMD.

[LynnInDenver]

Just now, usul27 said:

Sure, it definitely is. And if they choose that this should only work with closed-source software, that's totally fine. The authors and the users should also just accept that these files can't be used with Freezy's software anymore. You want to use .pal colorisations: get the closed-source software and a Pin2DMD.

 

And this is really why I don't plan on showing colorization working in Visual Pinball going forward that relies on his software - he's misusing Freezy's code, and in order to ensure I don't encourage others to violate the license, I won't show colorizations that have been updated to be solely run that way if someone wants to run it on an LCD.

[LynnInDenver]

1 hour ago, sudsy7 said:

And I can tell you that I personally have been waiting not a "couple of months", but more like 14 months for the freezy dll to be updated with all the 64-color functionality.

 

The current Freezy version supports 64 color, and released in the past couple of months... what's specifically not functioning there versus the Lucky1 license breaking implementation that has you still waiting there?

[sudsy7]

1 hour ago, LynnInDenver said:

The current Freezy version supports 64 color, and released in the past couple of months... what's specifically not functioning there versus the Lucky1 license breaking implementation that has you still waiting there?

It supports 64-color fine if none of the more advanced coloring modes such as Layered Color Masking, Colormask Sequencing, Layered Replace Masking and others aren't used in the colorization.  It's impossible to colorize some scenes without using these techniques.

[LynnInDenver]

Just now, sudsy7 said:

It supports 64-color fine if none of the more advanced coloring modes such as Layered Color Masking, Colormask Sequencing, Layered Replace Masking and others aren't used in the colorization.  It's impossible to colorize some scenes without using these techniques.

In other words, features Lucky1 was agitating to get implemented and likely not being happy with the time frame they would be implemented. Not that's an excuse for what's going on.

[sudsy7]

6 minutes ago, LynnInDenver said:

In other words, features Lucky1 was agitating to get implemented and likely not being happy with the time frame they would be implemented. Not that's an excuse for what's going on.

Time frame = 14 months.  That's not implementation at all.

[LynnInDenver]

4 minutes ago, sudsy7 said:

Time frame = 14 months.  That's not implementation at all.

 

Again, not an excuse to violate the GPL license to provide an implementation himself.

 

Now, if Lucky provided code submissions for those features to Freezy at any time prior to the last release of that and it's not implemented yet, yes, that is a problem, but it doesn't mean do what he did.

[sudsy7]

1 minute ago, LynnInDenver said:

Now, if Lucky provided code submissions for those features to Freezy at any time prior to the last release of that and it's not implemented yet, yes, that is a problem, but it doesn't mean do what he did.

That's what I'm saying - these features have been around for about 14 months or so.   You would have to ask him about the exact dates for code submissions, but I recall several times in the last year when he was asked when the compatible freezy dll would be released and the answer was always that he had supplied the data and it was being worked on - that's all on record.

 

Look, I can understand both of these developer's points of view and frustrations with each other, and we all wish they would come to agreement on how to handle it properly.  I'm still hopeful that they will, but I don't see how bad-mouthing or shaming tactics are going to help resolve anything - they haven't so far.   They usually just create irreconcilable division.

[LynnInDenver]

16 minutes ago, sudsy7 said:

Look, I can understand both of these developer's points of view and frustrations with each other, and we all wish they would come to agreement on how to handle it properly.  I'm still hopeful that they will, but I don't see how bad-mouthing or shaming tactics are going to help resolve anything - they haven't so far.   They usually just create irreconcilable division.

 

Right now, it looks like we're already there with the license violation, per Freezy.

[Ashram56]

I'd like to understand what exactly was the rationale for refusing to use freezy proposal of a colorization API. To me it's beneficial to everyone, and I don't see any downside, so why has this been rejected? 

 

[Hoop22]

is the gist of this that Lucky is in this to make money and he's violated Freezy's license in order to do so? The money coming from real pin cab owner's and vpin owners can ride along for free, but will be indirectly supporting Lucky's violation of Freezy's license?

 

I'm not quite sure how that's much different from the cab builders who sell pre-loaded machines. Wrong is wrong.

 

The license and tech talk is beyond me, though i've miraculously managed to get my crap working to this point.

I'd personally prefer to keep doing things on the up-and-up though.  Lady  Karma is never kind.

[lucky1]

7 hours ago, LynnInDenver said:

 

Right now, it looks like we're already there with the license violation, per Freezy.

 

Like many things said above it is just the POV of Freezy. What seems to be clear to him actually never has been.

https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

 

6 hours ago, Ashram56 said:

I'd like to understand what exactly was the rationale for refusing to use freezy proposal of a colorization API. To me it's beneficial to everyone, and I don't see any downside, so why has this been rejected? 

 

Actually we were still discussing this, with Funkyman as a mediator, until this thread was opened to help freezy.

In my opinion using such a API in GPL licensed code with closed source would lead to a more clear license violation.

 

Currently since both dll´s can be used as a dmddevice.dll (just rename dmdext.dll to dmddevice.dll to test) both are separate programs which then is no license violation. "If they are separate works then the license of the plug-in makes no requirements about the main program."

 

7 hours ago, sudsy7 said:

I'm still hopeful that they will, but I don't see how bad-mouthing or shaming tactics are going to help resolve anything - they haven't so far.   They usually just create irreconcilable division.

 

So true ! That is why I prefer not to comment any further in public and (still) for the majority of the community try to find a solution with a better interface and in the same time to hopefully never have to talk to freezy again.

 

 

[freezy]

You can spread all the confusion you want, at the end of the day it's your ego and "donations" versus open software. The community will choose what to prefer (I have a guess).

 

Note apart, I also talked to a few people and many have seen this coming. Money tends to ruin many hobbies.

[Ashram56]

@lucky1

 

I've read through the link you provided, and my understanding is the exact opposite of yours.

 

Your solution replaces an existing dll with your dll. By construction, it is also a combined work of Freezy work with your work, and that falls under GPL licence.

" If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. "

 

[EDIT] Clarifications needed on this subject, see below, looks like I misinterpreted some information

 

Using an external API

"By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. "

 

But anyway, this point is rather academic and at the end of the day for legal to decide.

 

But besides this legal argument, is there any other reason to not use a colorization API ?

 

[EDIT] Reading more in depth: can you use dmdext.dll directly from Freezy fork without any modification, as a plugin to your DMDdevice.dll ?

 

And who developed DMDdevice.dll in the first place ?

 

If it's freezy, well it's covered by the original GPL licence

If it's someone else, the governing licence is whatever licence applies to dmddevice.dll

 

[usul27]

1 hour ago, lucky1 said:

Like many things said above it is just the POV of Freezy. What seems to be clear to him actually never has been.

https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

That's not the POV of Freezy, but the POV of almost anybody. Don't look for crude web sites and your laywer, but just read the the comments from the license creators.
https://www.gnu.org/licenses/gpl-faq.en.html

But hey, the good thing is that even if you have the most bizarre ideas, you will luckily find somebody on the internet that thinks you're right.

[usul27]

Just a few more thoughts from me. I have been in contact with some authors that would really like to publish files in an unecrypted format that can be used with the open source software of your choice. For some reasons that's not possible today (and I won't get into some of the technical details).

There would be a solution for this, but it would require a few things:

1. Support from more than the 2 authors that I have been in contact with. 
2. A tool that post-processes exported VNI/PAL files. That's not a big deal to do and I'm willing to contribute and create an open source solution for it.

That would be just fine for everything that had been implemented in the past. 

Now comes the more problematic thing: The future. The problem with this approach is that it can't be used with current and future releases of the Pin2DMD editor.

On April 5 this year usage of the Pin2DMD editor has been limited to Pin2DMD devices:
https://github.com/sker65/go-dmd-clock/commit/998af409e6d05263495678ba22b1d6b636306443
(this might help to better understand the "gatekeeper" argument in Freezy's initial post)

In my interpretation this means that displaying colorisations with devices like Zedrummer's cool ESP32 board (and even an LCD display) would be forbidden without written consent of the authors of the editor.  With this change, there is no future for this editor in my point of view anymore as all kinds of innovative new developments from the community could be easily blocked.  This looks like a dead end for me.

Edited May 23, 2022 by usul27

[lucky1]

1 hour ago, Ashram56 said:

Reading more in depth: can you use dmdext.dll directly from Freezy fork without any modification, as a plugin to your DMDdevice.dll ?

 

Yes, no problem, if you set pinup to false in dmddevice.ini to not conflict with my implementation and don´t use HD scaling that would be possible with very little changes. I added missing RGB24 HD scaling routines, turned off pinup, changed DmdDevice.ini to DmdExt.ini to make it possible to use freezy as dmdscreen.dll with its own settings and added a few ini checks in my build. I attached a quick build which works with the release version from here https://github.com/freezy/dmd-extensions/releases/download/v1.10.2/dmdext-v1.10.2-x86.zip

if you only rename dmddevice.dll from the zip to dmdext.dll. If no valid dmdExt.dll is found from my dmddevice.dll it works only with a real pin2dmd just like previous releases. Thats it.

dmddevice.dll

[usul27]

2 hours ago, Ashram56 said:

And who developed DMDdevice.dll in the first place ?

 

If it's freezy, well it's covered by the original GPL licence

If it's someone else, the governing licence is whatever licence applies to dmddevice.dll

It's not about a license somewhere in the past, but the current license of the code that's being used. Licenses can change and they often do. As long all authors are fine with this, there is no problem at all. You have seen open source software becoming closed source in later versions (any idea about a project like this?). That's perfectly fine as long as everybody who contributed to it is fine with it. 

An example: If I publish code today under a BSD-license you can do with it whatever you want (you can even use it in closed-source projects). If I decide tomorrow to limit the use of the code only allow women from Chile who are over 90 years old to use it, you are most likely not allowed to use this anymore. However you still can use the initial code that was under BSD license. I can try to get the old code off the internet (and we have also seen this in some projects that have been open source before)., but if you still have a copy on your computer, you can still use this legally. 

[Tikimaster]

If Authors are choosing, which file format they want to use. - on the other side of the Medal there should be a kind of independend, legal solution for END-Users to be able to run both systems easily without doing big changes for every single loading Table. Right?

Edited May 23, 2022 by Retsamikit

[usul27]

Yes, in a perfect world it should be like this. But as you can see in this thread, the world is not perfect. Not everybody is interested in an "independent, legal solution".  See my comment above above about this.

My understanding currently is that there are the following legal solutions:
- Get a Pin2DMD and use the native closed-source DLL for it that does not use any Freezy code. It will only work with Pin2DMD.
- Use VNI/PAL files that have been created with an editor before April 5 and use it with the Freezy software (or whatever other software you like). Some authors have stated already in this thread that they are fine with this.

There are probably a lot if illegal ways, but I will not go further into this.

[LynnInDenver]

5 hours ago, lucky1 said:

 

Like many things said above it is just the POV of Freezy. What seems to be clear to him actually never has been.

https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

 

 

Actually we were still discussing this, with Funkyman as a mediator, until this thread was opened to help freezy.

In my opinion using such a API in GPL licensed code with closed source would lead to a more clear license violation.

 

Currently since both dll´s can be used as a dmddevice.dll (just rename dmdext.dll to dmddevice.dll to test) both are separate programs which then is no license violation. "If they are separate works then the license of the plug-in makes no requirements about the main program."

 

 

So true ! That is why I prefer not to comment any further in public and (still) for the majority of the community try to find a solution with a better interface and in the same time to hopefully never have to talk to freezy again.

 

 

 

For licensing, ESPECIALLY if it's unclear what's legal and what's not, it would have been best to steer clear of potential controversy and not do what you've done.

 

For my Twitch streaming, I've decided to err HARD on the side of caution, and no longer will be doing PAL/VNI altcolor on my LCD using either @freezy or @lucky1 options, and from your comment here lucky1 regarding the potential of working together again (none), that's going to be permanent until a solution without any of your software involved in the chain of creation is available.