At work, we’re in the process of open-sourcing CPN Tools. While many open-source fanatics will tell you it’s just about releasing the source, anybody who has actually tried doing so, knows it’s not that easy. Normally, you need to sanitize the code (make sure it contains no secrets/too embarrassing stuff), write some documentation on how to build it (as that often involves a secret spell and some magic only known by the elders), find a license, and a means of distributing the code.
In this case, we have the same problems, and a bunch of extra problems. Here, I’ll go thru some of the considerations we did before open-sourcing the code. Also, for easy reference, the location of the code is (not all code may be uploaded at the time of posting, but will within a week or two):
- https://gitlab.westergaard.eu/cpn-tools/gui/tree/master
- The CPN Tools GUI code.
- https://svn.win.tue.nl/repos/cpntools/Simulator/trunk/
- The CPN simulator component.
- https://svn.win.tue.nl/repos/cpntools/AccessCPN/trunk/
- The Access/CPN library for communicating the with CPN simulator from JAva without the CPN Tools GUI.
Bonus Problems when Open-sourcing CPN Tools
CPN Tools is a tad more difficult to open-source than your average piece of software.
First, it is written in an arcane academic language, you’ve probably never heard of (it’s called Beta and is developed by Mjølner Informatics and Aarhus University). The language is no longer supported and hasn’t really been for 5-8 years. Only very few people are able to code in the language (which has a syntax radically different from the C-like languages and uses some concepts not many are familiar with). Also, the compiler is not really available anymore (and never really was for free), and the custom version of the compiler we use for CPN Tools most definitely isn’t. As another nail in the coffin, the language has some limitations stemming from its old age and academic nature, which we are constantly hitting with CPN Tools. This means you have to code certain parts in a very particular way and that we cannot use the (also badly aging) IDE and debugger for development.
Aside from using a customized version of an obscure language, a second issue is that we also use a highly customized version of another almost as obscure language, namely SML. CPN Tools needs access to internals of the compiler, and we also require some new hooks in the runtime system. For this reason, we need a very specific setup just to compile the tools; namely with two custom, difficult-to-get compilers and additionally an old obscure version of a linker shipping with Microsoft Visual Studio 6 (it may work with other versions, but this is the only version we know to work). Luckily, a year ago or so, I did write a guide on how to set up a build environment. This has to be customized as it refers to things not generally available, but at least it is not going to be several days of effort.
Third, CPN Tools has primarily been developed by student programmers. Some programmers stayed for several years on the project, but some only for one year. During this one year, they had to get acquainted with Beta and the idioms for programming in a new language with a new standard library and to understand (at least part of) the large existing code base (73k lines of Beta code, 30k lines of supporting custom Beta libraries, 57k lines of SML code, and optionally 13k lines of other SML code). This means that they did not have a lot of experience, and the standard of parts of the code clearly reflects that. As there are no modern refactoring tools for neither Beta nor SML, there i no chance I am going thru 173k ((Assuming I am still able to do math.)) lines of code to refactor it, so the released code is going to be a bit messy with misunderstood design-patterns, anti-patterns and all kinds of stuff from software development hell.
Fourth, CPN Tools consists of several components that we wish to release separately. Basically, it consists of a GUI, a state-space tool, a bunch of supporting libraries, another state-space tool, a simulator component, and a library for interaction with the simulator component. These components have different usage scenarios and we want the components and licensing to reflect that. Basically, the GUI, which is written in Beta, is not expected to be usable aside from making minor modifications. This is because this is by far the worst of the code and additionally written in a language more obscure than volapük. We therefore decided on a GPL license, allowing everybody to use the code as long as changes are shared. Included in the GUI is one state space tool and supporting libraries written in SML. The simulator component is SML code of higher standard. It is useful for building another future GUI or integrating CPN simulation into a preexisting GUI, and for integrating CPN simulation into another program. This is also where the by far most clever code exists. For this reason, we have licensed this under two licenses: GPL and 4-clause BSD. This means that if you open-source your changes and your entire program, you may do so. If you do not wish to publish your changes, you have to give us credit. The simulator includes the other state-space tool, which is developed in the context of the ASCoVeCo project. Finally, the library for interacting with the simulator, called Access/CPN, is useful as it provides the basis for interacting with the simulator unless you want to write everything yourself. I’m considering either a dual-license as for the simulator or LGPL, which would allow you to use the library without publishing the source to your code, but you must publish changes to Access/CPN.
Finally, CPN Tools was recently transferred from Aarhus University to Eindhoven University of Technology. This means that in addition to regular code sanitation, I also had to go thru most of the source and replace old copyrights with new ones. Furthermore, I’m fairly sure that the released source will contain a bunch of old references to computers that have been decommissioned for years, but I’ve been thru the GUI component changing copyrights and applying licenses.
tl;dr: CPN Tools is going open source, but there is a lot of work to do, and as it doesn’t really do much difference for me (as I have the source), this is going slowly. But we’re getting there, and the GUI is available now, if you want to look at butt-ugly Beta code.
Also, if you intend to use the code for anything, I’d be happy to hear about it. You can put it in the comments here, and at some point I might set up an official page at cpntools.org linking the source and mentioning interesting uses. For now, it’s just gonna be out little secret. Along with the rest of the internet.
Thank you for publishing these really valuable information.
I would also like to use the code for CPN design, if possible.
Can we integrate the CPN GUI part with java based implementation.
I would be appreciated, if there is a way to contact you or your group.
Thanks,
Dulani
Hi Dulani,
I’d say no, it is not possible to integrate the GUI with Java (it is, of course, in theory, but that requires a lot of work, to the extent I have decided not to do so even though I know the code). I instead suggest using the GUI of CPN Tools as it is and instead use Access/CPN to work with the models in your Java programs. This is what I do myself. Access/CPN allows you to load models created in the GUI I’ll upload Access/CPN to the repository as well “real soon now”.
Our group homepage is at http://www.win.tue.nl/ais/ and my direct E-mail is m.westergaard_at_tue.nl, though I prefer that CPN Tools specific questions go thru support@contools.org. That is a public mailing list which makes it possible for others to use answers as well (so if you have information, you don’t want to be world-readable, you need to use my direct address).