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

[Zoltan Somogyi]

On Wed, 6 Jun 2018 15:54:03 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> Here's a list of the module in the mdbcomp directory that listed as
> being GPL licensed along with a list of people who have modified them
> since they were committed to the mdbcomp directory.  (The code may
> have come from the browser or compiler directory at one point but
> git doesn't track that.)
> 
>     builtin_modules.m                [GPL] zs, juliensf
>     feedback.automatic_parallelism.m [GPL] pbone, zs, juliensf
>     feedback.m                       [GPL] pbone, zs, juliensf
>     prim_data.m                      [GPL] zs, wangp, petdr, stayl, juliensf, maclarty
>     rtti_access.m                    [GPL] zs, juliensf, wangp, pbone, maclarty, mark
>     sym_name.m                       [GPL] zs
>     trace_counts.m                   [GPL] zs, wangp, maclarty, juliensf, pbone

A quick spotcheck of the git logs tells me that I am responsible for about
three quarters of the commits to these modules. I also created the mdbcmp
directory itself in commit 6b0fb566ce6257610f5458a6141602c8e0e5d940,
by moving some files from the browser directory. While I cannot remember
details that far back (this happened in 2005), I am pretty sure I did not
consciously choose the GPL over the LGPL, but simply moved the license
part of the files along with everything else. And the contents of the browser
directory *should* have been LGPL, not GPL, from the beginning; if they
weren't, that was an oversight.

So if you want clearance from me to change the license of the mdbcomp
directory along the lines we discussed, you have it, and I am pretty sure
that the rest of the committers to those files feel the same way. I don't think
any of *them* thought deeply about the issue; almost certainly, they just
(a) left the license part of the existing files alone, and (b) copied that part
of existing files in the mdbcomp directory when creating new files.

> mer_mdbcomp.m is also listed as GPL, but you can change that now.
> (If anyone objects, I will provide a public domain reimplementation!)

As the only person who has ever committed changes to mer_mdbcomp.m,
I can assure you that is not necessary :-)
 
 >> 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.
> 
> IIRC, we only use that copy of getopt for systems that don't provide it.

I believe you are right. I am not sure, but I *think* I added that copy of getopt
to the runtime for that purpose when I was providing scaffolding code for
projects to my students in whatever subject I was teaching at the time.
The scaffolding was the uninteresting part of the project's code, which
the students thus did not have to spend time to write. They thus did not
write it in umpteen weird and wonderful ways, which saved *me* time
when marking the projects.

The department's machines always had GNU tools installed on them and
thus had getopt, but some students worked on projects at home (or at their
own workplace, if parttime), and some of *their* systems did not have getopt.
So I included a copy of GNU getopt with the scaffolding code, and made it
a modified copy with renamed functions and global variables in the interface,
so that it wouldn't clash with the standard copy of getopt if it *was* installed
on a computer a student was using.

That was twenty years ago. Now, we should just assume that the system provides
getopt, and delete our copy. Unless someone knows of a current Unix/Linux/BSD/???
system that still lives in the dark ages?

> > 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.
> 
> It's probably better to get this dealt with once and for all.

Agreed.

Zoltan.