Erik Hofman wrote: > I'm not sure what to think about this, but ... We already allow for > things like this and I can see the need to drive external HUD code > from within FlightGear (if nothing else for FlightGear's own HUD code > on a separate display).
My understanding was that this was a patch to draw the *internal* HUD using externally loaded code. Basically, it allows someone to write a (non-GPL) C++ class implementing a HUD object and get it to display on the FlightGear display. That was my concern. In the past, our linkage to proprietary projects has been either via well-defined stream protocols (net_fdm, NMEA, etc...) or via the same configuration interface (properties) that we give to the user. This is a little different; instead of defining an external interface and telling proprietary developers "you can use this", it points at an existing code module and tells the proprietary developers "you don't need to worry about the GPL here". The *implementation* of this patch is just plain C++ code, but the *effect* is a change in the license of the project. That kind of design is a slippery slope. We obviously can't/won't apply it to the whole project, because it would be easier to simply re-license it under a more permissive license. So why are we using the GPL in the first place, and what makes the HUD rendering special, that it shouldn't be covered by the same license? Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
