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--