There aren't that many messages available in TravelPortals; why not make them all configurable, so that this plugin could theoretically be distributed in multiple languages?

It might make sense to make some sort of translation piece in the general plugin framework.

This could use something like my lang library to directly provide multi language abilities (based on client's language) and directly support MineDown too in order to better support RGB colors as well as chat components (hover/click events).

A note on lang though: That library is under GPLv3 so the plugin's binary would need to be distributed under at least the GPLv3 too. (Which the BSD 2-clause license seems to be compatible) That would simply require that all users of the plugin have access to the full source too (Something that shouldn't be an issue seeing as the source is available here on GitHub) but of course it wouldn't change the license of the original BSD 2-Clause licensed code seeing as its more permissive than the GPLv3 already and no re-licensing would be required.

Of course that would be something that mainly @cppchriscpp would need to decide seeing as this is his project.

Hey! I've been watching the conversations, but not really participating in the conversation since you've largely taken over maintenance. (And honestly you're doing a better job than I ever did)

I like this idea, but I think using that plugin would actually force me to change the license for this project. (Which I am pretty against doing a few years after release. That would muddy the waters for anyone who might have a private fork of this around, since it would have consequences, and they might no longer be allowed to maintain that fork with code from the mainline.)

The GPL is complicated and I'm not sure this has been fully tested in court, but if I understand correctly, the server runs all plugins in the same thread, and communicates using data structures such as blocks, etc... which I think might make the plugins + server a "combined program" by the terms of the GPL. (I'm going loosely based off this faq answer) If so, we would be required to change the license for TravelPortals.

I'm not against using the GPL in general, but there are some downsides to it that I don't like. The GPL gives end users a lot of freedoms, but it also puts a ton of requirements on how they use/extend the code. I want people to be able to use this code however they like - including in a commercial closed-source product. (And without spending hours reading documentation to determine if they're allowed to) I also don't want to make a decision on exactly what license anyone forking/extending this code has to adopt - I want that to be up to them. I much prefer say, in effect, "do what you want, just please don't sue me."

I'm open to further discussion, but in general, bringing in any GPL-licensed library leads to a lot of headaches that I'd prefer avoid.

I don't think the license of the code would need to be changed at all. The BSD 2-clause license is compatible with the GPLv3 meaning that BSD 2-clause licensed code can be used in programs distributed under GPLv3. So what would need to be changed is the license under which the plugin is distributed under (e.g. on dev.bukkit) and users would acquire the rights granted by it under the specified conditions.

The major right would be the access to the source code of all contained binaries (which is already provided in this repo as a courtesy by you/us) with requirements that are basically already in the BSD 2-clause license (which is what makes BSD 2-clause compatible with GPLv3 as it (BSD) grants a subset of the GPLv3's rights under compatible conditions).

What I think you are referring to is the perceived vitality of the GPL which isn't necessarily true in all cases. E.g. if we take this situation then, while the plugin's jar file might be distributed under the GPLv3, the licenses of all the contained code does not need to be under GPLv3, it just needs to be GPLv3 compatible. The source code as obtained from GitHub would still be under the BSD 2-clause license with all its rights and without the additional requirements of the GPLv3.

This is the important distinction between source and distribution that many people don't make or see but is explicitly mentioned in any more complex license (even the BSD 2-clause one although the difference is quite miniscule)

Of course you might also be referring to the debated static vs dynamic linking question which might require all code touching GPLv3 library code to be under GPLv3 or a compatible, stronger copyleft license even in source and not distribution form. I personally do not agree that this is the case here: Accessing a library (which's could even be replaced with an alternative implementation of its API) does not qualify as "static linking". The code isn't even included in the source but dynamically loaded when built, all that is depended on is the API specification which could be considered a preexisting "fact". (Of course the resulting binary will "statically link" to this specific library and has to be distributed under GPLv3 and grant all its rights)

And if this view on depending on GLv3 code isn't applied then the whole discussion is pointless anyways: Bukkit is under GPLv3 end any plugin would need to be under GPLv3 anyways to not violate its license. (Which would be quite ridiculous imo and goes against the (imo) goal of the GPLv3: Granting customer/user rights)

Of course I'm no lawyer, just really interested in open source copyright law ever since the CraftBukkit DMCA.

My suggestion would be to solve this using simple INI-Files, for each language a file.

If interested, I would implement it