Moved to DOSBox General subforum.

Dominus provides regular snapshots at https://www.dropbox.com/s/kbrf5elbcu66kst/Dos … ox-Snapshot.dmg what are build from the tip of the official SVN tree at https://sourceforge.net/p/dosbox/code-0/HEAD/tree/

However, it is entirely unclear to me if the HEAD has switched to SDL2 at this point. From what I gather on this forum, SDL2 does not have the CD audio library that SDL1.2 has, and that was a major gap. Probably other small difference too. But I think I read someone had reimplemented that, so maybe HEAD is now on SDL2. But I may well be entirely wrong about this.

DOSBox is a wonderful app, but without developer blogs or human-readable changelogs, figuring out where the codebase is right now is like playing pin the donkey 😉.

In any case, a next major version is expected Very Soon Now, but there have been some persistent blocking bugs. And because the devs are all volunteers we cannot and should not complain about release schedules or demand progress updates.

You could have just messaged me 😀

There is no source code but a patch for SVN at An adaptation to SDL 2.0 (Alpha-level Android build attached)
*unfortunately* SVN broke the patch a little while ago so it's a couple of weeks old atm.

DOSBox source code is at https://sourceforge.net/p/dosbox/code-0/4334/log/?path= and this the place to read each changes.

I'll paste this as-is:

---

The GNU GPL demands that as soon as you distribute GPL licensed software in executable format you make available the "complete corresponding source code". The GNU GPL also contains a definition of this term:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

This is a quite precise definition. For a typical C program, this translates into all the source code (.c files) plus header files (.h files) plus the scripts used to control compilation and installation.

Always keep in mind that it is the purpose of the GPL to enable the users to exercise his freedoms. Specifically, the freedom to make modified versions of the program, and to run such modified versions of the program.

http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

https://gpl-violations.org/faq/sourcecode-faq/

---

Dominus,

I think to comply with the spirit of the GPL, RobinW needs more than a pointer to the bit-rotten SDL2 patch and the latest patch SVN sourceforge site.

RobinW wants to build and modify exactly what you're releasing in binary .dmg.

So this means sharing the steps and scripts you used to generate your app-signed Apple .dmg file, and your exact source tree corresponding to your released .dmg files.

pffffff

Dominus wrote on 2020-03-11, 14:03:

pffffff

pfffff ... would be a legit response if DOSBox was BSD-licensed 😀

But yeah.. the Software Freedom Law Center (SFLC), even wrote a guide about build scripts and steps needed to get to the distributed binary:

https://www.softwarefreedom.org/resources/200 … ance-guide.html

4.2.2 Building the Sources

Note that you must include “scripts used to control compilation and installation of the executable” and/or anything “needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities”. These phrases are written to cover different types of build environments and systems. Therefore, the details of what you need to provide with regard to scripts and installation instructions vary depending on the software details. You must provide all information necessary such that someone generally skilled with computer systems could produce a binary similar to the one provided.

...

[...] Sometimes, however, scripts were never written (e.g., the information on how to build the binaries is locked up in the mind of your “build guru”). In that case, we recommend that you write out build instructions in a natural language as a detailed, step-by-step readme.

No matter what you offer, you need to give those who receive source a clear path from your sources to binaries similar to the ones you ship. If you ship a firmware (kernel plus filesystem), and the filesystem contains binaries of GPL’d programs, then you should provide whatever is necessary to enable a reasonably skilled user to build any given GPL’d source program (and modified versions thereof), and replace the given binary in your filesystem. If the kernel is Linux, then the users must have the instructions to do the same with the kernel. The best way to achieve this is to make available to your users whatever scripts or process your engineers would use to do the same.

fine... well done...
if anyone needs a snapshot ask kcroft. I'm done.

Dominus wrote on 2020-03-11, 15:00:

fine... well done...
if anyone needs a snapshot ask kcroft. I'm done.

You've decided to taken down your OS X binaries instead of complying with the license that gave you the right to create them in the first place.

Wow. Seriously?

Edit: I shouldn't have said that last part; sorry; it's not helping anyone. It's your right if you want to provide those or not; and taking down binaries is perfectly compliant as well. Even though it's not the decision I wanted you to make, I none the less respect it.

yes. You wanna play GPL cop, be my guest. but not on my time.

I have no time to set up yet another script to provide the source. my scripts are available online but again, right now I couldn't care less. maybe I'll see about doing this another time but for now you can have this win.

It's a loss my friend; no one won, and RobinW is not further in modifying and building your .dmg package regardless. Why not just upload your exact source tree and scripts sitting on your HDD that you build with? Your call though. Will leave it at that.

Let me repeat... SVN+patch I linked to.

Dominus wrote on 2020-03-11, 11:37:

There is no source code but a patch for SVN at An adaptation to SDL 2.0 (Alpha-level Android build attached)
*unfortunately* SVN broke the patch a little while ago so it's a couple of weeks old atm.

Yeah, I remember that thread. I just hadn't realised that the work was still being discussed there, as it has apparently moved beyond the pre-alpha android build. Thanks for the clarification.

Sorry to see that this thread got out of hand so quickly 🙁. I meant no offence, just trying to post what I knew. Apologies if it came across as disrespectful.

Shame...

GPL is enforced by the copyright holders (so the authors of dosbox). If they allow someone to redistribute a binary of their GPL project without providing source code, there has been no lic violation. This would ultimately be an agreement between the two parties, and nothing to do with any GPLcop.

Any contributors into a project should have agreed to a CLA before being accepted upstream.

This also goes for forks. If the original author doesn't like a fork, they are perfectly within their right to introduce a dual lic (GPL and even GPL-conflicting proprietary lic) preventing a fork from being able to pull updates from that point on (of course all code up to that point is still under original GPL).

This isn't very "open-sourcey", and may put off contributions, however, while GPL protects users to be able to do what they want, this does not detract from the copyright of the original author who still holds ultimate power and can choose what to enforce, and who to enforce it on.

... just say-in.

P.S IANAL

Yes, it is such a shame this happened. 🙁

Time to teach myself how to manually patch DOSBox SVN snapshots ... *sigh*

Closed

Leave the policing to the mods. Thanks

Almeath,

PM Dominus or start a new thread without the baggage of this one.