I'm reposting a response I received some
time back from Jon Hall about this subject.
Jon's response follows Scott Manley's and
Jim Paradis' notes here:
Scott Manley wrote:
> OK assuming this doesn't break the terms of the license, how would I do it, I
> can create binarys on our OSF boxes which will run on my linux machine by
> using the -non_shared compiler flag. But as soon as I try to link something to
> the maths library it'll fail with undefined functoins. Is there some simple
> flag I'm missing?
> > --
> > To unsubscribe: send e-mail to firstname.lastname@example.org with
> > 'unsubscribe' as the subject. Do not send it to email@example.com
> > One possibility, if you have *access* to a Digital UNIX system and you're
> > writing your own code is to build your program statically-linked on a
> > Digital UNIX system, then run it on your Linux/Alpha system. This gets
> > you the performance of the Digital UNIX math libraries while adhering
> > to the terms of the Digital UNIX license.
> > --
> > Jim Paradis (firstname.lastname@example.org) "It's not procrastination,
> > Digital Equipment Corporation it's my new Just-In-Time
Here is my question and response from Jon Hall:
> Then to be perfectly clear, a package like Gaussian 94, STATICALLY
> compiled on a licensed DEC Unix machine with the licensed optimized
> DXML (BLAS) library can be run on a LINUX alpha with no DEC license?
[Jon Hall replied:]
To be perfectly clear, with the issue stated as above, the answer is
There is a difference between compilation and linking. The binaries
which are created by taking the source code of a program and compiling
a Digital UNIX system using a Digital compiler bear no royalty or
issues. However when you link them (either statically or dynamically)
licensed libraries from a Digital UNIX system and the thread of
of a CPU that is *not* licensed runs through them, then you are in
of your license which you signed to get the code in the first place.
Therefore, if you compile a program (but do not link it) on Digital UNIX
a Digital Compiler, and take the resultant objects to a Linux system,
against Linux libraries and run it, you are o.k. If you link in (either
statically or dynamically, either locally or over NFS) any Digital
(i.e. royalty bearing code) which are licensed, you are not o.k.
>Wouldn't you need a DEC Fortran runtime license of some kind?
This depends on the license Terms and Conditions of the Fortran license
I am not familiar with) but in any case it would only cover the code
with the Fortran Runtime Libraries, which (in turn) typically use the
underlying operating system libraries (which are royalty bearing).
In the days when most Runtime licensing was conceived, there were two
o sell the compiler cheap, and make it up in runtime licenses
o sell the compiler high, and give the runtime licenses away
Digital tended toward the latter, but gave little thought to having an
unlicensed binary compatible platform running the bulk of the OS.
the relationship between the "runtime libraries" and the "system
libraries" were not spelled out, since it was assumed that the licensed
system libraries would always be there on a licensed system.
Over time there was a third school of thought, which was to price the
compiler based on "simultaneous usage", or even "personal usage". This
allowed the cost of the compiler to drop for infrequent or personal use.
Perhaps it is time for a fourth school of thought, that of showing
how to substitute the underlying libraries of an unlicensed operating
in a run-time environment.
Of course there was also a fifth way of thought (that of GNU), but
Digital did not tend in that direction.
>Would I also need more than one user license if
>I intended to have several simultaneous users?
Again, the license typically only applies to the number of users of the
COMPILER (i.e. we priced the individual simultaneous users and the
user license low on a per-use basis). The number of people using the
of the compiler (i.e. your compiled program) is typically not metered,
you should check the licensing of the run time libraries).
>Also, is there an OS dependence built in to the
>DEC optimized BLAS that would effect its
>performance on a LINUX machine?
There could be. Issues around mallocs, context switching, use of
memory, file opening/closing. I am not familiar enough with the
to see how they use the underlying operating system features to say if
result would be positive, negative or neutral.
>DEC has done an outstanding job of optimizing
>the Matrix routines. For matrix intense calculations
>this can make a huge difference. You wouldn't want
>to buy a 433 MHz Alpha board and not run an optimized
>matrix multiply routine in Gaussian 94, would you?
I take this as a compliment, and representing Digital,
I thank you.
>Would these optimizations be effective
>enough running on an OEM Alpha board to justify the
>expense and time involved in obtaining all of these DEC
Even though your question is still unanswered, you
have formulated the parameters to obtain an answer.
>The question here is how would you determine what
>"class" of licenses to buy? DEC Direct sent me
>to 1-800-axp4vme and they sent me to Dan Kilgore.
>I'm waiting for Dan to call me back.
I will give Dan a call. Perhaps working together
we can clear up some of these issues.
-- ============================================================================= Jon "maddog" Hall Internet: email@example.com Senior Leader, UNIX Software Group Executive Director, Linux International
-- from Bob Williams, mailto:firstname.lastname@example.org
-- To unsubscribe: send e-mail to email@example.com with 'unsubscribe' as the subject. Do not send it to firstname.lastname@example.org
Copyright © 1995-1997 Red Hat Software. Legal notices