[m-users.] Closed source Mercury projects on Windows

[Zoltan Somogyi]

On Fri, 25 May 2018 20:49:03 -0700, Martin McDonough <foolkingcrown at gmail.com> wrote:

> Hi,
> 
> So I see that the runtime, stdlib, and some components that are compiled
> into Mercury programs with certain options (trace, mdb stuff) is licensed
> under the LGPL. But on Windows, mmc can't be compiled to produce shared
> libraries and the runtime and stdlib can't be compiled as shared libraries.
> 
> This seems like a serious problem for distributing any close source (or
> even simply non-GPL-compatible) program for Windows.

It shouldn't be a problem at all. It has been several years since I have
looked at the LGPL, but it has always been my understanding that it is
intended *specifically* to allow proprietary code to remain proprietary
even when linked with open source libraries. As the LGPL states:

"This Library General Public License is intended to
permit developers of non-free programs to use free libraries, while
preserving your freedom as a user of such programs to change the free
libraries that are incorporated in them."

If anyone wants to change these "free libraries", they can get them from
the Mercury web site, and change them as they like. You need only tell them
where that website is (mercurylang.org). This should satisfy section 6c.

Moreover, I don't see anything in the LGPL that categorically distinguishes
static linking from dynamic linking. 

However, to make this clearer, ...

> I do see that there is a note in Copying.lib about negotiating a different
> license. Is it reasonable to expect that someday at least the parts that
> are automatically compiled into Mercury programs (like mer_rt) would be
> under a license like "LGPL with static linking exception" that some
> projects like FLTK use, maybe even only for Windows?

... we will look into explicitly adding such an exception.

Zoltan.