I’m pleased to announce the availability of Sigil version 0.8.0! The download location has changed sine the last release. This is because Google Code has stopped providing or allowing new downloads. Existing downloads will eventually be removed from the service completely.

It has been nearly a year since the last release of Sigil. This long delay is due to Sigil having and mainly is a one man operation. I don’t have the time I did in the past to work on Sigil so I’m mainly relying on contributions to keep Sigil current. For quite a while no one was willing or able to help. Recently Kevin Hendricks has had time and motivation to contribute and Sigil has progressed quite a bit with his help.

There have been a handful of fixes and minor improvements but that’s typical for a new release. This is a major release which means major new features…


The big new feature Kevin has spearheaded is plugin support. This has been long requested and it’s finally here.


Plugins support is a revision one at this point. We have plans to expand it out in the future. The system is designed to be flexible and allow for a lot of new features. Plugins are standalone and don’t hook directly into Sigil in term of UI changes. They’re mainly for advanced processing at this point.

Currently Python 2 and 3 are the only supported languages for Plugins. The system is designed to be able to add other languages in the future quite easily. The decision to focus on Python for this release is due to the amount of existing Python code for ebook manipulation that is currently available.

Sigil does not currently bundle Python but relies on Python being installed (this could change in the future). In preferences you’ll need to specify the Python executable location. If you’re on OS X it’s already installed with the OS and you just need to use the auto button to have it auto detected. Linux can also use the auto button. Most likely it’s already installed if you use Linux. For Windows user’s you’ll want to install something like Active State’s ActivePython (community edition is free).

Again, plugins are standalone. What happens is Sigil will call the interpreter (Python in this case) with an internal launcher script as the target. A few bits of info along with the target plugin are passed to the launcher which manages running the plugin. This allows for some really cool stuff like separation of plugins from Sigil’s internals and easy recovery if a plugin crashes.

Plugin Licensing

Sigil itself is Open Source and is licensed under the GNU GPLv3. The plugin system was written in a way that allows plugins to be released under any license the plugin author wants. A plugin author isn’t forced to use the GPLv3. Plugin authors aren’t required to release their plugins as open source either. They are free to release commercial closed source plugins.

The licensing allowance is not due to a licensing exception but due to how plugins are called. Plugins are run via the plugin launcher as a separate process. The launcher itself is licensed under a 2 clause BSD license. The plugin architecture is standardized and not dependent on Sigil. It is entirely possible to use a Sigil plugin in another application if that application implements the launcher interface. The idea is plugin authors write to the launcher API and Sigil implements that API.

The plugin API is very similar to calibre’s API. We have actually tested some cailbre plugins in Sigil with little or no modification of the plugin itself.

Does This Mean Sigil is Going Closed Source?


The idea is to allow people to extend Sigil without putting restrictions on them. Again, there is a lot of existing ebook manipulation code out there that this allows Sigil to take advantage of.

Allowing permissive licensing allows existing non-GPLv3 licensed code to be used with Sigil without forcing that code to be relicensed. Think about small publishing houses that have their own internal tools. They can integrate those tools with Sigil without having to worry about any licensing issues or worry about needing to relicense.

The motivation is code reuse and allowing users to expand Sigil. This is no different than the “open with” feature which allows external editors to be used in conjunction with Sigil. Think about images which Sigil doesn’t currently support editing. Users can use “open with” to edit an image using another tool and allow Sigil to use those changes.

Let me be very clear, I have no intention of withholding features from Sigil in order to make them into pay only and proprietary licensed plugins. I fully believe that this is not Kevin’s intention either (he’s contributed quite a bit of code to various places all open source).

Plugin Repository?

Not right now. There isn’t enough man power right now for this. We also don’t know how popular this feature will become or how many plugins will be created. It’s possible it will be very popular but only a handful of plugins will ever be made and used. I’m not willing to put resources toward this until it’s necessary.


This is a big release but it’s a first step release. There is a lot that can be done with plugins in the future. We haven’t even scratched the surface of all of our ideas. It just takes time.