TODO: Choose software license

[DrSkunk]

There are a lot of software licenses out there. I prefer the GNU GPLv3 since it means that people who adjust the code also have to make the code available.

More information: https://choosealicense.com/

[Wintergatan2000]

I know too little about the different licenses to be able to compare them, but i think this is a very good initiative. This one seems good at first glance, what do all of you others think about GNU GPLv3?

[ChemiCalChems]

I agree about using GNU GPLv3.

[Yuleblinker]

As open as possible would be my choice. GNU GPLv3 would be a good way to go but if the decision is made to use existing code libraries their licenses may influence the choice.

[emosenkis]

I'm in favor of MIT or Apache. GPL is what's known as "copyleft" - it forces anyone who makes changes to the code and distributes it to also release it as GPL. While this sounds nice in theory, in practice it means it's harder to make commercial use of the code (if someone decides to start laser cutting music box sheets as a business, this could make it irritating for them to use the code without violating the license).

MIT (extremely short and simple) and Apache (long and thorough) both allow anyone to do almost anything they want with the code and have become much more popular than GPL over the last decade.

[DrSkunk]

@emosenkis what's your preference? MIT or Apache?

[emosenkis]

MIT, I guess, but I'd be happy with either.

[ChemiCalChems]

MIT was chosen and added to the repo, closing.

[Yuleblinker]

We currently have an MIT licence applied to the project. Some contributers on Gitter have mentioned that we cannot use the midi-parser.js library as it is GPL. There are issues with the midi-parser.js library. It does not parse all midi files. For this reason we may have to change it and this license issue becomes irrelevant.

As the project progresses we may need to make use of other libraries for things like playback. Until we know what all the constituent parts of the project are and we have a definitive list of libraries used we cannot decide on a final license. I don't know much about licensing and I am not making any suggestions here. I'm merely pointing out that our choice of license is currently problematic and the issue is not closed.

[TeXitoi]

You can be MIT and using GPL code. The projet in its globality will need to respect the GPL, but if midi-parser.js became usable, you can then change the library and be fully MIT.

Thus, I think this issue can just be closed.

[Yuleblinker]

My understanding is that if GPL code is used in the project then the whole project needs to be GPL. We currently have an MIT project license. MIT code can be used in a GPL project but not the other way round. As we haven't finalised all the constituent parts of the application and have not finalised on the libraries and code we are going to use we can't make a definitive decision yet. At the moment however we are in breach of the GPL license by using the midi-parser.js library with a project license of MIT. The issue isn't closed and can only be if we change the project license to GPL or remove the use of the midi-parser.js library immediately (which means taking down the index page) And we may need to re-visit the issue when we have finalised on the libraries used in the final application.

[Pierstoval]

I'm also 👍 for MIT, it's the most flexible & permissive license that would allow using almost any library with GPL licenses

[TeXitoi]

@Yuleblinker the code in this repo can be MIT, and you depend on GPL. But the project in its globality is GPL. If you change later the GPL lib to a MIT one, the project is then MIT.

[Yuleblinker]

@TeXitoi Yes, but the problem is that, at the moment, the project in its globality is MIT not GPL. Which I believe means we are currently violating the GPL license for the midi-parser.js library that is currently being used. The final license can only really be decided when we know exactly what the final set of third-party libraries will be and what licenses they use. I re-openend this issue because we curently have an MIT license and we have a public facing app that uses a GPL component thus breaching the GPL license for that component.

[emosenkis]

I am not a lawyer but:

It's not a violation of the GPL unless the GPL'ed is copied and pasted into the MIT'ed code. We should be careful not to minify the GPL library together with non-GPL code. Without having all contributors explicitly agree to either assign their copyright or relicense their contributions, you can't just change the license on the repository so you might want to consider adding a contributors agreement that allows relicensing under any Open Source Initiative approved license. That could work for new contributions but existing contributors would also have to agree.

https://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant

[Pierstoval]

Or, what you can do, is add a small dependency flow (npm/yarn) and dump licenses of all installed packages in something like a yarn.lock file. It means anyone installing this project will also install sources of the GPL packages, therefore not violate them, even if you need for example to concatenate & minify lots of JS files, you can still keep the original license for these files (which is something common most of the time) in your project, as it's open-source, so the lock-file or dependency list + your frontend workflow will be the guarantee that you don't modify the original behavior.

Additionnally, you can also add a smal "About" page and add all details about dependencies licenses there, it works too.

[DrSkunk]

Since there are issues with the current midi parser library as well, I suggest to migrate to the ToneJS MidiConvert library. Its license is MIT and is tested to work with multiple tracks. https://github.com/Tonejs/MidiConvert

[DrSkunk]

New library does not have this issue. (MIT license)