License

[JayFoxRox]

Help me pick a license.

I currently consider going with GPLv2-only or some form of the LGPL.

(On the other hand I'm worried that FarSight Studios might not like these tools. However I might still want to work for them at some point in the future. So maybe a more restrictive license would be more suitable?)

[Noughtceratops]

This is a really cool project. Did you ever decide on what you'd want to do for a license?

I ask 'cause I have some local changes with some bugfixes, support for native windows compilation, and a little gui frontend. I'd love to upload it and issue a couple pull requests, but that's not compatible with the current license terms.

[JayFoxRox]

Finally some interest :)

No, I have never decided on a license, but I'd probably go with GPLv2-or-later for the codebase.
Is that fine with you?

I'd rather see this as some form of lib, or CLI tool, where frontends remain in separate projects (I'm really unhappy with all my ugly in the repository too).
But I'm happy to accept any new changes to the core-parsing and conversion routines. Ideally your patches would be licensed under BSD license or something, so I can re-license at a later point if necessary (there are some incompatibilities with GPL and certain platfoms I might want to support in the very distant future).

[Noughtceratops]

Yeah, I don't have a strong opinion on license - GPLv2 seems fine; I personally think it's good to keep tools like these under noncommercial terms. I prefer to submit patches under whatever license the original project was created under for simplicitly; if you're looking to re-license in the future, it's more a copyright issue than a licensing issue, and I'd recommend setting up a contributor license agreement. There are some tools like CLAHub that can make CLA's relatively easy to execute.

I'm happy to submit patches for just the underlying code and distribute the frontend separately, though it'd be cool to have one repository aggregate gui frontends and stuff, so that it's easier for people to take advantage of. The only reason I came across this project was because a friend came across it but couldn't figure out how to get it to build (and would've gotten stuck trying to use the bash scripts if he'd gotten past that point). You might have some latent demand for this project obscured by the fact that it's not very accessible to the average pinball enthusiast.

[JayFoxRox]

Sorry for taking so long. I got distracted with other projects.

GPLv2 seems fine

I've opened #3 (please review), even though I'm still a bit unhappy with the GPL. There's some issues with app-store compatibility (even freeware) and me having to give away many of my rights, possibly leading to monetization (by others) and other things I don't like.
Especially with preservation (as this was intended for pinball simulation), I'd rather have a license which will not pose a problem. Especially with the developments of the GPL and the rise of closed-platforms, I don't really trust the GPL.

That said, my old license was pretty horrible (mostly to get feedback here). I also don't currently plan to work for FarSight, PBA appears to be on a downhill slope, and the project is not complex enough to make it hard to rewrite, if anyone has an issue with the GPL.
Even then, it's kind of tricky do do anything useful with the generated output because FarSight themselves put a very restrictive license on the input files. So the license on this repo is not that important.

I personally can also always revert back to this version, where I'm the sole author of the code.
For the record: I'm willing to offer the current version of the code under other licenses, if there's a good reason for it.

I'd recommend setting up a contributor license agreement.

I'm aware of CLAs, and I use them on OpenSWE1R.
I'm against a CLA this time, because it's such a niche project, and a CLA just complicates things. Some people also don't tolerate a CLA, which has been a problem in the past - I don't want to scare away potential contributors.

I'm happy to submit patches for just the underlying code and distribute the frontend separately, though it'd be cool to have one repository aggregate gui frontends and stuff, so that it's easier for people to take advantage of.

Submodule should work? I simply don't have much time to review or test changes.
I think it's also cleaner to separate these tools / turn this into a lib.
This code was originally meant to bootstrap my own pinball simulation, and I feel adding more tools here, just makes it harder to integrate it in those projects.
In fact, I'd even like to see this split into libpbarez (decompression & conversion routines) and pba-tools (converters and blender scripts).

You might have some latent demand for this project obscured by the fact that it's not very accessible to the average pinball enthusiast.

Yes, I'm aware; also see #2.
Any PRs to address this would be welcome.