[Coin-discuss] Open Source Modeling Language System

[Brady Hunsaker]

On Thu, 2004-07-01 at 12:17, Tom Browder wrote:
> I've started on a parser/translator for the GAMS language and wonder if
> anyone could comment on the legality of reverse engineering the system from
> reference to the GAMS Users Manual.
> 
> If anyone thinks there is a problem I surely will consider stopping.  I know
> the manual is copyrighted, but current documentation is freely available on
> the GAMS web site.
> 
> Tom Browder
> 

I do not know for sure and I'm not a lawyer.  I'm only speaking for
myself and not on behalf of COIN-OR.  

My understanding is that no one can copyright or patent a language. 
That's why there are many compilers for computer languages.  No one
"owns" C or C++ or Java.  It's also not what I would consider "reverse
engineering":  you aren't trying to figure out how GAMS software works;
you're just writing a parser based on the description of the language. 
You don't care how their copyrighted software works and you don't need
it to write your parser.

The modeling language in GLPK, GNU MathProg, is really a subset of
AMPL.  It appears that Zimpl may also be based on AMPL, but I'm not sure
since I only briefly looked over Zimpl after seeing it mentioned on a
recent post.  I point these out as examples where similar efforts have
been made.  Of course, whether or not something is legal is not the only
factor in whether a company will attempt to stop you from doing it.

A disadvantage to writing a parser for a known language is that you're
always playing catch-up.  If your goal is to provide similar
capabilities as GAMS for future models, another possibility is to take
one of the existing open-source efforts mentioned on the list and extend
them in the directions you'd like.  Or you could start from scratch to
make an even better modeling system, though that's a bigger task.

If your goal is to provide a method to use existing GAMS models, then a
parser will be needed in any case, so your current effort makes sense. 
As you write, I would keep in mind the distinction between the parser
that interprets the GAMS files and the "engine" (or whatever) that acts
on these instructions.  Others may be interested in the parser but not
the engine.  One approach is for the parser to read the file and provide
an API that gives information about it.  This is the approach taken by
GLPK in writing an AMPL parser.  I'm not too familiar with GAMS so I
don't know whether this model would work perfectly or not.

Brady

-- 
Brady Hunsaker
Assistant Professor
Industrial Engineering
University of Pittsburgh
http://www.engr.pitt.edu/hunsaker/