This is not relevant for DOSBox, since ...

1/*
2 *  Copyright (C) 2002-2015  The DOSBox Team
3 *
4 *  This program is free software; you can redistribute it and/or modify
5 *  it under the terms of the GNU General Public License as published by
6 *  the Free Software Foundation; either version 2 of the License, or
7 *  (at your option) any later version.
8 *
9 *  ...
10 */

This may be true, except to the best of my knowledge as you point out, DOSBox is 'GPLV2+', i.e. GPLV2 with the "or (at your option) any later version." clause left intact.
However, as a whole, DOSBox is licensed (currently) GPLV2, so any xBR/xBRZ stuff which is licensed either GPLV3 or LGPLV3 is incompatible with the current distribution of DOSBox, unless DOSBox changes its entire license to GPLV3.
(any xBR/xBRZ stuff which is licensed GPLV2 or LGPLV2.1 is fine, though)

Due to the fact that certain distributors (Steam, (and MAYBE HumbleBundle?)) use DRM/TiVo-ization and distribute certain games with DOSbox packages (with sources included), changing the license to GPLV3 might hurt the project significantly.

LN

What makes DOSBox as a whole GPLv2-strict? Does it rely on 3rd party GPLv2 code?

My understanding is that you can ship GPLv2+ code along GPLv3 code, making the binary GPLv3. But if you strip out the GPLv3 bits from the source, it becomes GPLv2+ again. Is it incorrect?

That sounds vaguely correct but I'm not 100% sure.
It still would prevent anyone who needs GPLV2 binaries from using the code, though.

I've been informed that the Hyllian-created xBR code specifically in ffmpeg is licensed LGPLv2.1 so using that specific implementation of xBR is GPLV2 compatible. See http://ffmpeg.org/pipermail/ffmpeg-cvslog/201 … ber/083248.html

I have no idea yet if any xBRZ implementations are licensed 'less than' GPLV3, though.

Lord Nightmare wrote:

I've also (unlike HQX) yet to see a full mathematical description of the xBR/xBRZ algorithms which would allow a separate, permissively licensed code version to be created from scratch and not run into problems inherent in 'looking at GPL code to write BSD/MIT code'

Hence, I'm avoiding xBR until I can see a textual description of how it works.

xBR algorithm tutorial

Well, that's a start, at least. The post looks similar to the one that was deleted with a forum purge at byuu's old forums, but looks only about 1/2 complete description of the algorithm.

What I find far more useful however is that Hyllian seems to have relicensed about half of the xBR code at https://github.com/libretro/common-shaders/tr … ter/xbr/shaders as MIT. There are still a bunch of GPLv2 bits mixed in there, but the MIT parts are definitely usable to me.

LN

Hey Zenju,

Which was the last version that supported XP? Or would you mind re-compiling with XP support please (actually, I'm using XP x64).

I'm getting this error:

edit: Just want to confirm that DOSBox_0.74+xBRZ_1.2+Save_States_Win32 does indeed work on XP, so the XP target just has to be added for future compilations...

Also, the xBRZ is not something I'm really that interested in, and my computer isn't fast enough for it. Is there a way to run the executable so that I just have the savestate support without xBRZ?

Thanks

Here's another textual description:

http://libretro.com/forums/showthread.php?t=1 … ull=1#post34668

ZenJu, the results look very impressive. How does the algorithm work?

Binet wrote:

ZenJu, the results look very impressive. How does the algorithm work?

Have a look at the code. It's beautiful. 😀 Generally speaking it does a pattern matching, but in contrast to HQx it does not check against a list of specific patterns, but a only small set of highly generic patterns. Thous the better overall result. The seamless alpha-blending of the output geometry also doesn't hurt.