Discussion Orbiter add-ons outside Orbiter?

[Artlav]

Broadly speaking, how would developers in our community feel about their add-ons, generally MFDs, being used outside Orbiter?

First off, add-ons in question are of course the open-source add-ons, as binary compatible Orbiter API implementation would not be worth the waste of effort.
Such code can be used unaltered in other programs and games with a source-compatible implementation of a subset of OAPI, or through an abstraction layer with minimal modifications.
Also, the using program is implied to be free or open-source as well, and the credits are given as asked.

Take TransX for example. It does not specify explicitly that it's code is to be used with Orbiter only anywhere i can notice.
On the other hand, AeroBrakeMFD license specifically states use only within Orbiter community.
There are also Free Orbit MFD and KOST, that are explicitly stated to be for use anywhere.

So, first question is that.

Second question is, what is the morality of explicitly implementing an Orbiter API-compatible interface, or an open OAPI translation layer?

 

[T.Neo]

Every time I hear OAPI, I think of the [ame="http://en.wikipedia.org/wiki/Okapi"]Okapi[/ame]...

 

[Artlav]

OAPI=Orbiter API, as shortened by the common prefix in Orbiter API function calls.

 

[Urwumpe]

Orbiter API

I wouldn't feel exactly bad about it, if the codex is followed.

 

[Face]

Broadly speaking, how would developers in our community feel about their add-ons, generally MFDs, being used outside Orbiter?

First off, add-ons in question are of course the open-source add-ons, as binary compatible Orbiter API implementation would not be worth the waste of effort.
Such code can be used unaltered in other programs and games with a source-compatible implementation of a subset of OAPI, or through an abstraction layer with minimal modifications.
Also, the using program is implied to be free or open-source as well, and the credits are given as asked.

Take TransX for example. It does not specify explicitly that it's code is to be used with Orbiter only anywhere i can notice.
On the other hand, AeroBrakeMFD license specifically states use only within Orbiter community.
There are also Free Orbit MFD and KOST, that are explicitly stated to be for use anywhere.

This is certainly an interesting project, but... what purpose should a MFD have if not used in Orbiter. I mean, besides another space flight simulator, I can't think of a practical reason to use an Orbiter MFD mode in an application. For any special application like trajectory predictors or planning tools, you'd almost certainly have to modify the original code, anyway.

Do you have a specific application use in mind?

Second question is, what is the morality of explicitly implementing an Orbiter API-compatible interface, or an open OAPI translation layer?

As long as you give credit to Martin for designing the OAPI, I guess it'd be fine. Asking for permission would make things clear, too.

my 0.02€, of course...
Face

 

[Artlav]

Specific applications are other space flight simulators and games.
Any game that would try to use real Newtonian physics for interplanetary flights would want a trajectory plotting tool. So why reinvent the bicycle if others have already did the job and are willing to share it?

 

[fsci123]

I do have to say I and a whole bunch of developers use stuff from celestia and other sims but its pretty ethical to ask them first. I wouldn't mind if someone used my ad-dons for their projects as long i was cited properly and i approved of their work.

 

[Face]

Specific applications are other space flight simulators and games.

Yep, that's what I mentioned... so in essence it boils down to the question, if addon developers would be OK with having their code compiled for use in another space sim or game.

I would have no problem with this as long as the resulting addon is distributed according to its license.

regards,
Face

 

[Wishbone]

It may become a dead end as long as the API in another sim diverges or is not updated after changes in OAPI. Maintaining code base for 2 or 3 different apps is a major pain in the OMS... Right now we're struggling with 3 graphics clients.