Packaging status

Goal
A key first step of the open proofs project is to package key FLOSS formal methods / high assurance tools for easy installation. There are many promising tools, but if they're hard to install they are unlikely to be used.

Obviously, easy installation is not enough. Tools must be also be easy to learn and use for real problems - which implies a need for documentation and tool refinement. And since there are many tools, documents that help you choose between them (and use them together) are important too. But the first step is to make them easy to install.

The initial goal is to package promising tools so they can easily be installed on various systems. We have started by focusing on Fedora Linux (RPM-based), which is one of the most popular FLOSS systems in the U.S. and has lots of security measures (so it's widely used already by people who care about security). We've focused on ensuring that users can simply select the tools using their normal GUI package installer, without traversing multiple websites to download software. In all cases, this requires requires creating packaging, and/or sending bug reports so that they are integrated together.

We're also looking at Debian and Ubuntu (both deb-based), as you can see below. Again, the intent is to get FLOSS formal methods / high assurance tools into their standard repositories, so that users can easily install these tools. This is not to exclude other systems; the more the merrier. SuSE/Novell, Gentoo, and FreeBSD are especially of interest. It'd be nice to do this for Windows and MacOS too, but many of the tools are not designed to work with these operating systems, so it would likely be a lot more work to port them, and there's also no centralized repository to submit them to.

Please help us!!
Please look at the list of packages below, and see what's not already packaged. Let us know which one you're doing (by updating this page). Then, create a package for it! You normally don't need to be an expert in the program you're packaging; creating a package primarily involves knowing how to create a package file. Read its installation documentation, and go! When done, submit it to the project's repository; repeat til done.

LICENSES MATTER. Repositories for many FLOSS distributions will not accept non-FLOSS licenses, and it may not be legal to redistribute some programs. Nonstandard licenses often make it impossible to combine tools to create larger useful works, which defeats the purpose of this site. In addition, they can take a very long time to go through legal review, and may be rejected for a variety of reasons. So if you can, encourage the tool-makers to use standard FLOSS licenses instead of odd ones. Often lawyers add clauses because "it's fun to write contracts"; they often do not understand the ramifications of the text, and unless a license has been widely vetted through public examination and use, it's probably a terrible idea. (see http://www.dwheeler.com/essays/gpl-compatible.html)

Tool creators should try to limit themselves to these licenses: MIT, BSD-new, LGPL, and GPL; they are widely-used and known to be GPL-compatible (the GPL is the most popular FLOSS license). The Apache 2.0 license isn't so bad, but note that it's incompatible with GPL version 2 (though it is compatible with GPL version 3). At the very least, please use a license already approved by the OSI, the FSF, Fedora, and Ubuntu.

Promising FLOSS tools supporting open proofs
Below is a list of FLOSS tools that look especially promising, and who is packaging them. For more about these projects, as well as information about other tools, see: http://www.dwheeler.com/essays/high-assurance-floss.html In the table below:
 * "IN": Was already in the given repository before openproofs.org work begin
 * "DONE": It is now in that repository, due to our efforts.
 * "DONE BY OTHERS": Now in the repository, by those unconnected to openproofs.org
 * "Name": Name is currently packaging it.
 * "-": no one has checked if it is in their repository. For Ubuntu and Debian, please help us determine which ones are already in the distributions and which are not.
 * "?": It's not in that repository, and no one is working on it.

Please pick anything with "?" and package it!! Let us know by modifying this table. Note: "In repository" for our purposes may mean that it's ready for the next release; it might not be in the current release.

Many of these programs depend on implementation languages with multiple implementations like ML and Common Lisp - packagers will need to compare implementation possibilities. For example, many of the HOL variations (HOL 4, HOL Light, Isabelle) need an ML implementation, and preferably one that can store its state. Poly/ML is already packaged for Fedora, and can do this, but it'd be good to compare the various ML implementations.

Other potential FLOSS tools supporting open proofs
Here are some "maybes" that would be great to package as well:
 * veriT/haRVey: We've had extensive discussions with the developers of what was originally named harRVey, and is now named veriT. Originally, haRVey-FOL and haRVey-SAT were separate programs, but their developers merged them.  This merged result should be examined, but if it's as useful as appears likely, it should be packaged. "Why" can use the older version of haRVey; the Why developers intend to add support for veriT soon.  That could be great, as it would add another automated FLOSS prover to "Why".  veriT requires a few other packages, e.g., E and miniSAT 1.
 * Gappa: Automated prover for proving constraints on floating point numbers. Invokable from why. Very useful for programs with floating point arithmetic.
 * Sugar - Constraint solver
 * Saturn - statically and automatically verify properties of multi-million line software systems
 * ProofPower - HOL variant and standard Z support.
 * Daikon: ?  - Invariant-finder. Not really a formal methods tool _directly_, but     a way to help use of formal methods tools
 * JMLEclipse: ?  - Front-end for JML
 * JACK, Java Applet Correctness Kit (Cecill C licence): ?
 * Decision Procedure Toolkit on SourceForge
 * APRON (LGPL and GPL) - for static analysis of the numerical variables of a program by Abstract Interpretation
 * MOPS, which can do model-checking of a big system. Model Checking An Entire Linux Distribution for Security Violations discusses MOPS' use on the Linux kernel.  Compare this with BLAST - do we want to package both?  BLAST and MOPS are similar, but compared to BLAST, "MOPS trades precision for scalability and efficiency by considering only control flow and ignoring most data flow, as we conjecture that many security properties can be verified without data flow analysis".
 * Forge/JForge: ?
 * SNARK: ?
 * CSIsat - Submitted to Fedora, awaiting review. Needed for BLAST.
 * picoSAT - In Fedora. Needed for CSIsat.
 * iProver: ?
 * Darwin: ? - http://combination.cs.uiowa.edu/Darwin/
 * Paradox / Equinox: ? - http://www.cs.chalmers.se/~koen/folkung/  - promising prototype; Equinox is an automated theorem prover for pure first-order logic with equality, built on SAT (miniSAT)
 * Gandalf (Not the image processing system) - this is another promising automated theorem prover. However, we already have several generic automated provers (prover9, E), and for theory-specific ones, CVC3 covers a far broader array of theories, and alt-ergo works well too.  In addition, although Gandalf did well in years past, there's little evidence of continuing development.   Originally Gandalf was on the list to be packaged first, but now that CVC3 is available, it has been removed from the top priority list.  It'd be nice to package, though.
 * Murphi: ? - Lots of branches/variants, hard to track down what to _USE_
 * Deputy: ?  - C variant, not really a FM tool
 * CCured: ?  - C variant, not really a FM tool
 * Cyclone: ?  - C variant, not really a FM tool
 * CPAchecker - Described by its author, the BLAST maintainer, as "a better BLAST".

This is not meant to be an exclusive list. There are many different tools, many focused on different capabilities, and it's hard at this point to identify "winners". Feel free to package something not on this list, and let us know! At this point, it's best to package the more promising ones, and through use the best ones will fall out. But if you can show that some are much more promising than others, please let us know - it'd better to not package clearly inferior products, so that people can simply use the best ones. Many of these were selected by examining the results of the various competitions, such as Conference on Automated Deduction (CADE) Automated Theorem Prover (ATP) System Competition (CASC), and selecting the OSS tools that were the best in at least one category.

For lists of tools, see Free software tools for formal verification of computer program and High Assurance (for Security or Safety) and Free-Libre / Open Source Software (FLOSS)... with Lots on Formal Methods.

For discussion comparing some of these tools and their notations, see The Seventeen Provers of the World.

Uncertain/unreviewed licenses
The following are very unclear:
 * Jahob is a Java proving tool with many sub-components. It's not clear what the conditions of the various pieces are, and if a useful set can be released as OSS.  CVC3 is now open source software, so that issue has gone away.  Here's a paper about using Jahob to prove properties of programs with pointers

There are other tools that might be of interest; their legal status needs to be reviewed, as well as whether they're worth packaging:
 * NIPS VM
 * MCESS - Model Checking For Embedded Systems Software
 * Tapir

Not Free/Libre/Open Source Software (FLOSS)
The following are not FLOSS tools, even though some are widely misunderstood as being FLOSS:
 * Spin claims on its front page that it is an "open-source software tool", but this claim does not appear to be true (in the sense that the term "open source" is normally understood). Spin is released under the Spin license.  This license has not been certified as being an open source software license by the OSI, nor as Free Software license by the FSF; these are usual the sources for the definitions of "open source software" (aka "free/libre software"), including those used by the U.S. federal government and the state of California.  Fedora has examined it and determined that it is not a FLOSS license.  Debian's preliminary examination of the Spin license seemed to come to the same conclusion (it's poorly worded, making it difficult to determine what is legal to do).  Thankfully, the data format accepted by Spin (ProMela) can be accepted by other tools too, so users can switch to another tool.
 * zchaff is not FLOSS (it is released for "non-commercial use only"). zchaff is nowhere near as good as MiniSAT, anyway.
 * "Simplify" (part of ESC/Java) is not FLOSS. It has been abandoned, and its license is in legal limbo.
 * YiCES is NOT FLOSS. Its publisher does publish other FLOSS tools (e.g., PVS), but YiCES is not one of them.
 * Modex is released under a "non-commercial use only" and "no redistribution" license.

Here's a table of promising tools with license issues, though they may be worked out:

You also need to be careful of dependencies. Some repositories (e.g., Fedora's main repository) require that both the program, and anything it requires, be FLOSS.

How to Create packages
There were many different places to learn how to package for Fedora, and that made it hard to learn. For creating Fedora packages, see the CreatingPackageHowTo page at the Fedora wiki. Much of this information is relevant for other RPM-based distributions, such as Novell/SuSE.

For deb-based Linux distributions, such as Debian and Ubuntu, see the Debian New Maintainers' Guide and Ubuntu packaging guide for more information.

Please make sure you can start the program exclusively using a GUI, even if it's a text-only program. For Linux/Unix systems, please use the desktop entry specification and perhaps the icon theme specification from FreeDesktop.org.

Unfortunately, many of these programs don't follow standards, such as the Filesystem Hierarchy Standard, so you may need to modify them so they can integrate smoothly with other programs.

Comparing tools
There are a number of different tools, but no comprehensive document explaining their pros and cons. There are some useful documents, such as A comparison of PVS and Isabelle/HOL.

Potential Packagers
Here are people who have expressed that they might be interested in doing this. Please let me know of something specific you'd like to do!


 * Tim Colles &lt;timc at inf.ed.ac.uk&gt;
 * Jerry James jjames Jamezone
 * Jeremy Long &lt;Jeremy.Long at gmail.com&gt;
 * Earl Sammons &lt;esammons at hush.com&gt;
 * Justin Acquaro &lt;jacquaro at gmail.com&gt;.
 * Greg KH (for Gentoo, maybe SuSE) &lt;greg at kroah.com&gt;
 * Jesus Arocho &lt;jesus_arocho at comcast.net&gt;
 * Ed Schneider
 * Jonathan Marsden - interested in packaging SPARK for Debian/Ubuntu

Anyone in the Fedora Formal Methods SIG (Special Interest Group) is a potential packager.