[m-dev.] [m-users.] Closed source Mercury projects on Windows
jfischer at opturion.com
Wed Jun 6 15:54:03 AEST 2018
On Wed, 6 Jun 2018, Mark Brown wrote:
> On Wed, Jun 6, 2018 at 2:47 PM, Julien Fischer <jfischer at opturion.com> wrote:
>> 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.
Oddly enough, you're not really one of the culprits.
> 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
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
mer_mdbcomp.m is also listed as GPL, but you can change that now.
(If anyone objects, I will provide a public domain reimplementation!)
>> 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.
> 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.
More information about the developers