Licence, author and copyright information unclear - SAA716x

[6by9]

I was going to pick up the drivers for TBS6284 and do a little clean up to them, with the thought of trying to upstream them. However none of the files in https://github.com/tbsdtv/linux_media/tree/latest/drivers/media/pci/saa716x declare a licence, copyright, or author, therefore doing so is legally a grey area. Those who did the work deserve the recognition.

The saa716x_budget module does declare the author to be Manu Abraham and GPL (no version specified), so can that be taken as gospel? Is he the copyright holder, or was he working for a company that hold the copyright? There does appear to be a dev tree at https://cvs.linuxtv.org/manu/saa716x_new.git/tree/linux and https://www.linuxtv.org/wiki/index.php/NXP_SAA716x#Saa7162.2FSaa7161.2FSaa7160_driver_development references him working on a GPL driver.

For what it's worth I have the card now running happily on a Raspberry Pi Compute Module 4. My in-progress branch is at https://github.com/6by9/linux/tree/rpi-5.10.y-tbs. I've trimmed it down to the saa716x cards where the demod and tuner are largely supported in mainline, and then started addressing the large number of checkpatch warnings.

Thanks

[crazycat69]

This old story. saa716x driver based on NXP reference design. Now this discontinued product, all attemps upstream saa716x driver was rejected (dirty code, license and etc)

[s-moch]

You can find a saa716x driver with lots of checkpatch cleanups, license information, and credit for all involved developers at https://github.com/s-moch/linux-saa716x . So far there is no support for TBS6284. I'm happy to include it if someone provides a proper patch.

[6by9]

Thank you both for your responses.

Upstream have their standards and expect them to be met. Yes it can be frustrating, but once merged the support burden is then placed on them when APIs change, and dealing with rubbish code is then their pain.

Licences are the legal contract and therefore have to be declared otherwise the code is useless. Legally I'd be unsure if any distribution could take this repo and ship the resulting modules, so users are forced to do the rebuild themselves.

@s-moch I'll have a look at your tree and see what I can do. I've read through your thread with Mauro and others at https://lore.kernel.org/linux-media/50e5ba3c-4e32-f2e4-7844-150eefdf71b5@web.de/. I share your frustrations. Based on that your focus seems to be on the FF cards, whereas I'm looking at the budget driver where all of the TBS cards fit. I'm assuming your saa716x-5.11 branch is the current one, rather than the for-media or for-media-v2 branches which you submitted upstream.

Whilst it is an old card, there are still a load of them kicking around out there. With the Pi CM4 now being out and exposing a PCIe slot, I'm just trying out cards to see what does and does not work, and then working to determine if it is limitations of the PCIe host, running on ARM, or the cards doing something odd. If the drivers work and are in a state that can be merged into the Pi kernel tree then it would be considered for the benefit of others (or people like LibreElec may consider it), but licencing/copyright issues prevent that.

Even for the more modern cards that use the tbsecp3 bridge, I note that https://github.com/tbsdtv/linux_media/blob/latest/drivers/media/pci/tbsecp3/tbsecp3-asi.c has no licence attributed to it, so that's a no-go either.

I do appreciate the amount of effort you put into supporting these drivers, but the current ambiguous licencing position blocks others being confident in making use of your work, or trying to assist in upstreaming it.

[s-moch]

Not sure if I got all your points.

There is no problem with my driver in meeting any technical upstream standards. Otherwise I would fix it. I think the only problem is the so called media maintainer. He does not understand the APIs he maintains (talking about the dvb output API here), and spreads FUD instead of doing his work properly. This of course only represents my personal opinion. If someone else wants to start another round of upstreaming discussion, I'm happy to take part in this.

There is no licensing problem with my driver whatsoever. Where do you see a problem? The driver is and always was licensed GPL-2.0+, and this also is declared in all source files. I have no idea what TBS in doing with this driver here, though. So maybe this is the wrong place to discuss this.

The default branch of my driver is always the branch of the latest mainline kernel. This also represents the current development state, if no -test branches are available in my repository.

[6by9]

Apologies @s-moch, most of my comments were over the code in this repository, not your branch.

I totally get what you're doing in retaining all the commit history from parent trees where available, but adding 369 patches to a downstream tree is going to be a right royal pain in the proverbial. Is it permitted to squash all the commits providing a source branch with the complete history is also maintained? Hmm.

I'll see if I can sort a clean patch for TBS6284 and create a PR for you.