[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

How do we interpret the Stalin license?



I'm thinking of packaging Stalin for Debian, but it's got an unusual
license.  I wanted to see what our take is on this, and if we can't
comply, see if we have someone more experienced in getting these
things changed who'd be willing to contact the author.  (Does he
really want an email after every Debian package installation?  I
should put that in the postinst, and see how long it takes before he
changes that part of the policy :>)

First, a brief description: It's a really interesting batch mode
Scheme->C compiler (with some restrictions on the dialect) that has
been shown to generate extremely efficient code, including numeric
code that rivals Fortran.  It does really sophisticated analyses at
compile time to eliminate garbage collection and dynamic allocation
where possible, and to do global static type analysis which allows it
to eliminate many if not all run time checks without requiring type
declarations.  Furthermore, it maps Scheme types to C types on a per
expression basis which means it can emit extremely efficient numeric
code.  (The full blurb about it's features is included after the
license, for those interested).

Here's the license:

          CONDITIONS

  The current release of Stalin is provided for free on an as-is basis
  with no warrantee.  You are free to use, copy, and distribute this
  software provided that:

   1. You report *ALL* bugs to Bug-Stalin@AI.MIT.EDU whether or not you
      need them fixed.  Include the version number (0.7) in the message.
   2. You report *ALL* bugs that you fixed to Bug-Stalin@AI.MIT.EDU.
      Include the version number (0.7) in the message.
   3. You inform me that you obtained a copy of Stalin by sending a message
      to Info-Stalin-Request@AI.MIT.EDU to be put on the
      Info-Stalin@AI.MIT.EDU mailing list.

I'm particularly concerned about the "current release" bit, and the
insistence on the email.  While we certainly will report all the bugs
upstream, I'm not sure what to make of (3).


Here's the official blurb for those who care...

Stalin incorporates numerous strategies for generating efficient code.
Among them, Stalin does global static type analysis using a soft type
system that supports recursive union types.  Stalin can determine a
narrow or even monomorphic type for each source code expression in
arbitrary Scheme programs with no type declarations.  This allows
Stalin to reduce, or often eliminate, run-time type checking and
dispatching.  Stalin also does low-level representation selection on a
per-expression basis.  This allows the use of unboxed base machine
data representations for all monomorphic types resulting in extremely
high-performance numeric code.  Stalin also does global static
life-time analysis for all allocated data.  This allows much temporary
allocated storage to be reclaimed without garbage collection.
Finally, Stalin has very efficient strategies for compiling closures.
Together, these compilation techniques synergistically yield efficient
object code.  Furthermore, the executable images created by Stalin do
not contain (user-defined or library) procedures that aren't called,
variables and parameters that aren't used, and expressions that cannot
be reached.  This encourages a programming style whereby one creates
and uses very general library procedures without fear that executable
images will suffer from code bloat.

-- 
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: