opengc-devel — Developer's discussion list

[Opengc-devel] Theoretical question re: customization

[Pollack,Matthew E. <mpo...@mi...>]

We at MITRE have been using OpenGC for a few months now, and have
recently run into an issue that we are not sure how to tackle.  We have
a custom, internally developed flight simulator that has both outputs
that MSFS, FG and X-plane do not have and requires inputs different from
the aforementioned flight sims.  Up until now, we have been adding
variables to the ogcDataSource class to support our needs.  However,
this precludes us from making a smooth transition to newly released
versions of OpenGC.  Does anyone have any ideas as to how we might be
able to both support our needs, while, at the same time not breaking any
backward compatibility with the reference implementations of OpenGC?

[Opengc-devel] Question about interface

[<ale...@el...>]

Hello all!

We are considering to make interact a solid state gyro with other
hydro-pneumatic equipment, and we will need some interface ARINC alike, and
I am very curious if someone of this group had make such arrange and could
recommend an interface provider or other ideas to make concur the gyro with
this other acting devices.

Thanks in advance, any advise will be welcomed.

Re: [Opengc-devel] Issues loading texture

[Damion S. <be...@cs...>]

Ok, I have a couple other ideas I can try. Is there some example code 
you can send me so that I can replicate the problem? It might make 
debugging easier.

-Damion-

On Tuesday, October 28, 2003, at 10:32 AM, Stein,Jeffrey L. wrote:

> As far as I can tell this fix did not solve the problem.  I updated 
> the ogcAppObject code with the change you suggested.  We still have 
> the same problem where when instantiated in the constructor the 
> texture will not draw, where as when instantiated in the render loop 
> it will draw.  I tested on both windows and linux to no avail.
> Do you have any other ideas?
> -Jeff
>
> Damion Shelton wrote:
>
>> Hi,
>>
>> It's possible that because of the way in which FLTK does things that 
>> the OpenGL device context was not correctly initialized while the 
>> gauges were being loaded. I modified the AppObject class to force a 
>> display redraw prior to loading the gauges; assuming your code was 
>> working fine in the render loop, this is the only event that was NOT 
>> occurring prior to the gauges being loaded. Grab a CVS update and let 
>> me know if this fixed your problem.
>>
>> -Damion-
>>
>> On Wednesday, October 22, 2003, at 10:53 PM, Stein,Jeffrey L. wrote:
>>
>>> The following has been tested on both a linux build and a windows 
>>> visual c++ build of open glass cockpit.
>>> In trying to load a texture in a gauge constructor the texture is 
>>> never displayed.  However if the texture is loaded in the gauges 
>>> render loop it displays fine.  We suspect that openGL is not 
>>> correctly initialized to the point that it is able to hold textures 
>>> during the time that gauges are constructed.  Does anybody have any 
>>> information on this?
>>>
>>> -Jeff
>>
>>
>> ---------
>> Damion Shelton
>> The Open Source Glass Cockpit Project (OpenGC)
>> Carnegie Mellon University, Robotics Institute
>> http://www.opengc.org
>> da...@op...
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by OSDN developer relations
>> Here's your chance to show off your extensive product knowledge
>> We want to know what you know. Tell us and you have a chance to win 
>> $100
>> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
>> _______________________________________________
>> Opengc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opengc-devel
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel
>
>

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I wish I would have a real tragic love affair and get so bummed out 
that I'd just quit my job and become a bum for a few years, because I 
was thinking about doing that anyway.

Re: [Opengc-devel] Request for Changes to ogcFontManger

[Damion S. <be...@cs...>]

Good suggestion, I'll let you know once I add it.

-Damion-

On Tuesday, October 28, 2003, at 01:32 PM, Stein,Jeffrey L. wrote:

> I was wondering if you would be adverse to adding the following 
> overloaded methods to the print manager.  It simply allows the calling 
> of a print command with a c++ style string.
>
>
> -------- ogcFontManger.cpp --------------
>
> void ogcFontManager::Print(double x, double y, string text, int font)
> {
>  if( (font >= 0) && (font < m_NumFonts) )
>  {
>    m_FontList[font]->Print(x,y, (char*)text.c_str());
>  }
> }
>
>
> ---------- ogcFontManager.h -------------
>
> //! Print a character string at location (x,y) using specified font
>  void Print(double x, double y, string text, int font);

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

[Opengc-devel] Request for Changes to ogcFontManger

[Stein,Jeffrey L. <js...@mi...>]

I was wondering if you would be adverse to adding the following 
overloaded methods to the print manager.  It simply allows the calling 
of a print command with a c++ style string. 



-------- ogcFontManger.cpp --------------

void ogcFontManager::Print(double x, double y, string text, int font)
{
  if( (font >= 0) && (font < m_NumFonts) )
  {
    m_FontList[font]->Print(x,y, (char*)text.c_str());
  }
}


---------- ogcFontManager.h -------------

 //! Print a character string at location (x,y) using specified font
  void Print(double x, double y, string text, int font);

Re: [Opengc-devel] Issues loading texture

[Stein,Jeffrey L. <js...@mi...>]

As far as I can tell this fix did not solve the problem.  I updated the 
ogcAppObject code with the change you suggested.  We still have the same 
problem where when instantiated in the constructor the texture will not 
draw, where as when instantiated in the render loop it will draw.  I 
tested on both windows and linux to no avail. 

Do you have any other ideas?
-Jeff

Damion Shelton wrote:

> Hi,
>
> It's possible that because of the way in which FLTK does things that 
> the OpenGL device context was not correctly initialized while the 
> gauges were being loaded. I modified the AppObject class to force a 
> display redraw prior to loading the gauges; assuming your code was 
> working fine in the render loop, this is the only event that was NOT 
> occurring prior to the gauges being loaded. Grab a CVS update and let 
> me know if this fixed your problem.
>
> -Damion-
>
> On Wednesday, October 22, 2003, at 10:53 PM, Stein,Jeffrey L. wrote:
>
>> The following has been tested on both a linux build and a windows 
>> visual c++ build of open glass cockpit.
>> In trying to load a texture in a gauge constructor the texture is 
>> never displayed.  However if the texture is loaded in the gauges 
>> render loop it displays fine.  We suspect that openGL is not 
>> correctly initialized to the point that it is able to hold textures 
>> during the time that gauges are constructed.  Does anybody have any 
>> information on this?
>>
>> -Jeff
>
>
> ---------
> Damion Shelton
> The Open Source Glass Cockpit Project (OpenGC)
> Carnegie Mellon University, Robotics Institute
> http://www.opengc.org
> da...@op...
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel

[Opengc-devel] library version clarification

[Damion S. <da...@op...>]

A few people have asked about the versions of the various libraries 
required to build OpenGC. I just tested the following configuration:

Freetype 2.14
FTGL 2.07
Plib 1.6
FLTK 1.1.4

These are in general the most recent releases of the libraries, except 
when the most recent release is considered development/unstable. You 
should not encounter any major problems building these libraries; the 
only exception is building FTGL under Windows, which requires some 
editing of the project file to point to the correct Freetype directory 
(instructions on this are included with FTGL).

Cheers,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

Re: [Opengc-devel] Issues loading texture

[Damion S. <da...@op...>]

Hi,

It's possible that because of the way in which FLTK does things that 
the OpenGL device context was not correctly initialized while the 
gauges were being loaded. I modified the AppObject class to force a 
display redraw prior to loading the gauges; assuming your code was 
working fine in the render loop, this is the only event that was NOT 
occurring prior to the gauges being loaded. Grab a CVS update and let 
me know if this fixed your problem.

-Damion-

On Wednesday, October 22, 2003, at 10:53 PM, Stein,Jeffrey L. wrote:

> The following has been tested on both a linux build and a windows 
> visual c++ build of open glass cockpit.
> In trying to load a texture in a gauge constructor the texture is 
> never displayed.  However if the texture is loaded in the gauges 
> render loop it displays fine.  We suspect that openGL is not correctly 
> initialized to the point that it is able to hold textures during the 
> time that gauges are constructed.  Does anybody have any information 
> on this?
>
> -Jeff

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

[Opengc-devel] Issues loading texture

[Stein,Jeffrey L. <js...@mi...>]

The following has been tested on both a linux build and a windows visual 
c++ build of open glass cockpit. 

In trying to load a texture in a gauge constructor the texture is never 
displayed.  However if the texture is loaded in the gauges render loop 
it displays fine.  We suspect that openGL is not correctly initialized 
to the point that it is able to hold textures during the time that 
gauges are constructed.  Does anybody have any information on this?

-Jeff

Re: [Opengc-devel] Compiling the latest version of openGC with CYGWIN

[Stein,Jeffrey L. <js...@mi...>]

Ok,  So I deceided to start from scratch.  I downloaded a clean cvs 
developer copy of open gc.

First step was to compile the ExternalLibaries

compiled: freetype-2.1.0.tar.gz (works)

Upon trying to comiple FTGL I run into an error:  Freetype Version >= 
9.0.3  ...
It says I need a different version of freetype to install. 

In previous itterations of this cygwin process I downloaded a newer 
version of freetype(2.1.5) for example and this seemed to over come this 
problem. 

What version of freetype do you reccomend using?  I would assume the one 
in the developer archive would be correct, if this isnt the case please 
let me know. 

I was able to compile FTGL with freetype-2.1.5 i think, but its possible 
I ran into additional issues with an FT_Open_Flag call in 
openGlassCockpit which does not exist anymore in freetype-2.1.5

As I seem unable to get past this initial setp, I'll wait for more 
information before I start hacking away trying to make things work.

Re: [Opengc-devel] Compiling the latest version of openGC with CYGWIN

[Damion S. <da...@op...>]

Hi,

Please go ahead and send the detailed information on the linking
errors. I tested the CVS version under both Windows (Visual Studio) and
Mac (gcc) and they both compiled & linked without problems.

Offhand, I suspect that the linking problem is related to how CMake
does or does not detect Cygwin as a valid Unix/Win32 system. Is the
_WIN32 symbol defined during GCC compiles under Cygwin? Right now, the
logic is set up something like:

Is the system Win32?
    Yes. Use Windows OpenGL API.
Is the system Unix?
    Is it a Mac?
      Yes. Use the Carbon GL framework.
      No. Use the X11 GL framework.

I have used cygwin very little, and from what I've read online, _WIN32
is not defined as a valid compiler symbol under GCC in cygwin. This
means that the system would detect the OS as Unix, but not Mac, and
would try to use the X11 GL libraries (which is not correct either).

Some additional poking around suggests that the following procedure may
work, though I have not tested it. CMake is used to build the
Visualization Toolkit as well, and it sounds like similar linker errors
were encountered. Their solutions was:

---<snip>---

1. cmake.  You need to have cmake running under CYGWIN.  This is
available
as a standard package now.  You can install it from any CYGWIN
distribution
mirror.  This sure beats building it by hand.

2. opengl header files.  You must move or delete the opengl headers in
/usr/X11R6/include/GL (gl.h, glu.h,.....).  These header files are not
congruent with opengl32.  The -I flag in the makefile forces these
header
files to be found first, if they are present.  If you fail to do this,
you
will get a bunch of undefined library errors when you try to link the
vtk
libraries with an application.  The correct headers are present as part
of
the w32api package.

3. w32api.  You must have a recent version of w32api.  This insures that
your build will correctly reference opengl-1.1.  I suggest installing
the
lastest one from a CYGWIN distribution mirror.

---<snip>---

The full text of the message I grabbed that procedure from can be found
at http://public.kitware.com/pipermail/vtkusers/2003-January/015655.html

Let me know if there's anything else I can help you with, or if you
want me to take a look at the link errors.

Cheers,
-Damion-

On Wednesday, October 22, 2003, at 11:08 AM, Stein,Jeffrey L. wrote:

> Hi all,
>
> I was wondering if anybody has managed to compile the lastest version 
> of OpenGlass cockpit on cygwin.  I did a co install on linux and 
> cygwin and while I found both installs were quite buggy, especially 
> the building of the FTGL libraries finally we managed to get the linux 
> version working.  The cygwin install, however, ran into some issues.  
> Two cpp files would not compile at first but then I managed to fix 
> those issues.
>
> Currently after about 6 hrs of trying I have given up.  I can build 
> the app but it is not linking correctly.  Before I post detailed 
> information I was wondering if anybody has in fact managed to compile 
> under cygwin / gcc lately.
>
> Any help would be appreciated.  I will try to debug the linking errors 
> later today.
>
> -Jeff Stein

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I hope that after I die, people will say of me: "That guy sure owed me 
a lot of money."

[Opengc-devel] Compiling the latest version of openGC with CYGWIN

[Stein,Jeffrey L. <js...@mi...>]

Hi all,

I was wondering if anybody has managed to compile the lastest version of 
OpenGlass cockpit on cygwin.  I did a co install on linux and cygwin and 
while I found both installs were quite buggy, especially the building of 
the FTGL libraries finally we managed to get the linux version working. 
  The cygwin install, however, ran into some issues.  Two cpp files 
would not compile at first but then I managed to fix those issues.

Currently after about 6 hrs of trying I have given up.  I can build the 
app but it is not linking correctly.  Before I post detailed information 
I was wondering if anybody has in fact managed to compile under cygwin / 
gcc lately.

Any help would be appreciated.  I will try to debug the linking errors 
later today.

-Jeff Stein

[Opengc-devel] email update

[Damion S. <be...@cs...>]

Hi,

The mail handling for opengc.org is moving to a new (better) system. 
There is a slight possibility that mail sent to da...@op... 
during the next 24 hours may bounce, after which it should be easier 
for me to keep track of my opengc mail.

Cheers,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

[Opengc-devel] status update

[Damion S. <be...@cs...>]

Hi, a quick update on where I'm at with the proposed rewrite...

I spent last weekend upgrading my sim and glass cockpit computers (it's 
amazing what $550 will buy you these days), so I have not made a lot of 
progress on coding. This should greatly speed up compilation on the 
glass cockpit machine, so hopefully the time spent on the upgrade will 
be worth it.

One thing I would like to toss out is the idea of abstracting OpenGC 
away from a particular windowing toolkit. As I've looked into modeling 
OpenGC more after the Visualization Toolkit (VTK, http://www.vtk.org ) 
it's occurred to me that we could fairly easily adopt their rendering 
model as well. VTK implements its own native OpenGL contexts for 3 
general classes of machine (Windows, X11, and Mac), and then provides 
hooks so that these can be easily packaged into larger applications. 
For instance, you can choose to embed the window in FLTK, Windows (via 
the Microsoft Foundation Classes), Tcl/Tk, Java, etc. In fact, with 
suitable code wrapping (also from VTK) it should be possible to use 
OpenGC windows and gauges as objects within other languages, which 
would be great for people who are interested in writing a custom app 
with OpenGC but don't know C++.

This would increase the complexity of the code within OpenGC 
_slightly_, though the VTK license permits use of that code without 
restriction so porting should not be a huge deal. It's unlikely that 
gauge-oriented developers would notice much of a change, since this is 
all fairly low-level stuff. The major advantage I can see this 
providing is that the final "application" could be more easily tailored 
to a specific purpose; i.e., if you want to create an elaborate GUI in 
Windows, you don't have to rewrite anything. Similarly, if you want a 
completely bare-bones application running under X, you don't have to 
drag along the baggage of a more complex windowing system.

Feedback is of course welcome. Of course, for the average end user, I 
still plan to release something similar to what we have now that will 
let you configure a gauge layout in a text file.

Cheers,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

Re: [Opengc-devel] status/Avsim conference update/RFC

[John W. <ca...@mm...>]

> However, as I've said, the only difference between the
> current and proposed versions are the ability to use the code without
> restriction. Trying "a commercial venture that involves a high level of
> risk" is not prohibited under the current license...
>
Understand the risk I allude to is not the lose of capital or business
failure, but the loss of life and limb. Burt Rutan finally gave up licensing
the long-ez design because of litigation and pressure from his commercial
partner BeechCraft ( I believe) The Starship while a radical design for a
business class aircraft met all FAA standards and certs, but it never was
able to shed that image of "experimental".

My hunch is that OpenGC will die a quiet death and I wish you well in your
new venture.

Regards
John W.

Re: [Opengc-devel] status/Avsim conference update/RFC

[Damion S. <be...@cs...>]

Hi,

> So why should anyone contribute source code to an open-source project 
> that
> anyone can use for profit without providing any value added from a 
> derived
> product? I cuts both ways.

It's a personal choice. It depends I suppose on whether or not you 
consider the change so novel as to be revolutionary. E.g., if I notice 
a small bug (let's say a color is a little off) in OpenGC, I'd probably 
be willing to make the change even understanding that someone else may 
profit from it. If I come up with a completely revolutionary gauge 
design, the question is a bit more difficult. All I can say is that 
this model _has_ actually been successful...

> Example, I've got a pretty decent FMC running on
> my system ( My masters thesis at Purdue was on control and 
> optimization of
> shuttle approach trajectories) and with a little effort and 
> application of
> current control theory you could turn it into a reasonable autopilot. 
> That
> code will NEVER leave the confines of my hard drive.

Regarding the FMC, that's certainly your prerogative. Likewise, a bunch 
of the code I've written at work will remain private as well. But, your 
FMC also illustrates my current frustration with OpenGC - lack of code 
being contributed back.

> Plus there is the added potential for litigation.
>
> The last thing I need is for someone to grab all or part of my code 
> and the
> algorithms, put out a commercial product, and the next thing I know my
> attorney and I are in court because either the manufacturer goofed in
> modifying the code and/or some idiot pilot flew into the side of a 
> mountain.
> Yes, I know what the license and warranty state...  try telling that 
> to the
> judge and jury. And funny how lawyers seem to gravitate towards "deep
> pockets"

Well, it seems that this risk applies with the GPL as well. The only 
added requirement with the GPL is that the source be made available. 
I'm a bit skeptical that releasing the source provides any sort of 
legal buffer as far as liability goes. If this was a real concern, open 
source couldn't exist. With both projects I've been involved with (VTK 
and ITK) the liability is placed on the system integrator, who is 
responsible for testing to the satisfaction of the regulatory agencies 
involved, primarily the Food & Drug Administration with what I've done 
so far. This is in fact a main argument for permitting commercial 
development of open source code; getting regulatory approval for these 
sorts of products is insanely expensive.

> I don't know what to suggest. You seem determined to try a commercial
> venture that involves a high level of risk ( wonder why they call it
> experimental/home built ) with software and derivations based on an
> open-source license and project that started out as a learning 
> exercise.  I
> simply cannot agree with such a change

Understood. Hopefully the proposal I mailed out will address this. As I 
mention in it, any revised license version will be available for you 
(and others) to examine and verify that none of the "debated" code is 
included. However, as I've said, the only difference between the 
current and proposed versions are the ability to use the code without 
restriction. Trying "a commercial venture that involves a high level of 
risk" is not prohibited under the current license...

> Hopefully, you understand my position.

Yes, I do. I hope you understand mine is well, even if you don't agree 
with it.

Best,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

[Opengc-devel] copyright notes from VTK

[Damion S. <be...@cs...>]

Hi,

This stuff is on the web at http://www.vtk.org/contribute.php but for 
discussion purposes it's worth re-posting here. I am suggesting that 
the following "contribution standards" apply to a future rewrite of 
OpenGC. A large, active, community of developers has judged the 
following standards acceptable, so this is a good starting point...

<snip>

Contributing code to vtk is simple: write good, general-purpose code 
following our coding standards. Make sure that you include our 
copyright in your code. Also make sure the code is compatible with our 
automated Tcl wrapping procedure. Finally, realize that the code you 
contribute can be used in commercial products by anybody (without 
compensation to you), and that contributed code is owned (via 
copyright) by Ken Martin, Will Schroeder, and Bill Lorensen.

See detailed explanations in the following.

Copyright Issues

When you contribute code to vtk, Ken Martin, Will Schroeder, and Bill 
Lorensen own it. We are doing it this way because of logistics issues: 
legal decisions or modifications to the code would become completely 
unworkable if there were mixed copyrights. However, we do want to 
credit and give thanks to those people that make the effort of creating 
code. To do this, modify the standard copyright notice by adding a 
"Thanks:" field that states your name and/or affiliation. See 
vtkEarthSource for an example.

If this is unacceptable to you: then either don't contribute code at 
all, or (optionally) we may set up a contributed code repository that 
we DO NOT maintain, test, or distribute, but DO reference on our web 
site(s).

Commercialization Issues

When you contribute code to vtk, the code may be used in commercial 
products without condition. You will not receive any commercial gain as 
a result of the use of your code in a commercial product (either do we 
for that matter). Only contributed code meeting this condition will be 
accepted.

Obligation to Integrate Code

We often find ourselves in the position of receiving code that meet the 
above conditions, but are unable to integrate it into vtk. This may be 
because the code is not general enough, is judged to require additional 
development, or does not add enough value to vtk.

If you are a contributor affected by a decision to not integrate your 
code into vtk, or delay integration into vtk, we apologize. Please 
recognize that we are struggling to keep the complexity of the system 
at a managable level, and to make sure enough testing is performed to 
distribute a good system.

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...



---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I hope that after I die, people will say of me: "That guy sure owed me 
a lot of money."

Re: [Opengc-devel] status/Avsim conference update/RFC

[John W. <ca...@mm...>]

Hi
>
> So here's the problem... if the source code and binaries are made
> completely available for a finished product (I'm talking here about the
> homebuilt aircraft market), what's to stop some other hardware company
> - presumably with more resources than me - from releasing a competing
> product derived completely from OpenGC? While it is technically not
> legal to do this without also releasing the source code, I don't know
> that it would be possible to prove that they violated the GPL without a
> lengthy court process.
>
So why should anyone contribute source code to an open-source project that
anyone can use for profit without providing any value added from a derived
product? I cuts both ways. Example, I've got a pretty decent FMC running on
my system ( My masters thesis at Purdue was on control and optimization of
shuttle approach trajectories) and with a little effort and application of
current control theory you could turn it into a reasonable autopilot. That
code will NEVER leave the confines of my hard drive.

Plus there is the added potential for litigation.

The last thing I need is for someone to grab all or part of my code and the
algorithms, put out a commercial product, and the next thing I know my
attorney and I are in court because either the manufacturer goofed in
modifying the code and/or some idiot pilot flew into the side of a mountain.
Yes, I know what the license and warranty state...  try telling that to the
judge and jury. And funny how lawyers seem to gravitate towards "deep
pockets"

I don't know what to suggest. You seem determined to try a commercial
venture that involves a high level of risk ( wonder why they call it
experimental/home built ) with software and derivations based on an
open-source license and project that started out as a learning exercise.  I
simply cannot agree with such a change

Hopefully, you understand my position.

Regards
John W.

[Opengc-devel] opengc "toolkit" proposal

[Damion S. <be...@cs...>]

Hi folks,

I've been doing some thinking over the past few days about how to 
address the future of OpenGC (both in terms of where it's going in 
functionality and development). I think I'll throw the following out as 
a straw man proposal to get feedback on. To summarize, since the 
following may be a bit long-winded: OpenGC will be rewritten into a 
form of which I am the sole author (or have express written permission 
to include the code of others), after which it will be released as open 
source under a license modeled after the VTK license.

1) I will completely rewrite OpenGC based in part on my source code 
from pre Dec. 2001 (the date of the first CVS contributions of others), 
in part on modern source code about which there is no dispute regarding 
sole authorship (the font manager, X-Plane data source, the NEW nav 
database, etc.), and in part on a new design I've been working on based 
on the ITK and VTK toolkits, http://www.itk.org and http://www.vtk.org 
respectively.

2) Under this new design, the appobject would disappear completely, as 
would the gauge and gaugecomponent classes (to be replaced by a more 
general widget class). Objects would also be reference counted, using 
smart pointers, to avoid memory leaks. The eventual goal would be to 
provide something along the lines of VTK; i.e., a finished 
"application" as such is not provided, but the tools to rapidly produce 
one are. Example applications would of course be included, but more 
full-featured applications (with advanced mouse interaction for 
instance) would be left as an exercise for the reader. Under this 
model, an application main() might look something like:

main()
{
	ogcRenderer* pRen = ogcRenderer::New();
	ogcDataSource* pDataSource = ogcFSUIPCDataSource::New();

	ogc777PFD* pPFD = ogc777PFD::New();
	pPFD->SetDataSource(pDataSource);
	pRen->AddWidget(pPFD);
}

The above code may look a bit odd to those of you not familiar with 
VTK, but is intended to show the basic steps involved in creating a 
simple one-gauge display that drives a 777 PFD from FSUIPC. The _major_ 
advantages of switching OpenGC to this modular approach are:

A) It becomes possible to use the CABLE tool ( 
http://www.itk.org/HTML/CableSwig.html ) to generate wrappings in other 
languages. Prefer to code your GUI in Java or Tcl? No problem. This 
would address the common question of "can I use OpenGC in language X".

B) OpenGC is not tied into a particular application framework. As it 
stands, OpenGC doesn't really exist without AppObject and main.cpp - it 
would be nice if this weren't true.

3) This code would be distributed under a modified form of the Kitware 
license/VTK toolkit copyright. This is an extremely open license (do 
whatever you want), with one exception: the version of _contributed_ 
code placed in the repository becomes copyrighted solely by myself. All 
users and developers still retain full rights to use and redistribute 
the code, with or without modifications, with or without included 
source.

I've talked to Kitware in the past, and they have adopted this license 
purely to avoid copyright dispute regarding the code INSIDE the 
repository; as the license states, users are still free to do WHATEVER 
THEY WANT with the code. Please take a look at the license here: 
http://www.vtk.org/copyright.php

This is likely to be the portion of this proposal that creates the most 
angst among others, so feedback is encouraged. Please keep in mind that 
this license has worked extremely well for Kitware; VTK has something 
on the order of 2000 active developers. The copyright clause does not 
mean that you're giving up copyright to code you've written; you're 
free to publish another version elsewhere copyrighted solely by 
yourself.

4) As I produce a "sanitized" version of OpenGC, it will posted for 
everyone to see. I do not want to be accused of using code which 
someone else may legitimately have a claim to, so the entire revision 
process will be conducted in the open. After it has been established 
that I am the sole author of version "X" of OpenGC, it will again be 
opened up for public contributions under the new license terms.

5) Code for which permission cannot be obtained for inclusion in OpenGC 
mark II will have to be removed from the repository. I will try and 
work with the FlightGear folks to produce a non-GPL'd version of the 
FlightGear data source. All of the data sources will be changing 
dramatically, both in function and variable names. The current version 
is very poorly designed, by my own admission, and does not allow any 
form of bi-directional communication.

Given how well things have worked out for the Kitware folks and the 
users of VTK (of which I am one) I think this is probably the best 
direction in which to proceed. I realize that this will effectively 
halt new development of OpenGC for 4-6 weeks during the rewrite, but 
I'd rather get this sorted out sooner rather than later. The current 
version of OpenGC, as licensed under the GPL, will continue to be 
available for download even after the new version is released.

Feedback is encouraged...

Cheers,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

Re: [Opengc-devel] status/Avsim conference update/RFC

[Damion S. <be...@cs...>]

Hi,

> As I understand the GPL there is nothing to preclude the use of 
> open-source
> software for commercial purposes provided the resultant code is 
> provided
> and/or made available along with the binary executable. The problem 
> arises
> trying to distinguish between source code that is integral to the 
> program
> vis-a-vis programs that link to a library or can be considered unique 
> and
> seperate

So here's the problem... if the source code and binaries are made 
completely available for a finished product (I'm talking here about the 
homebuilt aircraft market), what's to stop some other hardware company 
- presumably with more resources than me - from releasing a competing 
product derived completely from OpenGC? While it is technically not 
legal to do this without also releasing the source code, I don't know 
that it would be possible to prove that they violated the GPL without a 
lengthy court process.

> IMO OpenGC in it's current form and structure is not amenable to the 
> spirit
> and intent of the GPL

Really, why is that? I've contributed everything I've done back to the 
project, provided a CVS server using my own resources, and paid for the 
web site out of my own pocket. All of the existing code is GPL'd, and 
all of the contributing authors are credited in the header of each 
file. I haven't made any money off of OpenGC to date, nor do I have an 
existing commercial project.

> Quite frankly, starting an open-source project and
> then suggesting a change in the license is a bit ingenuous.

Not really, as long as the new license is also open source. Something 
like the MPL simply says, "Do whatever you want as long as you 
contribute any code changes back to the project". In many ways, this is 
less restrictive than the GPL. Keep in mind that, given that I provided 
the initial codebase for the project and have been maintaining it on a 
solo basis for the past year, I would have the most to "lose" from such 
an approach since I would essentially be opening up my work to 
commercial development by others.

> My suggstion
> would be to go for a "clean room" approach, but that will require a 
> third
> entity not exposed to the source to create a spec or design document 
> based
> on observations of the programs performance.

I don't think so. Such a third party doesn't really exist, nor do I 
think one is necessary. I can always push development back to where I 
was prior to August 26 2001, since I have archive copies on CD. As I 
said, if the closed-source route were taken (and I'm now leaning 
towards trying to find a compromise that would allow the project to 
continue largely as open source) the best I can do is promise that I 
would not use anyone else's code in a closed source product. The GPL 
does not amount to a non-competition agreement.

> Trying to produced closed-source and open-source programs under the 
> same
> license will most likely result in the open-source side stagnating and
> eventually being overwhelmed by the closed-source-portion. It would 
> have a
> very chilling effect on new ideas and innovations from the community at
> large.

I disagree. If the bulk of the code is licensed under something like 
the MPL, then it would be up to developers to provide a value-added 
product. For instance, I could run everything _but_ the EGyro project 
as open source. As an example, I point out Kitware Inc. They have been 
quite successful running VTK as an open source product, yet also 
distributing a payware application called VolView that uses some of the 
components of VTK wrapped into a slick interface.

Also, I believe the Mozilla/Netscape example contradicts the "chilling 
effect" example; if anything, the Mozilla project has hurt Netscape's 
bottom line since their releases are often better than Netscape's. If 
the project really _is_ viable from an open source standpoint, then the 
community at large can create a completely open-source alternative to 
whatever commercial product is released. If not, then the community 
benefits from someone going the extra mile to create a polished 
commercial product.

Anyways, it seems like there are two options:

1) Start from scratch, create a new closed-source product that is 
functionally similar to OpenGC but based on new code (or on code from 
the original project prior to the Sourceforge days). As I would have to 
do this myself, there would be little incentive to continue development 
of the original OpenGC and this would effectively kill the project.

2) Re-license OpenGC under a less restrictive license more amenable to 
commercial development. This would allow the bulk of the code to remain 
publicly available, while still making it feasible to pursue a 
commercial product.

Personally, it seems like option 2 is the best route at this point.

-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I hope that after I die, people will say of me: "That guy sure owed me 
a lot of money."

Re: [Opengc-devel] status/Avsim conference update/RFC

[John W. <ca...@mm...>]

> Thoughts? Opinions? John - since you're the other major developer in
> the history of OpenGC, what do you think about this?
>
As I understand the GPL there is nothing to preclude the use of open-source
software for commercial purposes provided the resultant code is provided
and/or made available along with the binary executable. The problem arises
trying to distinguish between source code that is integral to the program
vis-a-vis programs that link to a library or can be considered unique and
seperate

IMO OpenGC in it's current form and structure is not amenable to the spirit
and intent of the GPL. Quite frankly, starting an open-source project and
then suggesting a change in the license is a bit ingenuous. My suggstion
would be to go for a "clean room" approach, but that will require a third
entity not exposed to the source to create a spec or design document based
on observations of the programs performance.

Trying to produced closed-source and open-source programs under the same
license will most likely result in the open-source side stagnating and
eventually being overwhelmed by the closed-source-portion. It would have a
very chilling effect on new ideas and innovations from the community at
large.

Regards
John W.

Re: [Opengc-devel] status/Avsim conference update/RFC

[Manuel B. <li...@va...>]

Hi Damion,


On Mon, Sep 29, 2003 at 07:30:58PM -0400, Damion Shelton wrote:
> Ok. Do you think it would be possible to reach an agreement to 
> relicense the "base code" portion of OpenGC under the LGPL or BSD?

LGPL should be the easiest. BSD is too different (you know, there are
the GNU people and there are the BSD people)

With BSD, anyone can take the code and use it. Without telling you,
without contributing back changes... 
Like M$ uses the BSD TCP/IP stack in Win*. 

It might be worth looking at licenses of Mozilla and OpenOffice (MPL and
?) since they use the development model that I was using as an
illustration.

Why not propose to all the other contributors of OpenGC these ideas and
the choices of licenses and see what they say.

> There are a few technical issues (handling multiple GUI interfaces for 
> example) that would have to be addressed, but they're probably not 
> insurmountable.

Yeah, esp. when you have binary modules. Thats why I would prefer the
"source -module" way. 

> > For me the most important about OpenGC is the fact its free software 
> > and
> > the code is open source.
> 
> Well, that's what I had hoped for as well. Any ideas about how to drum 
> up more interest in contributing to the code base?

Hmmm... how about some simple "Hello World" -type tutorials and some
docs for both installation (source and binary) AND programming.
Try to appeal to the windows/MSFS "gauge programmer" type of people.

The docs should include how to get the sources and dependencies and
build tools, how to compile, how to add something "custom" like a 
"Hello World" gauge and how to set the thing up to talk to the sim.

Get those MSFS junkies to actually do something more than just work
within the confines of MSFS (and its hacks)

Also put up a short explanation of the (future) license so they know
what they and others can do and what they can't.

Most of the "freeware" for MSFS is very "unfree" in GPL/BSD sense.

> This is what I spent over an hour talking to Enrico about at the Avsim 
> conference. He doesn't agree that PM will always dominate the market, 
> and has in fact expressed frustration that he's a bit overwhelmed by 
> requests for new features. He would like "competition", if only to 
> relieve some of the development pressure.

Interesting. 

> This is what I spent a bunch of time talking to Austin about. He has 
> similar relationships with several companies that use X-Plane in their 
> businesses; they pay him to add features with the understanding that 
> whatever is created gets rolled back into the main release of X-Plane.
 
> I think this is a _very_ good model under which to operate. I have 

Yes. I try to work that way if possible. I think its is the BEST way to
develop software.

> worked in close cooperation with a company called Kitware at work, and 
> one of their main products (VTK) is released under a similar model. If 
> you're curious, the copyright under which they release their code can 
> be found at:
> 
> http://www.kitware.com/Copyright.htm
> 
> The difference I see here is that without the ability to "hold back" 

Holding back certain parts wouldn't be too much of a problem as long as
it is "special" stuff that wouldn't make much use to other people.
If "open source" is the "preferred" method (and maybe a little cheaper
than if not open sourced), that seems to be a good approach in my eyes.

> some features, in the case where _I_ am the company doing the homebuilt 
> aircraft development, there is really no way to fund the development of 
> gauges that require a cash investment. In other words, I'd be perfectly 
> happy if the following were true:
> 
> 1) OpenGC still exists as open source
> 2) Anyone can contribute code to the open source version
> 3) I'm allowed to develop closed source add-ons that make OpenGC viable 
> in the homebuilt aircraft market.
> 
> This requires something along the lines of a BSD/LGPL license. As long 
> as everyone can agree to switch to that, I'm perfectly happy. My ONLY 
> interest is being able to pursue an interesting new avenue of 
> development that I don't think is possible operating purely under the 
> GPL. I have absolutely zero interest in stopping development of OpenGC 

True. The GPL wasn't made for that. Some projects are using an amended
version of the LGPL, eg. the WxWindows toolkit (www.wxwindows.org)
This amendment has to do with linking... 
You might wanna take a look at it.


Regards,
Manuel

Re: [Opengc-devel] status/Avsim conference update/RFC

[Damion S. <be...@cs...>]

Thanks for the feedback!

> I think, the "multi sim/platform support" should remain the primary
> "selling point" for OpenGC. ("Selling point" not meant literally here)

Agreed. We're still unique in that respect.

> Have you considered 'modularizing' OpenGC (not necessarily on the 
> binary
> level, eg. shared objects/dlls/plugins, maybe on the source level...)

<snip>

> That way, every user/developer of OpenGC could profit from those
> changes. I think such a development model is much more viable than
> having a(nother) closed source Glass Cockpit Software.

Ok. Do you think it would be possible to reach an agreement to 
relicense the "base code" portion of OpenGC under the LGPL or BSD?

> My ideas go along the lines of how Mozilla/Netscape or
> OpenOffice/StarOffice are orginized and developed.
> Both have a free version and also a commerical version with a few more
> things added to it that could not go into the free/opensource version.

There are a few technical issues (handling multiple GUI interfaces for 
example) that would have to be addressed, but they're probably not 
insurmountable.

> For me the most important about OpenGC is the fact its free software 
> and
> the code is open source.

Well, that's what I had hoped for as well. Any ideas about how to drum 
up more interest in contributing to the code base?

> I don't believe that there is a big market for this. Most of it is
> already taken by PM.

This is what I spent over an hour talking to Enrico about at the Avsim 
conference. He doesn't agree that PM will always dominate the market, 
and has in fact expressed frustration that he's a bit overwhelmed by 
requests for new features. He would like "competition", if only to 
relieve some of the development pressure.

> Why not set up a model (eg on "contractual basis") that all gauges that
> are developed (even for money) to be made free/opensource after its
> finished. What I mean is: some company wants a gauge for eg. their
> homebuilt aircraft systems. They pay you to write it. When its 
> finished,
> they load OpenGC and the gauge they paid for onto their hardware. They
> sell this hardware with OpenGC and that gauge in it to their homebuilt
> customers. You put that code into CVS. They got what they wanted. 
> OpenGC
> has another gauge. You earned some money.

This is what I spent a bunch of time talking to Austin about. He has 
similar relationships with several companies that use X-Plane in their 
businesses; they pay him to add features with the understanding that 
whatever is created gets rolled back into the main release of X-Plane.

I think this is a _very_ good model under which to operate. I have 
worked in close cooperation with a company called Kitware at work, and 
one of their main products (VTK) is released under a similar model. If 
you're curious, the copyright under which they release their code can 
be found at:

http://www.kitware.com/Copyright.htm

The difference I see here is that without the ability to "hold back" 
some features, in the case where _I_ am the company doing the homebuilt 
aircraft development, there is really no way to fund the development of 
gauges that require a cash investment. In other words, I'd be perfectly 
happy if the following were true:

1) OpenGC still exists as open source
2) Anyone can contribute code to the open source version
3) I'm allowed to develop closed source add-ons that make OpenGC viable 
in the homebuilt aircraft market.

This requires something along the lines of a BSD/LGPL license. As long 
as everyone can agree to switch to that, I'm perfectly happy. My ONLY 
interest is being able to pursue an interesting new avenue of 
development that I don't think is possible operating purely under the 
GPL. I have absolutely zero interest in stopping development of OpenGC 
if there's a way to keep it open source yet still pursue commercial 
goals.

Thoughts? Opinions? John - since you're the other major developer in 
the history of OpenGC, what do you think about this?

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I hope that after I die, people will say of me: "That guy sure owed me 
a lot of money."

Re: [Opengc-devel] status/Avsim conference update/RFC

[Manuel B. <li...@va...>]

Hi Damion,

just a couple of thoughts from me...

On Sat, Sep 27, 2003 at 11:25:04PM -0400, Damion Shelton wrote:
> 1) People are impressed with its multi-platform, multi-sim capabilities.
> 2) The open-source nature of the project is not, in and of itself, a 
> selling point of the project (keeping in mind that this is largely a 
> FS200x, and to some extent X-Plane, oriented crowd).
> 
> I have personally believed that the main thing that differentiates 
> OpenGC from Project Magenta (and indeed other cockpit efforts) is it's 
> multi sim/platform support. While I do not wish to make product 

I think, the "multi sim/platform support" should remain the primary
"selling point" for OpenGC. ("Selling point" not meant literally here)


> 1) Closed source development creates a viable business model that would 
> allow development of gauges for which there is a non-trivial 
> development & distribution cost. For instance, gauges based around 
> commercial terrain and map databases (for which there are no freeware 
> alternatives).



> 2) The homebuilt aircraft/EGyro component of OpenGC developed this 
> summer will need to be accompanied by physical hardware development, 
> which will require purchase of hardware in the multi thousands of 
> dollars range. I am unable to float the cost of this myself with no 
> expectation of return (for obvious reasons), which would essentially 
> block development of what I think is a potentially very valuable 
> addition to general aviation.

Have you considered 'modularizing' OpenGC (not necessarily on the binary
level, eg. shared objects/dlls/plugins, maybe on the source level...)

Why not leave the core of OpenGC with all the current Gauges under GPL
and continue to use this as the basis for free and commerical
distributions, while creating the possibility for commercial gauges to
just "drop" in their source in a subdir before building.

The resulting binary would be a payware program (which could be done
totatlly independent from OpenGC by a company who wants to use it that
way with their own special gauges)

As far as I undestand, this would mean the core needs to be
relicensed/dual licensed under LGPL.
If such a company wanted a change in the OpenGC core, it could add code
to the opensource CVS core OpenGC (that piece of code haveing the same license
as the core)

That way, every user/developer of OpenGC could profit from those
changes. I think such a development model is much more viable than
having a(nother) closed source Glass Cockpit Software.

My ideas go along the lines of how Mozilla/Netscape or
OpenOffice/StarOffice are orginized and developed.
Both have a free version and also a commerical version with a few more
things added to it that could not go into the free/opensource version.


For me the most important about OpenGC is the fact its free software and
the code is open source.


What do you think ?

> This leaves the following as potential targets for full 
> commercialization:
> 
> 1) Development of more polished gauges, more in line with the Project 
> Magenta work, and any gauges which require data unavailable in free 
> format.

I don't believe that there is a big market for this. Most of it is
already taken by PM. 

> 2) The homebuilt aircraft market.
> 
> 3) Custom gauge development, either on a contractual basis or by 
> licensing a copy of the OpenGC source for commercial development.

Why not set up a model (eg on "contractual basis") that all gauges that
are developed (even for money) to be made free/opensource after its
finished. What I mean is: some company wants a gauge for eg. their
homebuilt aircraft systems. They pay you to write it. When its finished,
they load OpenGC and the gauge they paid for onto their hardware. They
sell this hardware with OpenGC and that gauge in it to their homebuilt
customers. You put that code into CVS. They got what they wanted. OpenGC
has another gauge. You earned some money. 

 
Just some ideas... :-)

Regards,
Manuel

Re: [Opengc-devel] status/Avsim conference update/RFC

[Damion S. <be...@cs...>]

Hi,

> Like you, I have been both disappointed and puzzled by the singular 
> lack of
> support and interest within the sim community (hardware and software) 
> for
> projects like OpenGC. Yet there are any number of websites about 
> projects
> and individuals building flightdecks, selling software, and offering 
> all
> forms of products and services.

My impression, after talking to the folks at Avsim (who I would say are 
among the most fanatic members of the simming world) is that their 
hobby is flying, or perhaps to a smaller degree, constructing home 
cockpits, and not writing code. I think this is similar to the case of 
image editing; a lot of people will edit photos as a hobby, very few 
are interested in writing Gimp-like tools to do so. Moreover, the fact 
that people are interested in paying money to let other people do so is 
(IMHO) merely an indication that they're willing to pay for a 
professional quality product.

> Over the course of the past year I been focused on expanding the FG and
> OpenGC interaction and network design. The result is that my system has
> evolved into a highly customized simulation with FlightGear and OpenGC.

Ok, but this has not been contributed back to OpenGC as a whole. You 
attribute this to (from a recent email):

"since Damion went off on a different direction with the OpenGC project 
it's become incompatible and I just don't have the time, talent or 
resources to set up a website and CVS server or try to sync up with 
X-Plane or FSxxx."

If the only reason the project is useful to you is as the starting 
point for a private development branch (with the split occurring a year 
back), I don't know if that's a particularly convincing argument to 
continue development of the public version of the code. While there is 
nothing in the GPL that prohibits private development, it does little 
to improve the project as a whole.

> Throw in recent hardware designs ( and software drivers ) that provide 
> for
> throttle/control input, momentary and static switches, rotary encoders,
> light and LED displays, etc and one has pretty much all the technical 
> means
> to build a world class simulator. Just a question of high deep are your
> pockets for cockpit hardware and visual systems and how much time to 
> devote
> to construction.

Agreed - I think this is the view that the cockpit crowd is taking. In 
terms of the price to pay for a polished software product (which I 
think we can all agree OpenGC is not), it's really quite minimal 
compared to, for example, a single flat panel screen for an interior 
display.

> I am still troubled by your claim regards the source and copyright. 
> The code
> was moved from SourceForge so there is a question of continuity and 
> again I
> don't think CVS logs (which can be altered and edited) are sufficient 
> proof.

<sigh> If anyone wants to accuse me altering CVS logs in a 
conspiratorial grab for power... well, I consider myself an honest 
person and you're right, there really isn't any indisputable proof I 
can provide that would convince someone beyond a shadow of a doubt that 
I'm not lying.

> I can recall making and committing changes to all segments of the 
> OpenGC
> code from the make files to basic modules such as ogcAppObject,
> ogcRenderWindow, and ogcDataSources.So again, I would challenge your 
> claim
> of copyright and lay claim to those portions and modifications within 
> the
> larger document(s).

Fair enough. Look, if this is a serious issue (and it apparently is) it 
would be a fairly minimal amount of work to start completely from 
scratch. Although, my ability to convince people that I have started 
from scratch is a different question...

> Again, if you wonder why there is a lack of interest, perhaps this is 
> a good
> reason.

Is the suggestion that the lack of interest is due to my "claim of 
ownership" on OpenGC? The first time I've ever expressed a commercial 
interest in glass cockpit software was three days ago, and that was 
largely BECAUSE of the apparent lack of interest in contributing code 
to the project. It has never been suggested to me by anyone that I'm 
maintaining an inappropriate level of control over the project.

As a question to everyone, my main goal at this point is the following: 
I have a personal interest in starting a small company to develop glass 
cockpit hardware and software for homebuilt aircraft. OpenGC was shown 
at the EAA airshow in Oshkosh and, though it was quite popular, there 
was zero interest in the open source aspect of the project. None. 
Pilots want a complete drop-in solution and that's it.

To provide this: terrain databases (the good ones) cost money. Highway 
map databases cost money. Hardware costs money.

If someone can suggest a model whereby the open source and private 
development aspects of OpenGC can coexist, I'm all ears. One option 
would be moving the license to something like BSD or LGPL, although my 
guess would be that that would not be a particularly popular move 
either. My problem is not with having the bulk of the code of OpenGC in 
the open source arena; if I were that paranoid, I would not have GPL'd 
it in the first place.

Things get complicated in trying to figure out a way of releasing a 
"value added" version of OpenGC as payware. Apple has done this fairly 
successfully by releasing the Darwin core of OSX as open source and 
close sourcing their desktop. If something similar could be done with 
OpenGC, great!

Any suggestions?

-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I hope that after I die, people will say of me: "That guy sure owed me 
a lot of money."