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

[Mark Brown]

On Wed, Jun 6, 2018 at 2:47 PM, Julien Fischer <jfischer at opturion.com> wrote:
>
> On Wed, 6 Jun 2018, Mark Brown wrote:
>
>> I've come across another problem: much of the mdbcomp directory is
>> actually labelled GPL even though mdbcomp itself is LGPL. I really
>> can't change these files without clearance, although I imagine they
>> were always intended to be LGPL given they were in mdbcomp in the
>> first place.
>
>
> Chances are they were originally in the compiler directory and the
> license wasn't updated when they were moved to mdbcomp.  (I would
> note that some of those files are included directly in GPL'd components
> like the slice tools or deep profiler.)
>
> What sort of clearance do you need?

For example, if the people who git would blame for adding ostensibly
GPL code to an LGPL library can confirm that it's okay for them to
have done so. It's possible I am one of the culprits here although
I've checked and I don't think so. Any code I may have moved would
originally have been written by Zoltan (e.g. goal_path stuff, which
may have got to mdbcomp via the browser directory).

>
>> To avoid unintended captures, rather than change COPYING.LIB I am
>> going to add COPYING.CORELIB which will contain the special exception
>> and the LGPL. Then, at least for the time being, I'll just update the
>> copyright messages for the standard library and runtimes to point to
>> the new license file, since those libraries are the ones primarily
>> needed. We can move the debugging libraries over to the CORELIB
>> license as a separate change, once mdbcomp is sorted out.
>
>
> As I mentioned the other day, the situation with the trace library
> and GNU readline complicates things for debugging grades as well.
> (We will need to document that situation fairly carefully, e.g.
> configuring with --without-readline etc.)
>
> I've been looking into supporting the NetBSD editline library as
> alternative to readline.
>
> The situation with getopt code potentially being included in the runtime
> directory still needs to resolved.

Ok. Sounds like even more reasons to move things over in a piecemeal fashion.

Perhaps it is worth remembering at this point that there is probably
very little demand for people to distribute closed source binaries
with debugging enabled.

Mark