Re: Failure to detect pswrite and epswrite Ghostscript devices
Bob Friesenhahn <[email protected]> Mon, 2 Nov 2015 08:30:41 -0600 (CST)
| Newsgroups | gmane.comp.video.graphicsmagick.bugs |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1775383734-1446473924=:1673 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-ID: <[email protected]> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by blade.simplesystems.org id tA2EUfJm003747 On Mon, 2 Nov 2015, Test User wrote: >=20 >=20 > Yes, that makes sense. The LGPL is the one that stops the "infection", > but GNU Ghostscript is GPL. Even GPL does not require changing license statements in all source=20 files to match. In fact, it explicitly does not require such a thing.=20 What Artifex claims to require does not make sense (and is usually not=20 possible) since it would require a GPLv2 project to have all of its=20 existing license statements changed to AGPLv3. It is clear that Artifex wants to commercially license Ghostscript and=20 accomplishes this by assuring that its license is not viable for=20 most commercial purposes. > By the way, I noticed the following in the configure script: > # It would be nice to use reg.exe to obtain Ghostscript information > # but unfortunately MSYS seems to transform registry key paths into > # filesystem paths so it does not work.=A0 Maybe there is a way to > # prevent that translation? >=20 > Does the following solve that problem? > $ cmd /c "reg query \"HKLM\Software\GPL Ghostscript\" /s" >=20 > HKEY_LOCAL_MACHINE\Software\GPL Ghostscript\9.18 > =A0=A0=A0 GS_DLL=A0=A0=A0 REG_SZ=A0=A0=A0 C:\Program Files (x86)\gs\gs9= .18\bin\gsdll32.dll > =A0=A0=A0 GS_LIB=A0=A0=A0 REG_SZ=A0=A0=A0 C:\Program Files (x86)\gs\gs9= .18\bin;C:\Program Files (x > 86)\gs\gs9.18\lib;C:\Program Files (x86)\gs\gs9.18\fonts I will check. This hunk of configure code is there to allow 'make=20 check' to work in MinGW builds. Hard-coding any paths (or making=20 decisions based on local paths) is not normally desired for Windows=20 binaries since they are often installed on other systems, which may=20 use different (almost arbitrary) paths. There are some other loose ends in the MinGW build. Particularly, the=20 delegates.mgk file from VisualMagick/bin is more suitable for Windows=20 than the one from config/delegates.mgk.in. Bob --=20 Bob Friesenhahn [email protected], http://www.simplesystems.org/users/bfriesen= / GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ---559023410-1775383734-1446473924=:1673 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ ---559023410-1775383734-1446473924=:1673 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Graphicsmagick-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs ---559023410-1775383734-1446473924=:1673--