MIT ?

[Justinfront]

Hi just wondering if the license could be changed to MIT, just looking at integration with other haxe opensource projects and MIT license like the flambe one would be preferable and encourage contribution.

[tconkling]

I don't necessarily have a problem with that - we went with the BSD license because that's what we'd used for other projects - but I'm wondering what the issue with BSD is? It's extremely permissive - the only thing it prevents is using the authors' names to promote something.

@groves @aduros thoughts?

[Justinfront]

I was talking with underscorediscovery on the snow/luxe channel about his project and partially about openflump and he mentioned an issue with copyright and was reluctant to explore projects that don't have MIT, currently looking at range of haxe solutions. It seems MIT is the new BSD 3. https://github.com/aduros/flambe/commit/1834845c28e7dfd77963f700f4dddf3913e39be1 Also enquiring about openflump which does not have a licence in the project. https://github.com/SavedByZero/openflump/issues/1 Probably best to chat with underscorediscovery on snow channel about licenses as he may shed a lot more light on them https://gitter.im/snowkit/public/ I have switched to using MIT on projects but yet to update older git experiments to MIT.

[tconkling]

"Because some dude said so" isn't a compelling reason to make a change to a piece of software. We're programmers! We (hopefully) make decisions about our software for rational reasons. (See: http://en.wikipedia.org/wiki/Cargo_cult_programming)

Happy to have the discussion about the Flump license, but it needs to be an actual discussion, not a request to go track down a random person :)

[Justinfront]

it's simpler if projects have compatible/same license and MIT seem to becoming a standard and it is known for being simple, for instance current haxe frameworks have MIT licenses.

flambe, openfl, snow all have MIT https://github.com/openfl/openfl/blob/master/LICENSE.md https://github.com/underscorediscovery/snow/blob/master/LICENSE.md

[ruby0x1]

I think some “broken telephone” has happened here, let me clarify what I was saying a bit. I'll start with : The flump source code license has little to do with other projects or collaborating between them in any way because it relates (I think?) only to the tool itself.

My remark in passing was related to this, and this only:

    * Redistributions in binary form must reproduce the above copyright notice,
      this list of conditions and the following disclaimer in the documentation
      and/or other materials provided with the distribution.

A) As a library provider for end users, including any dependency that requires the user application/game to include a copyright notice in their binary somewhere is out of the question for me. I was remarking that 3 clause BSD is incompatible with including any portion of code from this repository in any way shape or form. Any code that used this code in some form to create new code might also be incompatible.

B) Now, The source code of flump itself does not apply to the output generated by flump (unless I am mistaken - but that would be a little weird). If a person were to read the flump file spec (or look at the flump output) and write a parser and runtime on their own they could license it however they wanted to. I am under the impression the openflump project was doing something along these lines, but I really haven't looked at it because I have other things to focus on.

In the end, my remarks were made in the context (at least in my mind) suggesting that a flump importer would be “neat” - but that caution should be taken as the origin of the importer and runtime code for flump playback due to licensing of flump source in itself is incompatible, and if sources were basing their code on this code that would probably lower their usefulness as well.

In the end, I won't be using flump (I don't have or want flash licenses) and no part of this code or any flump importer code would end up in my libraries anyhow. And of course, third party users can opt into any invasive licenses as they see fit on a project level.

---

TLDR; It was a remark made in passing and in no way directed at flump code specifically.

I do however feel that projects with a runtime and data (like flump, spline, spriter etc) often have invasive runtime licenses and this drastically reduces their usefulness or reach. MIT would make it way more inviting and worth supporting on a framework level, but I totally respect the right to choose whichever licenses you feel best fit the project goals.

[tconkling]

Thanks for the comments, @underscorediscovery.

I don't think that MIT is any less invasive than BSD, however. The issue you're objecting to - including library licensing information in your game's binary - seems to be present in the MIT license:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

I Googled "MIT license iOS app" and found a lot of discussion about the issue; the consensus seems to be that any MIT-licensed libraries should have their disclaimers reproduced in your app's About screen.

http://stackoverflow.com/questions/10133542/using-mit-licensed-product-in-iphone-application

[tconkling]

(That said, I don't care about this clause as far as Flump is concerned. Maybe we need another license entirely :))

[ruby0x1]

I am aware of the MIT clause but I don't view it in that way. I take my view from large MIT based projects (including expat), and my view is that the license is for the code itself, not the end product of using it.

I think there's a reason that it's explicitly stated in one license and not in others. Also the lineage of MIT (and variations) stripped invasive clauses to make an intentionally more permissive license.

I view it in the light that the Software as defined by the license is the actual thing along with documentation in code form that you're getting (and it mentions those). I don't (and I don't know any big projects using MIT) suggest that the licenses be displayed in the end product in any way or bundled with the application binary. I'm happy to see examples, but I can't find any that aren't adding other clauses instead of clarifying what it means to them.

In the end, I think the ambiguity means that nobody can honestly give a definitive stance and the mutation of use over time has altered the meanings in more ways than just these two that the link suggests.

I will however further clarify the licenses in my own projects to state explicitly that no binary or end product is obliged to do anything, unless copying the code (such that they abide by the license and afford others the same rights they got).

[aduros]

I also understand that MIT is basically the BSD license without having to attribute in binary distributions. Unless other Flump devs really care about this attribution (can't say I do) it could be better to switch just to remove friction.

(By the way, unless openflump uses portions of the AS3 runtime from this repo, you can use whatever license you want.)

[groves]

A more permissive license is fine by me. On Thu, Feb 26, 2015 at 14:09 Bruno Garcia notifications@github.com wrote:

I also understand that MIT is basically the BSD license without having to attribute in binary distributions. Unless other Flump devs really care about this attribution (can't say I do) it could be better to switch just to remove friction.

(By the way, unless openflump uses portions of the AS3 runtime from this repo, you can use whatever license you want.)

— Reply to this email directly or view it on GitHub https://github.com/threerings/flump/issues/137#issuecomment-76285298.

[tconkling]

Done!