Authorship attribution?

[mk-pmb]

Hi, this repo might be what I've been looking for all week! :tada: (I'm trying to find anyone who can effectively grant me a free software license for lists of instrument and drum names that closely resemble the GM1 names, as The MIDI Association refused to allow me to publish modified versions of the original list. :disappointed: )

Since your drumkit list is a superset, and under CC0, it would be a perfect basis for my project. However, I'd need an author statement in a prominent place of the repo:

• Who is/are the author(s)? Which name or pseudonym shall I use for attribution? (In some countries, it's much easier to re-publish if you can voluntarily add attribution.)
• Claim that they have full copyright for this project.
• Claim that they release this project under the terms of the CC0 license.

Could you add that for me? It could be a "License" section in the readme that says something like Copyright (C) yyyy Name[, Name[, Name]]; released under the [CC0 license](LICENSE).

Once that's solved, I'll try and make a JavaScript version of midiconstants. Would you mind having an npm meta data file (package.json) in your repo so people can easily clone it using npm, the Node.js package manager? I'd write and PR that file for you, it's easier than having to make a custom download script for my package. :-)

[milasudril]

"The MIDI Association refused to allow me to publish modified versions of the original list". Hmm everything is in "modified" on Wikipedia [1]. Also, there are more opensource software that uses modified versions of the lists mentioned (such as in switch-case statements, program name arrays etc). The drumkit file includes the GM2 extensions. You can find the additional names at Wikipedia [2].

[1] https://en.wikipedia.org/wiki/General_MIDI [2] https://en.wikipedia.org/wiki/General_MIDI_Level_2

I could not really claim the copyright on the data files, since the true copyright owner would really be the one who wrote the initial specification, that is The MIDI Association. Or, maybe these names should be attributed to Wikipedia, but "The vast majority of MIDI devices ... display these Program Numers as shown in the table". I hope that I have not done any illegal thing here. Though it may not help in court, I have decided to not claim any copyright on the data files, so no one can claim it being pure plagiarism.

For the code generator, it can be thought of as a Maike add-on (at least if you share the opinion of FSF, which is very strict). Then, it would have been licensed under the GPL. On the other hand, the build metadata does not really bind it to Maike, and as for now, you can run it with python3 without using the Maike frontend. The most appropriate license for that part of the repo is more likely to be something like MIT or 2-clause BSD. I should really fix that.

For different bindings, the cleanest way of implementing it would be to add a other generators to compile.py. However, being a dynamic language, you may wish to do some kind of run-time loading instead. Making it a JavaScript package is fine. But the README file needs to mention all supported languages so the presence of package.json does not make any believe that this is a JavaScript package only.

[mk-pmb]

Yeah, I know there are lots of modified versions of the instrument list. A lot of free software seems to have the strangest useless modifications just so they can claim their list is a work of their own. I tried to explain to TMA that if they want people to use the original names, paradoxically, they have to allow changing them, because only then can free software projects share the original, unmodified list. They either didn't understand or weren't that keen on their intent of having people use the original names.

I considered shipping a list based on Wikipedia, combined with a script that transforms it into the original, but for the "list + patcher" approach I'd prefer to use lists from (L)GPL or MIT software, because of the sheer amount of authors that I might have to credit in the Wikipedia case.

I could not really claim the copyright on the data files, since the true copyright owner […] is The MIDI Association.

That's a bummer, that makes it a lot harder to use your project. :-( Nonetheless I've forked a free software edition that

• cleanly separates the BSD-licensed parts,
• uses a cleaner directory structure,
• fixes compile.py's encoding problem and makes its CLI args optional,
• ships a downloader for the non-free files,
• auto-generates the Maike python files from a template,
• and last but not least, makes the CSV tables available for JavaScript. :tada:

If you like it, pick any good parts or reboot your entire repo – just make sure to keep a branch with the original CSVs around somewhere.

[milasudril]

I would be really interested in the differences you have seen. Interestingly, the Wikipedia list is identical to the official list. Did you include that you will state that this is not an official reference of the (general) MIDI standard in your question. I believe that this should be a huge difference.

Is the only consideration the instrument names, or the message names? I can rename some of them easily (Things like Drawbar Percussive, and Rock -> Drawbar Organ 1, Drawbar Organ 2 (Percussive), Drawbar Organ 3, for example). The message names are sometimes mangled to fit within a C API. My C++ generator, do not need that because it can use a proper namespace. For the messaging part, I believe that the case Oracle vs. Google will determine whether or not this is "fair use". If Oracle wins, then there will be no free software MIDI available for use within the US.

This project is very similar to GLEW, which targets OpenGL. And OpenGL is a much larger API than the API part of (general) MIDI. Conclusion: TMA more restrictive than Khronos.

Personally, I do not use the program names, only the status codes. This means that I can remove the gm_programs and gm_drumkit, but the other files must stay.

[mk-pmb]

I would be really interested in the differences you have seen.

If I had known, I'd have kept research notes. :-) On hand I only have 5 examples from kmid ("Usage" section).

I'm sorry I can't advise on the detailed legal questions. I'm not a lawyer anyway, so all I have is my layman opinion. From what I've read over the years, it seems that European law has no "fair use" exemption but has a protection of "database works" which could apply to carefully crafted, selected ordering of the items in a list. So none of the instrument names are protected, but their specific arrangement in the tables might be. If the message names are creative enough they might even be legit as trademarks, though I doubt TMA would pursue them.

[milasudril]

Hammond® Organ is not good either [1].

Yes, the database is copyrightable. In Europe, there is no fair use, but no API:s are not copyrightable. I see though, that your mentioned reference got permission to use the table as it is. And I happily accept this conditions, because otherwise it is not the GM list anymore. Thus, the license for the instrument names must be CC-BY-ND. Yes, free software requires that with some exceptions, often found in the license text. For example, the GPL begins with

Copyright © 2007 Free Software Foundation, Inc. http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it > is not allowed. ...

What this means (I number them so the individual items can be discussed further):

1. Set the license of any code generators to 2-clause BSD
2. Set the license to the MIDI data files to CC-BY-ND (or similar), with the clarification that code that uses code generated by the code generators is not considered as a derived work.
3. In case there are any bugs or additions (Spelling mistakes, API additions (see #1)) regarding the restricted files, must be published on one channel, so it can be peer-reviewed against official specifications.
4. Make it clear that this repository has nothing to do with the MIDI association, and that any deviation from the official standard is unintentional (otherwise we would break the invariant requirement).

(1) and (2) implies that there has to be individual license tags on different files. In particular, the csv loader must be able to skip any comment. Since different files use different licenses, there can exists free versions of the instrument list in this repository.

(2) forces the use of code generators, but allows the content to be used with free software.

(3) but is sort of implied by (2).

The LV2 SDK contains the full MIDI API with exception for the program and drum names [2]. Thus (2) is could be a requirement for the API message tables. But perhaps it is best to apply (2) to these files also, to be on the safe side.

[1] https://trademarks.justia.com/715/90/hammond-71590155.html [2] http://lv2plug.in/ns/ext/midi/midi.h

[mk-pmb]

Having files of multiple licenses in the same repo/package makes it harder for package managers and related software to automatically report and manage licenses. Some may support it, but it raises the requirements and could be a trap for users who discover too late they relied on a less-capable package manager.

It would also most probably exclude the package from free-software-only compilations like the Debian repos. I'm also currently not motivated to ask TMA for a Creative Commons license, since I'm optimistic I can construct a free software automated DIY kit for the parts that I need.

Thanks for the trademark hint though. I'll make that name less visible in hopes to make it easier for people to avoid doubt about whether the documentation advertises that name.

[mk-pmb]

The wording probably needs fine-tuning. When a repo claims that it

has nothing to do with the MIDI association,

that could sound like the authors don't maintain any contract relationship with TMA, especially they'd not have, or intend to use, any licenses contracts with TMA. However, that would make me wonder on which grounds they could sub-license permission to re-publish TMA works, as they seem to declare they intend to if they write

any deviation from the official standard is unintentional […].

(Why I'm talking about contracts? At least for Europe, my understanding is that the free culture license texts are an offer to agree to a contract (as with a paper version already signed by the distributing agent), so that anyone who would like to enter that contract agreement can do so by just deciding he/she agrees, too, and instantly the agreement becomes binding for both parties. At least if both parties were legally able to make that contract, so it's important to have a source that you can trust has gained effective permission to sub-license the works.)

[milasudril]

First, to come to any conclusion about the status codes:

For my part, I must clear the license of the status codes, otherwise the repo is completely useless. Do you think I have that can take them, without the GM part?

---

If I can use the status codes as is, my plan is to invent new names and publish a new gm lists under CC0 with other names. Otherwise, I guess I must contact TMA and ask for a permission to convey their tables as simple text files, with a suitable license that allows for reuse anywhere, but without any changes. That would not be DFSG compatible, but the repository can still be used for creating DFSG compatible software.

You are probably right about the point about "any deviation from the official standard is unintentional". I want to mention that because

1. Although I think I have made everything correctly, there can be errors in the data files, and TMA does not allow that, since then, it the original content has been modified.

2. Users of the repository should know that it aims to be correct, but they also must know that if they see something that looks strange, they should look it up.

Both (1) and (2) are two sides of the same coin. (1) has more to do with the legal stuff, while (2) is more of a practical concern.

[mk-pmb]

If you make a list of customized status names, it's probably a work of your own and should be safe. However, I wouldn't name it GM or General MIDI, as that would mislead users and TMA won't like it either. They have seals of quality for those names and will probably defend them.

I've checked my discussion with TMA and verified that my permission to "implement" covers the whole spec, so I'll make a priority to create a JavaScript program that can translate numbers into message names, and release it under the BDS-2-Clause license. I will have full publishing rights over that program because I will invent all details of the implementation on my own. You can probably obtain full copyright (in addition to the restricted permissions from the BSD license) by commissioning me to write that program for you. Just request that I shall both write, and publish as BSD-2-Clause, that program for you and in your name; if so, I'll happily act as your ghost writer for free. :-)

[milasudril]

However, I wouldn't name it GM or General MIDI, as that would mislead users and TMA won't like it either.

Notice that the constants is MIDI only, not general MIDI. What was added to General MIDI was certain interpretation guidelines, such as CHANNEL_VOLUME represents a linear gain rather than logarithmic volume, the latter being a design choice due to the small number of bits available. Moreover, I prefer "Classical guitar" over "Acoustic Guitar (Nylon)", and "Drawbar organ 3 (Rotary)" instead of "Rock organ".

Another thing to notice is coding conventions. I have used MESSAGE_CONSTANT which perhaps is more C style. Current C++ convention is to reserve uppercase-only names for macros, and to use MessageConstant instead. How do JavaScript programmers treat constants?

So your program is going to contain these names anyways, so you can do some grep and sed trickery to extract them? Or do you plan to scramble them, and let your program extract them?

I think my way forward is to skip the instrument and drumkit list (the drumkit list is somewhat harder to replace names in), or move these two to a restricted repository, and go with the modified status names from LV2, which is free. However, since there should not be any name mangling in the data files, I guess that the original names reappears.

[mk-pmb]

How do JavaScript programmers treat constants?

If they have seen the light and follow the only true doctrine ;-) , they apply the same naming conventions to constants and variables: http://javascript.crockford.com/code.html#names When I want to highlight that something is meant as a constant, I tend to make a "consts" object to store them, and refer to its values by property lookup notation (consts.vacuumLightspeed).

For the implementation strategy, my current idea is to condense duplicate words for the names, and replace the absolute numbers by distance.

However, since there should not be any name mangling in the data files, I guess that the original names reappears.

As long as you don't arrange them in a way that resembles parts of a MIDI spec document too closely, it shouldn't be a problem. TMA probably has a general permission statement somewhere that allows anyone to implement the spec, and if you can't find that, they'll probably affirm you if you ask. From what I've seen, their restrictive side is only about reproductions of their documents.

[milasudril]

As long as you don't arrange them in a way that resembles parts of a MIDI spec document too closely, it shouldn't be a problem.

So what is your opinion about control_codes and status_codes. Do they look like a spec document? If not, I will close this issue, when removing the instrument and drumkit lists from this repo.

From what I've seen, their restrictive side is only about reproductions of their documents.

And so does all standards bodies: ISO, IEC, IEEE, Khronos.

[mk-pmb]

Do they look like a spec document?

Unfortunately I couldn't form my own opinion on that. My favorite PDF reader is unable to display the GM v2 spec document, and it's not important enough for me to go and test other PDF readers.

[milasudril]

Here is MIDI 1.0 [1]. It works within chromium. Notice that there are a lot more documentation than simple constants with short descriptions.

[1] http://oktopus.hu/uploaded/Tudastar/MIDI%201.0%20Detailed%20Specification.pdf

But before closing, I need more than two eyes.

[mk-pmb]

Thanks for the link. That version I can view but not search for text in it, so it will take a while. Maybe I'll find time later today. I found even more documents about MIDI 1.0 on https://www.midi.org/specifications/item/the-midi-1-0-specification but again I can't read them. Maybe I'll try and convert them (Acrobat Reader -> FreePDF XP) on a windows box later.

[mk-pmb]

A draft preview of my implementation of a program to translate MIDI status codes between numbers and names is now available in the midiconstants-csv's drybake branch.

[milasudril]

• I am not convinced that code obfuscation (this is what you have done) makes things more legal. You could also have used a cryptographic method based solution and kept the key inside the repo, or even simpler: use gzip to "hide" the content.

• I believe that this repo cannot be transformed into an "implementation". There is nothing here that responds to a message, and no code that can generate "Grand Piano" sound.

• I wrote this repo to be a language-agnostic SDK. Thus, the intention was to keep things as simple as possible, and not write the lists as C include files (like the one that comes with the LV2 SDK). The code generators were added for convenience, and the instrument list was added for the sake of completeness.

• I think the best solution is to send a message to TMA, containing the CSV files exactly in the form we want to publish them, and ask what parts of it we have to remove (or write in another form). If everything has to be removed, then I will give up the idea of keeping a language-agnostic repo for this purpose. Instead, I will host a C++ header-only library with the status and control codes, translated by me, released under CC0. At least Drobilla has the permission to host a C version in his LV2 repo.

[mk-pmb]

code obfuscation (this is what you have done)

I dispute that claim. If my code is hard to read, that's one thing, but I didn't use any automated process to make it harder to read.

Instead I've invented my own representation (using the "dry" format) of the data in your tables. I assumed all of that data is a subset of the GM1 spec, so my permission to "implement" the GM1 spec covers this step. I had to make quite a lot of artistic decisions about how my representation should look and be constructed, and my choice was lead by my personal preference and gut feeling about where and how to put which of the words. I'm quite sure that European artist protection law thus grants me full intellectual property on that work. It probably even counts as a new work, not a derived one: While it represents the same idea (the MIDI spec), I didn't use any substantial part of the actual spec document. (The document may be protected by copyright, the idea only by patents.)

Then I wrote a program that could transform my representation of the status codes list into a form that coincides with your original tables. As stated in the readme, distribution of that output may be problematic, so I treat it as non-free. The input file and the transform program however are my own original creations, and I'm convinced I can share them with any licence I like.

I believe that this repo cannot be transformed into an "implementation".

I agree. It's tainted and that won't go away easily. That's why I rebooted the untainted parts and spend considerable time in crafting not just any representation of some of the MIDI ideas, but the coolest and fanciest I can imagine.

As far as I'm concerned, we can just drop the tainted master branch and make the free software edition the new master. I'll soon have finished my own representation of the control codes, and the instrument lists will soon be available via midi-instrument-names-gm1-pmb. At that point the free software edition will be independent from the current master.

[milasudril]

It probably even counts as a new work, not a derived one: While it represents the same idea (the MIDI spec), I didn't use any substantial part of the actual spec document. (The document may be protected by copyright, the idea only by patents.)

Not with the background of this logged discussion. This would count as evidence that we are trying to circumvent copyright restrictions by some form of obfuscation, manual or automatic. Your effort certainly hides the tables from googlebot, making them harder to find, but I am pretty sure that WMG thinks home-cooked file formats (this is what you have done) make no difference to their copyright policy, so why would TMA think any different. The only sane way of writing code like this is to present the tables in some conventional form, csv being the most readable.

Now, I am going to remove the instrument list, rewrite the message tables into C++ only, skipping the pretty names. This has to be legal as I could have copied the same list from any other C++ MIDI software. Also, I am going to remove the code generators, as they are not needed anymore. Then I am going to close this issue, as it has taken too much valuable time.

As I do not believe in your approach to circumvent any copyright, I also want you to remove my name from your fork.

[mk-pmb]

I'm pretty sure that if you get WMG's permission to implement one of their songs, then play it on your own instrument, it would count as your own work. The permission to implement is the core difference here. Anyway, I can understand your decision and I accept it. I'll still maintain the reboot, so thanks for having made the basis for that!