Hi Pep,
I haven't personally flown in the IVAO network, but if it is staffed by
realistic real world controllers and maintains similar standards of
professionalism as in the real aviation world, then I could see this being a
really nice option for FlightGear pilots.
The biggest challenge here is the constraint imposed by IVAO that your
protocols must be closed and the only access to your network is through a
dll you provide.
FlightGear is licensed under terms of the GPL and the GPL specifically
disallows linking to a proprietary library simply for the purpose of
avoiding the terms of the GPL which state among other things that any
derivative work must have the same terms of open access as the original work
(applied to the entire application.) There may be some discussion about it
being ok to link to operating system level libraries, but the answer to that
question might depend on if you are speaking with RMS himself or someone who
is a little more pragmatic about life.
The other big issue for us is that if we must live with your shared library,
will you provide an equivalent version for windows, linux, macintosh,
freebsd, solaris, sgi, and all the other platforms that flightgear
supports? If not, which platforms would you be willing to support (or which
platforms do you already support?)
There is nothing wrong with imposing strict closed source requirements
around the use of your work if that is what you chose to do. And likewise
if you do not wish to disclose the details of your communication protocol.
However makes things really tough to try to find a way to integrate your
proprietary work into FlightGear's open structure.
Because of this clash between license terms of closed and open source
software we can't link your library into our code. And because you have
chosen to hide your protocols in addition to the source code, we don't have
a chance to write our own interface to your network.
So what options does that leave?
One possible option I can see at this point is to implement a seperate
gateway process that runs along side FlightGear. (I think this was a
solution that was proposed in the past.) FlightGear would talk to this
proprietary gateway application, which is linked to your DLL and then that
would in turn relay information to and from the IVAO network. The downside
is that this is much more complicated for the user since they would have
another application they'd have to start on their machine along with
FlightGear.
Another possible option might be to write a gateway application that relays
information between the IVAO network and FlightGear's multiplayer network.
That could even live on your server and you could have complete end-to-end
control over it. That should theoretically be possible if your protocols
and dll provide the capability for and end application to report data for
more than one aircraft. It occurs to me that you might not like this option
since it would reduce the level of control you have over individual clients
in the FlightGear world.
So to summarize, I'd love to see some developers push forward with this, but
due to the very strict closed-source requirements of IVAO, we don't have
many options for bridging the gap.
Regards,
Curt.
On Sun, Nov 9, 2008 at 5:11 PM, Pep Ribal wrote:
> Hi all,
>
> my name is Pep Ribal. I belong to the Software Development department of
> the
> IVAO network. Some of you might remember me, as I was involved in a project
> regarding IVAO-FlightGear interconnection time ago.
>
> That specific project was discontinued, but we at IVAO have not forgotten
> about the idea of making FlightGear drop in the network in a future. We
> think this is a good moment to give it a serious try, though changing the
> approach, i.e., not via a separate application.
>
> It would be really positive either for the FG community as well as for the
> IVAO community. FG would benefit from the "real life" human controllers, as
> well as the big amount of virtual pilots available at the same time,
> sharing
> a common airspace between pilots running either FG or other simulators. And
> IVAO would become the first flight sim network that would accept FlightGear
> simmers, which in our opinion would be a huge plus for the network.
>
> I'd like to ask you developers what do you think it would be the best way
> to
> proceed, and what help could we expect from you. The situation is as
> follows:
>
> We are not willing to publish our server protocol. That means that a
> possible module for connecting FG to the servers shouldn't be open source.
>
> We have developed a shared library called the INL (IVAO Network Library),
> freely available at no charge (IVAO freeware), but not open source, that
> would encapsulate all accesses to our servers. A potential FG module for
> connecting to the IVAO servers should link and use this library.
>
> What I would like is to know what do you think it can be done technically,
> what license problems could arise, and see if there's any of you willing to
> help in the possible development of such a software module.
>
> Once I had a clear idea of the best way to proceed, I would hand the
> project
> to IVAO for approval. We would provide you developers with the INL
> binaries,
> and all necessary documentation and other files. Any suggestion is really
> welcome.
>
> Hope something can be done. Thanks to all.
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
