Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submitting pull request for GUS and other devices? #4

Closed
MobyGamer opened this issue Nov 16, 2021 · 8 comments · Fixed by #6
Closed

Submitting pull request for GUS and other devices? #4

MobyGamer opened this issue Nov 16, 2021 · 8 comments · Fixed by #6

Comments

@MobyGamer
Copy link
Contributor

The repo does not have the full distribution of SHELL; it is missing GUS, Turtle Beach, WSS, and other devices. I have those sources.
@volkertb Should I submit a pull request, or would you like the sources out-of-band to integrate in your own way?

@volkertb
Copy link
Collaborator

Hi @MobyGamer. 🙂

Yeah, I noticed that these additional sources were missing too. As a matter of fact, I found that even the drivers that weren't missing couldn't be built because of some missing files that I later added to the repo from the ZIP file you shared with me earlier. I also included a VBE/AI header file once I received an email from someone at VESA who confirmed that the VBE/AI stuff is now in the public domain. (Also I believe header files with copyright notices are APIs and thus fair use, as decided by SCOTUS in the Google v. Oracle decision earlier this year.)

As for the other missing drivers that were in your ZIP file, but not initially in John's repo, I was a bit hesitant about adding those, because of possible third party IP issues. The WSS sources are probably fine, since Microsoft developed the Windows Sound System in an attempt to develop a vendor-neutral industry standard. I couldn't see how they could object to any of that being open-sourced. (We could ask someone at Microsoft such as @bitcrazed to chime in on this, if we want to be sure.)

But for instance the GUS driver is a bit tricky, since it contains code from an SDK from Forte Technologies that explicitly forbids distribution without their approval. I did some Googling to figure out if Forte Technologies (with whom Gravis developed the GUS and the accompanying software) still even exists, and if not, which company now owns their IP, but I couldn't find any information about that. But even if Forte Technologies has disappeared from the face of the Earth, that doesn't make the IP situation of the GUS DIGPAK drivers any less questionable.

In the case of the Turtle Beach driver, that company still exists, so we could try reaching out to someone at that company to ask if they would still object to the release of any code that they may have contributed to the driver back in the day.

Also, as I wrote a while back in this post in the freedos-devel mailing list, John told me that he remembered Creative Labs contributing to some of his drivers. But there are no copyright notices from Creative Labs in his sources (like there are from Forte Technologies and Media Vision), and also the programming guides from Creative Labs for the various Sound Blaster ISA cards are publicly available.

So what do you think? Am I being overly cautious here?

Let's try reaching out to Microsoft and Turtle Beach first. And if anybody reading this happens to know which company owns the Intellectual Property of Forte Technologies these days, please let us know here. Thanks. 👍

@volkertb
Copy link
Collaborator

See also this other post in freedos-devel in which I made a list of the driver sources that I believed to be safe to release, and the once that I wasn't sure about, due to copyright messages and such.

@MobyGamer
Copy link
Contributor Author

MobyGamer commented Nov 17, 2021

Thank you for your detailed summary and history!

I personally think you're being overly cautious, since the licenses in question are 1. over a quarter-century old, 2. were provided as part of an SDK that was given to developers for free, and 3. beyond any sort of economic recovery by the license holder even if they weren't.

My experience in trying to contact companies for this kind of permission only results in frustration, because in 25-30 years there has been so much turnover at the company, or the company's IP/holdings have changed owners so many times, that most of the time you can't find anyone who understands what you're talking about or what you're trying to achieve. My personal criteria of whether or not it's worth the trouble is, for anything over 20 years old, see if said company's website still offers old drivers or manuals for download. Looking at Turtle Beach, they don't list the Multisound on their legacy support pages, let alone anywhere else on the entire website except for an About page and a company history page. So I'd personally have no qualm adding the sources, but then again I'm not an official steward of this code.

Complicating matters is that it's not all their code -- it's original DIGPAK sources too. At a bare minimum, anything that has mixed sources should at least publish the DIGPAK portions.

In my experience, trying to track down permission for releasing old source code is that the current intellectual property owners (nobody involved with the original companies) have no idea what you're talking about, and don't want to talk to you because it would involve their legal department or contracted legal firm, which costs them money for no finanical benefit to them... and you never hear back from them again after some initial contact. In my personal opinion, it's a waste of time.

Your final option depends on how much free time you have and how dedicated you are to the project: Clean-room a clone of the sources. Have someone else document everything the sources do in general terms, then take their description and write your own sources that implement the rules of the design document. Like before, I personally think that's a waste of time, but it absolves you of trying to seek permission while still getting workable drivers (eventually).

In the meantime, it is perfectly legal to distribute the assembled binary .COM files that were produced by the sources, so you might want to produce a repo release that contains them, just so there's an official place to get all of the original DIGPAK drivers.

It's a shame that the source code in question is for the devices that really need drivers: The uncommon and exotic cards.

BTW, in your FreeDOS post, you posit that all of the sound blaster drivers would have to be omitted. I think this is in error, since they likely provided John the same SDK sources they provded everybody. From 92-94 I worked for a Unix company and we wrote a driver for the Sound Blaster family, and we were provided text files and example C code, and didn't have to include any licensing messages or anything to Creative. They later released info and sources for free, so I really don't think you need to omit all of the Creative drivers.

@volkertb
Copy link
Collaborator

volkertb commented Nov 17, 2021

Your reasoning is solid. Thinking about it more, all the DIGPAK sources (namely driver code that John wrote himself) should definitely be fair to include in this release. And since that FreeDOS post, I have also come to realize that Sound Blaster programming SDKs and documentation have been publicly available for decades.

So in the case of Creative Labs, Media Vision, Turtle Beach and (Microsoft) Windows Sound System I think we're pretty much in the clear.

By the way, I just took another look in the DIGPAK sources that you initially shared, and the only files with copyright notices from Forte Technologies happen to be .INC files that contain only EQUs, defines and a few structs and a union definition. There's no actual source code in there, or at least no logic. Basically, these .INC files seem to be the UltraMID API, and like I mentioned earlier, including copyrighted APIs in an open source project was ruled to be fair use in the Google v. Oracle decision. The actual UltraMID sources don't seem to be part of the DIGPAK sources, so it was a bit excessive (and probably unenforceable) of Forte Technologies to add such a restriction to those .INC files. As for the actual DIGPAK driver sources for the GUS, it's clearly copyrighted by The Audio Solution, and includes the text "Written by John W. Ratcliff", just like the driver sources that John initially included when he initially published this repo on GitHub.

Other than Forte Technologies and The Audio Solution (a.k.a. John W. Ratcliff), the only other copyright notices that I could find in the DIGPAK sources (including the ones still missing from this repo) are from John Miles, who already gave permission and his full blessing to include any of his sources with this release, if you recall our email conversation with both Johns a while back. 🙂

So yeah, you're right. Let's include the missing driver sources in this repo. 👍

Looking forward to your PR. Thanks!

@galazwoj
Copy link

GUS sources have nothing special that cannot be found in the ultramid programmer's reference guide.
SB16 source has some codes related to DMA programming, but again, nothing that cannot be found elsewhere.
Turtle Beach is big, I haven't disassembled it yet so I cannot comment, but the file is a bit large (some data inside) so releasing its source code would save a lot of time

@volkertb
Copy link
Collaborator

@galazwoj Yeah, as I stated earlier above, I have been convinced to accept the addition of the missing sources (including GUS and Turtle Beach) to this repo. 🙂

@MobyGamer Can you create a PR as you offered in the opening post? I have a copy of your full distro myself, but if you create a PR first, then I'll be able to review it first, as an extra check to make sure we didn't leave anything out. Thanks!

@MobyGamer
Copy link
Contributor Author

Yes, I'll work on that tonight.

@volkertb
Copy link
Collaborator

Thanks! I added a comment to your PR. Please have a look if you can. Thanks. 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants