Distributing under LGPL?

[jpcima]

Hello @bisqwit. Are you open to an idea of permitting distribution of ADLMIDI under LGPL or another license more permissive than GPL is?

There has been work on some library projects, by primarly @Wohlstand and myself, reusing the ADLMIDI code. [1] [2]. By virtue of the GPL license, these are derivative works of ADLMIDI, and by transitivity so are all projects touching these libraries by linking other than runtime loading.

Some projects are reluctant to integration of GPL-licensed code (as the latest example, dxx-rebirth). Considering that our work is outside of the initial scope of ADLMIDI, maybe a change of license would now make some sense that it didn't at the creation of ADLMIDI. We used to also be bound to GPL by Dosbox before, but that is no longer the case as it can be substituted with a LGPL-licensed NukedOPL3.

For a similar licensing reason as cited, Nuke.YKT has previously accepted to relicense his NukedOPL3 from Chocolate Doom, from GPL to LGPL to permit adoption in some projects.

So I ask kindly if you would be willing to permit such use of ADLMIDI. Thank you.

[bisqwit]

Copy of my response at https://github.com/Wohlstand/libADLMIDI/pull/183#issuecomment-426943504 :

Currently ADLMIDI does not contain a component called “libADLMIDI”. However, I am interested about that prospect, and I would be open to licensing that kind of subcomponent — which I repeat, does not currently exist at least in my repository — under LGPL.

If I received push requests to the official ADLMIDI repository that divide the player into a library and frontend component without sacrificing any functionality, this motion could perhaps be effected.

[Wohlstand]

@bisqwit , thank you for LGPL granting! :fox_face:

Also, the libADLMIDI is not a component: it's my fork of your ADLMIDI I have completely reworked and turned into the library that can be used as MIDI player as well as real-time MIDI synthesizer, and can be integrated with musical software include games, VST plugins, and even MIDI driver!

If I received push requests to the official ADLMIDI repository that divide the player into a library and frontend component without sacrificing any functionality, this motion could perhaps be effected.

I already did that, and I even had to sent you a email to merge my stuff with your one, but looks like you have lost it... However, to get the same ADLMIDI player as it was originally, it's need to build next:

mkdir build
cd build
cmake -DWITH_CPP_EXTRAS=ON -DWITH_ADLMIDI2=ON ..
make -j 4

In result, you'll see in the current directory the "adlmidi2" binary that will reproduce original ADLMIDI utility, but, was reworked into the "library user", but keeps same functionality as original one. Please, try out the stuff and feel free to review the full internality :fox_face: :wink:

Another hints:

• the library's code was placed into "src" folder
• the code of modded original ADLMIDI player was placed into "utils/adlmidi2"

Trivia against libOPNMIDI:

I was inspired by ADLMIDI, and I had a dream to have YM2612 based MIDI player, and I did it in form of libOPNMIDI: https://github.com/Wohlstand/libOPNMIDI It uses a very similar base to libADLMIDI, but designed to work with different chip - Yamaha OPN2 (YM2612), a chip known by Sega Megadrive / Genesis game console and FM Towns computer where it was also used. It's also another difference: it has no embedded banks support, instead, it does using of externally loaded WOPN bank format. Inside of games or player plugins I using one default bank represented as H-file and passed by "opn_openBankData()" call.

[bisqwit]

I will have to look for your e-mails then. Chances are that I have received it indeed, and filed it in the “look at it later” limbo with the rationale “this is going to take some time…” on the account of there being way too many changes at once. If your patches included things like changing the entire build system to require a toolchain that does not even come installed by default in normal developer configurations (such as CMake, and Debian’s build-essential metapackage respectively), then it definitely meets this sad criteria.

In the current state, ADLMIDI is not a library nor does it contain one, and therefore it does not get the LGPL license even if you somehow misread my words. (Yes, I know LGPL means lesser GPL, not library-GPL…)

Unfortunately I cannot promise progress for this for at least a week, because I am going away for this weekend and I hardly have time to focus on anything on workdays. Sorry about that.

[Wohlstand]

In the current state, ADLMIDI is not a library nor does it contain one, and therefore it does not get the LGPL license. (Yes, I know LGPL means lesser GPL, not library-GPL…)

Yeah, therefore I have inspired in 2015'th year to turn it into the library to use more than just a console player. In result, my library is interested by other folks are including it into their projects.

Unfortunately I cannot promise progress for this for at least a week, because I am going away for this weekend and I hardly have time to focus on anything on workdays. Sorry about that.

Not a trouble: we can work together! :fox_face:

We together with @jpcima already have made a huge progress on it (since 2015'th year when I have forked it a first time), and you can see that! :fox_face:

You'll see we have made a full-featured portamento implementation (that works even on real hardware!), fixed the channel aftertouch support, fixed Doom MUS support (it is NOT same as MIDI and requires data conversion that we have made), added XMI (not an ideal, but works, include loops), added own WOPN bank format that allows to support full internality of libADLMIDI and even more: we are supporting GS/XG, added volume models to represent more accurate sounding regarding to original library (DMX, Apogee, and even Windows 9x's driver). And more more other things!

You have did a good base, and gave me a hope for everything!

[bisqwit]

I could not find your e-mail. I searched for both sender “Wohlstand” and for subject “ADLMIDI”, separately. No matches for the former and none of the latter match your description.

EDIT: Okay I found a patch for SDL2 support.

[Wohlstand]

In my email I am Виталий Новичков [Vitaly Novichkov in Cyrillic] and my email is admin :frog: wohlnet.ru

[bisqwit]

I have now merged the patches you have provided. Which isn’t… much. Looking forward to more!

[Wohlstand]

Those patches where made very long time ago, and looks like I need to post my entire content of libADLMIDI's repo to swap entire stuff. But thanks :3

[bisqwit]

I see!

[Wohlstand]

Anyway, please review and play around my stuff first, as it's very different to original one, then I suggesting you to make a "legacy" branch which will contain the original stuff until merge my override into master.

[Wohlstand]

Or better... Make a fork of my library repo to you, and while pulls & reviewing our stuff from me and making something into it, I'll have to take something back for polishing / reviewing / debugging / testing on many stuff include mobile phones :fox_face: :wink:

[bisqwit]

I still have not given permission to re-license. I only said that if my code was split into a library and a front-end, the library part could be licensed as LGPL — I would be open to such thought. As it stands, the original code is not split into those two portions; the whole code is GPL, and so are derivatives thereof, even if you have done such splits yourself. Suggest you roll back your commit.

[Wohlstand]

The player part is kept in GPL, look into README.md into License paragraph:

Misc. utilities, players, and player plugins are licensed under GPLv3+.

And the player part is KEPT under GPL: https://github.com/Wohlstand/libADLMIDI/tree/master/utils/adlmidi-2

[bisqwit]

And the “player part” includes also the MIDI reader, RPN handling, linear to logarithmic volume conversion, OPL3 scheduling, arpeggio, etc., derived from my code, yes? Anything derived from the code within this repository is still GPL3. I don’t want to be difficult, but you can’t make license changes yourself. If you do, what’s the point of even asking me? Or having a license to begin with.

[Wohlstand]

Do you mean the MIDI Sequencer? I have completely rewrote it with my own. Or the MIDI Synthesizer that interprets each MIDI event are passing into the chip emulator?

Look:

On side of Library part are next:

• MIDI Sequencer - does loading and parsing of MIDI files are converting into internal structures, I have completely rewrote it to provide seek-ability support for it. It does iteration of MIDI events and passing of them into MIDI Synthesizer. It's disablable part (by the CMake option, or by macro for case of manual usage). When it's disabled, the library can be used for only purpose of Real-Time MIDI driver or player plugin (I did VLC plugin of it, it's licensed under GPLv3).
• MIDI Synthesizer - A set of functions are interpreting MIDI events are sending into OPL3 chip(s) as native register data. Most of part was majorly changed, you'll see., and the generator functions are given to return the sound output generated by chip emulators are reproducing the state was sent by MIDI Synthesizer

On side of Player

• GUI (that prints MIDI events received from callback into the animation, or the game joke)
• Video and WAVE recorders
• SDL Audio usage to play the final result
• WinMM usage to play the final result on Windows builds
• Reverb code that applying to the output stream (I have added an option that can disable it as on some machines the reverb produces noisy sound, or even causing some lags on slow audio outputs).
• Command line interface
• And some other parts

The content of "utils" folder in most GPLv3+ or GPLv2+

The code of library part is here: https://github.com/Wohlstand/libADLMIDI/tree/master/src Each file I have described in README.md you can check.

The code of Utils part (include Player part) is here: https://github.com/Wohlstand/libADLMIDI/tree/master/utils

[bisqwit]

So the files libADLMIDI/src/adlmidi_midiplay.cpp, adlmidi_opl3.cpp, adldata.cpp etc. which obviously are derivatives of portions from this repository, are not actually used in your project at all except by those “Misc. utilities, players, and player plugins”, and these files I listed and others like them are still properly indicated as being under GPLv3+?

If so, what are you even asking me in the first place and why?

On another topic, the reverb thing is a quick hack. A Ladspa-based solution would be probably much better.

[Wohlstand]

• libADLMIDI/src /adlmidi_midiplay.cpp, adlmidi_opl3.cpp, adldata.cpp etc. - are Library part are mainly used in my project, I wanna license that under LGPLv2.1+.
• Misc. utilities, players, and player plugins (inside utils folder) - are all GPLv3+.

[bisqwit]

Well, you want. But I have not given you permission for that. Yet you created a commit suggesting contrary.

[Wohlstand]

Well, you want. But I have not given you permission for that. Yet you created a commit suggesting contrary.

Sorry, I'll revert that, and will return that back on your full confirmation for licensing. You are still review the stuff and give a complete comment for that.

EDIT: Done with force-push. The changes I have made, I kept locally on separated local branch.

[Wohlstand]

Okay, at begin, I'll post entire content of my libADLMIDI stuff, but with keeping your readmes and PHPs in the root, but changing the folder structure for organizing, and other stuff...

[bisqwit]

I would appreciate gradual commits without large codemasses suddenly appearing out from nowhere :-) And I also kind of dislike CMake.

But I am also willing to study your repository more in detail at such day when I have time and do librarification+backporting changes myself. Unfortunately, right now it’s 2am and I should finish packing.

[Wohlstand]

Okay, for comparison, I have made the separated branch I have called as "library": https://github.com/Wohlstand/ADLMIDI/tree/library

libADLMIDI - It's 4 years of work, and the original ADLMIDI was gone into very far past... Then, it's reasonable to make a branch for current state of original for historical purposes and basing on my "library" branch for some sort of ADLMIDI v2.0 which represents my libADLMIDI.

[Wohlstand]

And I also kind of dislike CMake.

The CMake is one most common building systems are used widely by lot of projects (include commercial!). The alternatives are:

• autotools, also one of most common, however, it has own cons include harder learning of it's usage
• QMake, a build system used on Qt, one of that easy to use, but it depending on biggest thing, obvuiously - calling Qt.

With CMake I have extended abilities to build the project on lot of platforms include macOS and Android! Raw Makefile-s are totally not suggested for cross-platform projects due inter-platform cons and limits of GNU-Make language itself. The CMake allows to generate GNU-Make files as well, as Ninja build files, Visual Studio projects on Windows (to compile stuff on MSVC toolchain, or natively edit code from IDE that is official on Windows), Xcode projects on macOS. CMake projects are well-supported by Qt Creator IDE where they are can be natively opened as regular projects and used for compile and debug.

[Wohlstand]

Unfortunately, right now it’s 2am and I should finish packing.

At me is also 2AM (UTC+3) ;3

[jpcima]

@Wohlstand look, it's as @bisqwit has said a bit sooner; it's no need to attempt to rush it and make it in one go. Best is to take a strategic, divided approach to split the cake into smaller parts. Since this issue is specifically about the license issue, it may be wise to open another about discussing the strategy of merging our works into one and all relevant details.

[Wohlstand]

Okay, it's a good idea then, gonna to make another issue for that. This will be kept opened.

[no-more-secrets]

Looking forward to a future where I can use libADLMIDI as LGPL! :-)

[no-more-secrets]

@Wohlstand is there any way that this could get prioritized? All of the other great changes/features that you are adding to the libADLMIDI will be of no use for people who cannot use a GPL library in their project (many)! Really need to get this as LGPL for it to be widely usable.

@bisqwit Appreciate your willingness to work toward libADLMIDI becoming LGPL. Honestly though I wouldn't seen any reason not to just allow the libADLMIDI developers to release libADLMIDI as LGPL even without refactoring your original tool into app/library components (if I understood right what the deal currently is), since philosophically/legally I don't think you really lose anything by allowing it. But that's just my two cents.

[Wohlstand]

Okay, since yesterday I resumed my work, however, I made the new branch: https://github.com/Wohlstand/ADLMIDI/tree/library-3 I found a simplier way to turn the thing into the library, however, it's still need some time to let me process the thing.

[no-more-secrets]

@Wohlstand Thank you, looking forward to it!

[Wohlstand]

For everyone who want to track a progress and review commits I made, I made the draft for a Pull-Request: https://github.com/bisqwit/adlmidi/pull/7

[Wohlstand]

Okay, my pull-request #7 is ready now. @bisqwit, feel free to review all changes through 32 commits I made. At the pull-request, I'll write the short-list of changes I did.

[elvisish]

@bisqwit Is it possible for this to be switched to LGPL over five years later? @Wohlstand Did this ever get close to being done?

[Wohlstand]

Hello, @elvisish, I already did all the work and placed it at the PR #7. @bisqwit should confirm that all was done for this.

[elvisish]

Hello, @elvisish, I already did all the work and placed it at the PR #7. @bisqwit should confirm that all was done for this.

O̶h̶, I̶ m̶u̶s̶t̶ h̶a̶v̶e̶ b̶e̶e̶n̶ c̶o̶n̶f̶u̶s̶e̶d̶ w̶i̶t̶h̶ o̶n̶e̶ o̶f̶ t̶h̶e̶ o̶t̶h̶e̶r̶ c̶o̶m̶p̶o̶n̶e̶n̶t̶s̶ t̶h̶a̶t̶ n̶e̶e̶d̶e̶d̶ t̶o̶ b̶e̶ r̶e̶-̶l̶i̶c̶e̶n̶s̶e̶d̶ Did he not confirm it yet?