Hi Eric, I searched for copyright notices in the code and this is what I found:
Copyright notices we don't have to worry about: - ✔️ The Audio Solution -> John W. Ratcliff himself, who has given permission to "do whatever we want" with his code - ✔️ Miles Design, Inc. -> John Miles, who has also permission for his AIL2 code and DIGPAK/MIDPAK contributions to be used freely Copyright notices that are probably not problematic (although IANAL): - ❓VESA, Inc -> VBE/AI specification and SDK, can now freely be downloaded from VESA (upon free registration) Copyright notices of now defunct companies, the rights of which could still be in the hands of other companies: - ⚠️Media Vision -> out of business, not sure what company (if any) would own the IP to their DIGPAK contributions - ⚠️Forte Technologies -> Gravis Ultrasound SDK files, no redistribution permitted, but where is Forte Technologies now? Copyright notices and possible IP from companies that still exist: - ⚠️Turtle Beach Systems -> company still exists - ⚠️Missing from any copyright notices is Creative Labs, although John Ratcliff explicitly mentioned receiving code contributions from them, which he explicitly does not claim ownership (or sublicensing rights) to. Copyright notices from other contributors: - ⚠️Scott E. Sindorf -> contributed a secondary screen debugger and some tweaks to the Sound Blaster driver code So if we wanted to be safe, we would have to leave out the source code for the following drivers and tools: - ⚠️all the Sound Blaster and compatible drivers (including the Sound Blaster Clone and Media Vision Thunderboard drivers) - ⚠️all of the Media Vision drivers (Pro Audio Spectrum) - ⚠️all of the Turtle Beach drivers (such as the Multisound, not sure if there are others from this company) - ⚠️The Gravis Ultrasound (GF166) driver - ⚠️The secondary screen debugger (it's a separate single file that doesn't seem to be included by any of the other sources) The rest I'm not so worried about. We could inquire with VESA if they are okay with the VESA AI Include file (with service definitions and such, but no source code) could be included with these sources. I think it's highly unlikely that they were to object to that, since it's an obsolete standard that sadly didn't even gain seriou adoption back in the day. Here's the thing with all these drivers, though: most of them (except for the Gravis Ultrasound driver, the Turtle Beach drivers and the later Sound Blaster model drivers) are built from a single assembly source file, with all the device-specific parts placed inside IFDEF statements. So I think a practical approach would be to write a script that would filter out the potentially legally problematic driver code by their device-specific IFDEFs, before publishing the resulting sanitized code on GitHub. We could then worry about porting the remaining drivers to another assembler dialect later. What do you guys think? On Sat, Feb 13, 2021 at 9:22 PM Eric Auer <e.a...@jpberlin.de> wrote: > > Hi Volkert, > > if you ask me, unless you can convince Creative otherwise, > we should really omit any third party sources in that digipak > driver source code release. Any other third parties involved? > > I remember that there is a NoMySo (not my source) script to > convert ASM sources to more free dialects, you could try how > well that works on digipak sources :-) I am not sure whether > it has TASM, MASM or both as input. Output was NASM or JWASM > as far as I remember. > > Regards, Eric > > PS: Feel free to reply as part of the freedos-devel thread. > >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
