View mode: basic / threaded / horizontal-split · Log in · Help
January 18, 2013
including dmd's response.c in gdc
I'm trying to bring @cmdfile functionality to gdmd. I looked at ldc's ldmd, 
and they simply use dmd's root/response.c. Could I just include it in gdc, 
too?

response.c itself says:
> * This source file is made available for personal use
> * only. The license is in backendlicense.txt
> * For any other uses, please contact Digital Mars.

And backendlicense.txt says:
> The Software is copyrighted and comes with a single user license,
> and may not be redistributed. If you wish to obtain a redistribution 
license,
> please contact Digital Mars.

Doesn't look compatible with GPL to me. Could Digital Mars grant rights to 
redistribute it under GPL?

Then again, no other files in root are licensed that way, most say:
> // License for redistribution is by either the Artistic License
> // in artistic.txt, or the GNU General Public License in gnu.txt.
> // See the included readme.txt for details.

Has response.c simply been overlooked?
January 19, 2013
Re: including dmd's response.c in gdc
Hello? Is this thing on?
January 19, 2013
Re: including dmd's response.c in gdc
On 1/19/2013 1:31 PM, Nils Boßung wrote:
> Hello? Is this thing on?
>

Unfortunately, it'll have to be rewritten to be GPL. I don't control the 
Symantec license.
January 19, 2013
Re: including dmd's response.c in gdc
Walter Bright wrote:
> Unfortunately, it'll have to be rewritten to be GPL. I don't control the
> Symantec license.

Too bad. That means, ldc should get rid of it, too; doesn't it?
January 20, 2013
Re: including dmd's response.c in gdc
On Saturday, 19 January 2013 at 22:51:45 UTC, Nils Boßung wrote:
> Walter Bright wrote:
>> Unfortunately, it'll have to be rewritten to be GPL. I don't 
>> control the
>> Symantec license.
>
> Too bad. That means, ldc should get rid of it, too; doesn't it?

Sorry for not responding earlier, but I haven't really been 
following the newsgroups lately as I'm swamped in university work.

Yes, this is a major problem indeed. A while ago, I rewrote LDMD 
to use as much of the DMD command line parsing code as possible 
for maximum compatibility. Among the issues that lead to this 
were specifically a few reports of the LLVM response file parsing 
code handling some corner cases/quoting issues slightly 
differently than the DMD one. So, back then, I just copied the 
response_expand declaration from mars.c and assumed that the code 
would be okay to use, since response.c is in root/. The file was 
already glob-included in our build as part of root/, so I didn't 
have to look at it at all.

So, three questions:
 1) What is the best way to handle the situation from an LDC 
perspective? Pull the last release immediately and temporarily 
fall back to the LLVM response file parser in Git master? Or, 
Walter, could you grant us (resp. the LDC team/me) the right to 
redistribute the file until we have a proper solution? Distro 
packages would be another problem?

 2) Could somebody read the source and document the quirks of the 
parser in painstaking detail, so that somebody else can do a 
clean room implementation?

 3) Could we maybe move the file out of root/, as all the other 
files in there are under the front-end Artistic/GPL dual license?

David
January 20, 2013
Re: including dmd's response.c in gdc
On 1/19/2013 4:55 PM, David Nadlinger wrote:
> So, three questions:
>   1) What is the best way to handle the situation from an LDC perspective? Pull
> the last release immediately and temporarily fall back to the LLVM response file
> parser in Git master? Or, Walter, could you grant us (resp. the LDC team/me) the
> right to redistribute the file until we have a proper solution? Distro packages
> would be another problem?

Yes, you can do that.
Top | Discussion index | About this forum | D home