On Mon, Apr 6, 2009 at 11:34 PM, Gert van den Berg <wine-users@xxxxxxxxx> wrote: > On Tue, Apr 7, 2009 at 6:20 AM, Austin English <austinenglish@xxxxxxxxx> wrote: >> On Mon, Apr 6, 2009 at 11:10 PM, Gert van den Berg <wine-users@xxxxxxxxx> wrote: >>> Including a FreeDOS command.com in Wine is probably not a bad idea, >>> presuming that Wine's DOS support is working well enough for it to >>> run... (I've never been able to run any DOS programs under Wine) >> >> It's GPL'ed, Wine is LGPL'ed, the license is incompatible. >> >> If they'd be willing to re-license it, that may be an option... >> > How about just bundling it? This would require it being used and not linked in.. I don't think that'll fly past AJ/devs. Does it actually gain us anything? > It can also get installed on request, like Gecko... Possibly, but command.com is something that should be in there by default, IMHO. > IMHO, Wine would need to turn into some kind of distribution > eventually, including the core Wine and some bundled utilities, from > say, ReactOS (explorer), FreeDOS (commnad.com, general DOS > utilities...), etc.. No. Wine is an application/set of libraries, not a 'distribution'. Furthermore, Wine doesn't accept ReactOS code. We've got an explorer replacement (winefile/virtual desktop). > GPLv2 has: (And an actual lawyer probably need to give an opinion...) > (v3's terminology make a quick search hard....) > "In addition, mere aggregation of another work not based on the > Program with the Program (or with a work based on the Program) on a > volume of a storage or distribution medium does not bring the other > work under the scope of this License. " SFLC would be the one's to ask. IANAL, but that's the general interpretation I've heard as well. The problem then is, what happens if we need to improve the command.com code? Relicensing would be the best course of action. -- -Austin
