On Nov 12, 2021, at 7:26 AM, Justin Noah Kreikemeyer <[log in to unmask]> wrote:
> 1) Why has there been no release to the maven central repository since
> version 14.0 of MASON? Would it be possible to release the newest
> version? This would make installing it a lot easier (automatic).
Maven support was something handled at length by my students; but with covid and a different project for developing MASON, it dropped off. I don't use maven at all and don't even know how to build for it, so it'll have to be someone else handling that. [In truth, maven is such a pain to build for that we've given serious thought to its value at all].
> 2) As this is my first open-source project, I did a lot of research on
> licensing. I was shocked how confusing the situation regarding license
> compatibility is. I think, the AFL 3.0 might be a good choice for an
> extension, as MASON itself is licensed under AFL 3.0 too.
> However, I am wondering whether further obligations apply to me, since
> MASON uses quite a few dependencies, distributed under a myriad of
> licenses, which might be incompatible (LGPL, MPL, ...). Especially, in
> the case where I distribute a .jar of demo models, which contains all
> those dependencies to be runnable.
> Making things even more complicated, through AspectJ, I modify the
> MASON code automatically at compile-time (right now this applies to the
> Bag, Network, Edge, Steppable and MersenneTwister classes). But I guess
> this is supported by the AFL license/BSD license for the RNG...
> Judging from the website and mailing list archive, there has been some
> work put into license compatibility, so maybe you could clarify the
> situation for me.
Ultimately there are two kinds of licenses: viral licenses (GPL etc.) and academic licenses (BSD, AFL, Apache, MIT). LGPL licenses, when used in the way MASON uses them, generally fit in the academic category. [Let me know which library MASON is using that's MPL: we'll have to deal with that.]
MASON avoids viral licenses so as to broaden its applicability everywhere. This means that if you're developing something that MASON will be relying on, it *must not* be viral. If you're building something on top of MASON, as I think you are, you can do as you please.
MASON's original license was AFL, but that's pretty archaic at this point. If you're just starting building an open source tool on MASON, I would strongly suggest that you use Apache 3.0. That's what I use for all new software. As an academic and research developer I would strongly suggest you do *not* use GPL.
> 3) Would you consider adding the extension to the list on your website?
> Right now it is more of a prototype, meaning it works if you know what
> you do, but I intend to put some more work in to making it more robust
> and adding documentation.
Sure. You have two main options.
1. You maintain the code yourself, at your own location, and we put a link to it on MASON's website.
2. I give you access to MASON's contrib directory, where you'd maintain and store your project. To do this (1) the project should be in pretty good shape and (2) should generally follow MASON style, including documentation and (if it's not too much of a pain) its unusual brace style.
Sean
|
