[DEV] Create an API for other mod's to use

[T145]

This functionality is pretty great, and reminds me of mods like LookingGlass and iChun's GLASS. Instead of adding mod support for all dimension mods out there, you should just create an API for other mods to access. I'd use this in one of my upcoming projects honestly.

It may also be good to look into porting your Kotlin over to raw Java, so you don't have to worry about compiling Kotlin into the mod. Or at least look at dependencies like ShadowFact's Forgelin.

[TheGlitch76]

You (Johni0702) would probably want to relicense as LGPL if you do this so that others can impliment this new API without becoming "infected" with the GPL.

[T145]

APIs in general are separate entities. If the API is made correctly you shouldn't need to package it w/ your mod.

[Johni0702]

INAL but merely using (e.g. extending one of its classes or calling one of its methods) an API should be enough for you to be bound to its license.

However I'm not convinced that "infecting" other mods would be an issue. Linking to a GPL-licensed API merely requires your mod (and dependencies) to be available under a GPL-compatible license. It does not require you to switch your entire mod to exclusively GPL. You can continue using e.g. the Apache License (2.0) and if you ever drop support for the API, it's as if you would have never touched it.

The only mods which this would be an issue for are those not available under a GPLv3-compatible license. GPLv2 (without Or Later), EPL or similar aren't really used in the modding community afaict. Those which are "All Rights Reserved", I'd prefer if they licensed their mod under something more permissive (this is where I'd actually rather not re-license as LGPL).

[T145]

In my experience of being a professional developer, projects you work on don't need to adhere to other software licenses unless you use their code/platform directly, i.e. through copy-paste or repackaging. Merely calling a method from some other source is fine. It's possible that all of the projects I've worked on had licenses that are subsets of all dependencies, but a majority of these projects are proprietary so I find that unlikely. My seniors also follow that mentality, so I trust it.

[Johni0702]

Hm, it seems like that issue is indeed not as black and white as I had remembered it and a definite answer / court ruling has yet to exist (see e.g. this answer on stackexchange).

Anyhow, bundling the API itself should really not be required for any third party mod to use it. So I guess we both agree (though for different reasons) that no re-licensing is necessary.

[TheGlitch76]

That makes sense to me. I've always been more cautious when it comes to licensing issues because I don't want to be on the receiving end of a sue happy developer or contributor to a project that wants to make it case law, which is why I said that in the first place.

On Fri, May 31, 2019, 10:52 AM Jonas Herzig notifications@github.com wrote:

Hm, it seems like that issue is indeed not as black and white as I had remembered it and a definite answer / court ruling has yet to exist (see e.g. this answer on stackexchange https://opensource.stackexchange.com/questions/2829/which-statement-of-gpl-enforces-publishing-source-codes-that-uses-gpl/2831#2831 ).

Anyhow, bundling the API itself should really not be required for any third party mod to use it. So I guess we both agree (though for different reasons) that no re-licensing is necessary.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Johni0702/BetterPortals/issues/17?email_source=notifications&email_token=AEU6AEGYOKK7PXB2QX444WDPYFCTPA5CNFSM4HQQISOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWVTZIA#issuecomment-497761440, or mute the thread https://github.com/notifications/unsubscribe-auth/AEU6AEBW5K2DWYWFN6EALC3PYFCTPANCNFSM4HQQISOA .

[Johni0702]

BP 0.2 now has an API usable by third-party mods. You can look at its source in src/api/…, it's written in Kotlin but should be usable from Java just fine (though it might be a bit clunky in some parts, feedback welcome). Though I haven't tried, using the API via ForgeGradle should work just like any other API/mod available via the CurseForge maven repo (there isn't a separate jar for it, just don't use any of the impl packages), i.e. betterportals:betterportals:0.2.0.

The mod provides two separate APIs.

The view API allows one player to have multiple views. It handles spawning of server-side fake players, tunneling of packets, switching out client-side state, collecting information about which views to render in which order and from which positions and finally also switching of the main view. Additionally, the view API allows different mods to share views where possible (see Ticket).

The portal API builds upon the view API to implement abstract portals (PortalAgent) which handle teleportation, collision checking, rendering, etc. In particular it is sufficiently abstract to be used as an entity, a tile entity or basically anything else (as long as you can implement a PortalAccessor for it). E.g. an abstract portal entity class is provided which is used for the nether, end, TF and Aether portals whereas the Mekanism Teleporter uses a PortalAgent with a tile entity. The portal API also provides everything you need for detection, search and generation of arbitrarily shaped portal frames in PortalBlock.

For an example of how to use the view API, see the implementation of the portal API. For an example of how to use the portal API, see the Vanilla, TwilightForest, Mekanism or Aether implementations.