Open Source vs. Commercial Licenses Open Source Licensing Basics Unlike many Open Source software projects, Ghostscript and MuPDF are owned and fully controlled by Artifex. The vast majority of all Ghostscript and MuPDF development is done by Artifex engineers, and on rare occasions, bug fixes accepted from outside contributors (under license by Artifex). If you have further questions regarding the development and control of Ghostscript and MuPDF, please contact, President/CEO Artifex Software. We provide two of our technologies, AGPL Ghostscript and AGPL MuPDF, under the GNU Affero General Public License (AGPL), as well as under an Artifex commercial license. For more detailed and complete information on the AGPL please visit the This page is intended to provide a summary of information that developers and companies may find useful in understanding licensing options available for Artifex products.
It does not represent legal advice. We strongly encourage developers and/or companies to review the specific licensing text made available on the If you are trying to determine whether to use Ghostscript and MuPDF software under AGPL or our alternative Artifex commercial license, please consider the following guidelines. Distribution – Unlike most other open source licenses, AGPL’s conditions are not all dependent on re-distribution of the software. For most other open source licenses (like GPL), the condition for making source code available is the distribution of the software.
Distribution means making a copy available (or delivering a copy) to someone outside your organization. So, for example, providing the software to an employee within your organization is not distribution, but providing the software to an outside consultant, beta tester, or customer is distribution. If you are redistributing our software in binary form, you must make the source code available. AGPL also requires this. Network Use – However, AGPL also has some conditions even if you are not distributing the software. For example, if you are using the software on your own company’s equipment, but you are making the functionality of the software available to users interacting with it remotely through a computer network, and you make any change to the software, you must make the source code for your changed version available to users of the software. Take care to ensure that during network deployment that there is no code change that could invoke the source code availability obligation. This special requirement of AGPL is in Section 13; see the for more details. Bottom line, if you distribute our software, or make the functionality of the software available to users interacting with it remotely through a computer network, you must share your source code. Corresponding Source – If you combine our software with other software, you might have further obligations under AGPL that you would not have under our alternative commercial license. The conditions of AGPL require you to provide the Corresponding Source code for any binaries you distribute. This may include source code for your application. The Corresponding Source includes “all the source code needed to generate, install and (for an executable work) run the object code and to modify the work, including scripts to control those activities.” For example, if you ship an executable product that includes your application and Ghostscript (or MuPDF) in a single executable, including integration via static linking, dynamic linking, or any other means that produces a single executable at compile, build, or runtime, then the entire executable must be made available in source code form under AGPL3.
If you meet certain criteria, then we will not consider the distribution of your application in an executable form to be in violation of AGPL, even though you ship an executable product that includes your application and Ghostscript (or MuPDF). Here are the criteria:. It is conspicuous and clear to the end user that he/she is getting access to two separate pieces of software (i.e., AGPL Ghostscript or AGPL MuPDF in addition to the application using either of these products).
The end user has the ability to opt out of installing the AGPL version of our products during the install process. Each AGPL module is separable and replaceable within the build. The available source code for the AGPL modules must be for the build that corresponds with your binaries. Any other redistribution is not licensed under AGPL. If you cannot meet the requirements of AGPL, you should to inquire about a commercial license. More information on the various licensing options available for our three products follows below. Artifex Licensing Artifex has different licensing approaches for our different products.
Ghostscript and MuPDF are available under both Open Source and commercial license arrangements, while SmartOffice is available only under a commercial license for OEM partners and under an end-user license (as an end-user solution). Ghostscript and MuPDF Artifex is the exclusive commercial licensing agent for Ghostscript software and MuPDF. There is no “public domain” version of Ghostscript or MuPDF. All versions of Ghostscript and MuPDF are provided under one of two licenses (Commercial or GNU AGPL Open Source) described below. The kind of distribution or use you plan to make of Ghostscript or MuPDF will determine whether you need a commercial license from Artifex. If you plan to distribute Ghostscript or MuPDF in one of your products or make them available to your SaaS or ASP customers, you should understand the differences between these licenses.
Please note that the rules below apply even if you ship or make available a free demonstration version of your own product or application. An “application,” as referenced below, can be any type of software product or application, tool, system or utility. THE BASICS A commercial license is required if your application (including source code) is NOT licensed to the public under the GNU AGPL and.
you intend to distribute Ghostscript or MuPDF to a third party for use with (or usable by) your application, or. you intend to allow your users to remotely interact with AGPL Ghostscript or AGPL MuPDF along with your application. In the above circumstances, if any one of the following is true you are not authorized to ship AGPL versions of Ghostscript or MuPDF. A commercial license is required If your application:. contains a copy of some or all of AGPL Ghostscript or AGPL MuPDF. is derived from, based on or constitutes a revision of some or all of AGPL Ghostscript or AGPL MuPDF.
includes one or more functions that use some or all of AGPL versions of Ghostscript or AGPL MuPDF. The above criteria apply to your application as a whole. Even if only one section satisfies one of the above criteria, you cannot use AGPL versions of our software and need a commercial license. THE BASICS If your entire application, including all source code, is licensed to the public under the GNU Affero General Public License (GNU AGPL), you can provide either of our AGPL products with your application without a commercial license. The terms of the AGPL require that your application be licensed as a whole at no charge at all to third parties. If your use of AGPL Ghostscript or AGPL MuPDF is such that you will not be distributing to a third party (e.g., creating an internal newsletter or database to be used within your organization), you are authorized to use these AGPL versions and to allow your users to remotely interact with these versions along with your application. Please note that this is only valid as long as this use is only within an organization.
Should a user outside the legal organization entity gain access to the software it counts either as a distribution or remote network interaction, which would require a commercial license. EXAMPLES Generally speaking, “distribution” is the key word. Some examples of distribution/network use requiring a commercial license include:. Distributing Ghostscript or MuPDF (or any component) within your non-AGPL application. Distributing Ghostscript or MuPDF on the same media with your non-AGPL application for use with and/or by your application.
Distributing Ghostscript or MuPDF embedded within hardware (such as a multi-function printer or RIP). Running Ghostscript or MuPDF on your network servers and permitting non-employees access to interact with these products as part of your non-AGPL application. Example: utilizing Ghostscript to interpret and display a PDF on a cloud application. These are illustrative examples only and do not cover all the situations that require a commercial license. Please and we’ll help confirm the type of license you may need for your intended use. EXAMPLES There are a number of situations that qualify for use of AGPL Ghostscript or MuPDF under terms of the AGPL license.
Some examples include:. Use Ghostscript to translate old PostScript files into PDF files for use in generating internal reports or documents (within organization). Use of Ghostscript for research and education purposes (e.g., developing a prototype for a college computer science project) that are not distributed to third parties for additional use. Use Ghostscript within an IT department for internal uses only. These are illustrative examples and do not cover all the situations that may qualify for an AGPL license. If you have a question as to whether your project qualifies, please and we’ll help clarify whether you qualify for open source licensing of our products. Which is Right for You?
We recommend that all commercial entities that wish to distribute Ghostscript or MuPDF, or make them available to SaaS or ASP customers, enter into the Artifex Commercial License agreement. This frees you from having to conform to the requirements and restrictions of the GNU AGPL licenses, it also provides you with additional benefits and rights, such as access to ongoing commercial version updates and support. And we’ll help you select the appropriate version for your intended use and your needs. SmartOffice SmartOffice offers commercial licenses only (there is no open source version). The SmartOffice mobile app may be downloaded from iTunes and Google Play for individual use.
There are also several different versions of SmartOffice available for enterprise use, depending on your intended use and needs. These include:. – Full featured, SmartOffice branded app. – A customizable version of SmartOffice to facilitate integration within an existing mobile security platform or enterprise brand presentation. Viewer Only versions of the above two products. Versions designed for embedding in various hardware and software products.
We have a complete listing of all available SmartOffice products for commercial licensing.
Well, I had to abandon that idea due to licensing constraints. We're stuck with shelling out to Ghostscript at this point, because if we compiled with the gs dlls we'd break the GPL license (I work on a commercial product).
Unfortunately, I haven't had enough non-work time to develop something like this for use by the community. In general, a C# wrapper to the GS C DLLs (pardon the alphbet soup), would be trivial to write, however would involve a lot of time-consuming typing.
Once that wrapper was in place, you could work on writing a top level library that used that wrapper, but did things in a more 'C# way'. Sierra bravo actress. A good start would be to take this project and just create a minimal syntactic port to C#. What would be cool is to see someone port the GS code to Java or C# directly. But that would be quite an undertaking. I'd be glad to assist in whatever way I can if you decide to get this project going.
Thanks, Troy. Great to hear you're interested in this.
I've sinced moved to a new job where we are not using Ghostscript, so this has sort of fallen off my radar. The good news is that my new job allows me a LOT more free time to work on these kind of things (ie, non-work coding projects).
So, I might be able to start on this project now. I would say the first step would be to port this API from C to C#. That's not a trivial task.
A quick look over the source puts it at about 2200 lines of C code (.cpp and.h files). Do you have any experience porting c to c#? I have minimal experience.
Another option would be, instead of porting it, to simple compile this c code, and wrap up the full API in C#. That would be faster, and easier, but it means that the code that actually does the work would all be in c, meaning, to update or change it (for example if there are GS c api changes in new versions), we would need to update it in c, rather than C#.
It also means yeat another layer of wrapping, which means yet another layer of debugging to go through. The C code seems straightforward and it's well documented. I think a port would be easy enough just working from what is presented in this article. So, what do you think? I'll try to have a minimally functional version of the API wrapper up there in the next couple of days. I does occur to me that having the API established in C# would allow someone to start re-writing the backend slowly. However, the Ghostscript API is very high-level, and still operates like a 'blackbox'.
Meaning, you pass the postscript source code in, and it parses it, executes it, and when it figures out what to display, it draws to whatever device you've configured, which could optionally be a custom device that you've written that it calls back toe (which is how the GDI+ integration will occur). This is a fairly minimal API. I would like to see it expanded to expose the parser, the execution and operand stack, the core static functions, actual vector information about the drawing commands instead of just raster drawing. But that would mean re-writing ghostscript completely. Which is probably beyond my weekend warrior schedule. I would love to see it be a completely free product for commerical use or otherwise. I would also love to have that kind of functionality exposed so that a decent IDE could be built against it.
So - Here you go. For all the world to see.
My offer: If anyone wants to pay me to re-write Ghostscript in C# as a completely free, open source product, and develop a Postscript IDE, I'll definatly entertain the idea of leaving my current job if the salary is comparable to what I'm making now and I don't have to move from Portland, OR. Wick#3 20-Nov-06 21:58 20-Nov-06 21:58 I have been working on trying to get PDF to PS (or for that matter PDF to EPS) via GhostScript or anything else within the.NET context. MAny go the other way and most things that call themselves PS are image files - not old school 'placed text' (as in what was produced by Illustrator v9 when you saved a imported PDF as PS).
I have tried working with gs pdf2ps but can not seem to get anything to come out right (either an unkown device or it comes out as an embedded image - which does not work well with prepress). It is late so I am hoping this makes sense. Is what I am looking for inside of what you have here? I guess, the CAPISettings class is not clear.
As for testing, just try to enter manually instead CAPISettings data before miLastStatus=minitwithargs.