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

Zoltan Somogyi zoltan.somogyi at runbox.com
Sun May 27 07:40:27 AEST 2018



On Sat, 26 May 2018 12:58:16 +0200 (CEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 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.

The language in the LGPL (COPYING.LIB) that says

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License."

indeed looks worrying. It has never been our intention to prevent
proprietary programs being written in Mercury, so would anyone object
if I added a prelude to COPYING.LIB modelled after the prelude of
http://www.fltk.org/COPYING.php? I would of course post the diff
for review first.

By the way, is anyone else having problems with

https://github.com/orgs/Mercury-Language/dashboard?

It *should* show the most recent commits, but for several days now,
I see nothing but a gif saying "loading activity" spinning forever,
even with all my adblockers disabled.

Zoltan.


More information about the developers mailing list