Change license to a more permissive

[konradreiche]

This library uses the GPL license which makes it actually impossible for us to use as it would require us to use the GPL license as well as disclose our source code. Working on a commercial product it would mean that we need to move away from this library and roll our own implementation.

How deliberate is the choice of GPL. Would other, more permissive licenses, like MIT or Apache be a feasible alternative?

[bradleyfalzon]

@grafov I'm a +1 on this too, we're fortunate it hasn't affected us the way we use this library, but we've had discussions internally about the product and the GPL is a blocker.

I'd also like this library to for this library to consider relicensing.

[grafov]

Frankly I dislike permissive licenses. I respect ideas of Richard Stallman and like to see more GNU licensed software in the world. Well it is idealistic point of view. For a reference I looked on Ffmpeg project as an example of useful software that uses GPL. Though their use LGPL (it allows a way for use it in proprietary software but not in a way convenient for Go packages) and only include parts of code under GPL v2. So when I uploaded code on github I decided to use GPL for this library. Really I not thinked much about future use of the library by other people and just selected GPL by default.

I'm understand what in reality for opensource project is more important to be useful than to be strictly open. We worked for companies where we make commercial software and much of it software is proprietary, notably for videostreaming software. So I not insist on keeping this library under GPL license and I accept relicensing it for more acceptable conditions for using in closed software.

[grafov]

There are number of contributors in the project. Though most of contribs are small patches. But I not sure about proper procedure for license changing. I looked for examples and found a lot of cases for moving from BSD, Apache, etc. to GPL v.3. But I not found a ways how to back from GPL v3 to a more permissive license. Probably we need notify other contributors about license changing. Or just use dual license for future versions. It is cause for asking it at stackoverflow or anywhere such place :\

Also @platzhirsch let rename the topic of discussion to a more constructive? :) For example "Change license to a more permissive".

[konradreiche]

Sorry for just getting back at this now. Apparently, this issue is a non-issue.

Running code on a server does not account as distribute where as if a client app would use GPL it would very much. That's also the reason why there is the Affero GPL (AGPL) license, that's the one which closes the loophole:

Why the Affero GPL

The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run the program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the program that it's running. If what's running there is your modified version of the program, the server's users must get the source code as you modified it.

In most cases the m3u8 library would be run on the backend anyway, hence a more permissive license is not necessary. If there are no further objections I would close the issue.

[bradleyfalzon]

We're in the same position on GPL vs AGPL, however, this may not always be true and would still like to consider relicensing this library until a more permissive license, such as BSD/Apache.

I fully understand the reasonings of GPL, however, both @konradreiche and I, who aren't required to submit our changes to this library under the existing GPL still choose to do so, a more permissive license would still have me contributing.

[grafov]

Well, as I said I not against relicensing. And if we decided set up a new license then let move to conditions that permissive enough for prevent future problems in both server and client sides. So let move to BSD license. I made some code under BSD 3-clause license for similar cases when the code was targeted for proprietary projects for my employers.

I still not sure about right way though. So let try to do it in the simple way. If anyone will complain we will handle the conflict situation personally.

1. I will make patch with new LICENSE text (BSD 3-clause) and also with changes in the file headers.
2. The patch will be applied to the nearest release (for clarify let make the release with only license changes).
3. Release notes will say about the new license applied since that version. And it will note contributors: if anyone against this change he can create the issue about it. So if I got such issue I will remove the old patches from the contributor and replace them with a new code under my authorship.

I hope this way will not violate license rules.

[bradleyfalzon]

Sounds good to me, we won't contest any of our patches.

[grafov]

@bradleyfalzon I just published the release v0.8 with announce of changing license to BSD. I will make the new release v0.9 with only changed comments in file headers and the new LICENSE file. For clarity please don't accept any patches until the new release!