[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Opinions about packaging software that violates terms of third-party services as its sole function



Hi,

Bug #1110266 (ITP: pipe-viewer - lightweight YouTube client) just reminded me of this issue. I have no stake in that package and I'm sharing my concerns here firstly about the broader topic. I have doubts about the ethics of shipping software in Debian that is designed to intentionally infringe on the rights of third parties. I understand the sentiment that in Debian we don't like to police the software in the distribution too much, but copyright and terms of service issues deserve especially strong consideration: we want people to respect the licenses on works of our own authorship as well as for incorporated upstream projects, including copyleft ones, and also respect rules on access to our own services we provide.

It's fairly common for services designed for use with proprietary software ecosystems to prohibit unauthorized clients from using the service, as YouTube does: https://www.youtube.com/t/terms#xpointer(/html/body//ol[1]/li[1]) Consider this example of what it would look like if the tables were turned: if Google folks were to use accounts on Debian Salsa to host files and use us as their CDN for their products, and they perpetually made new accounts to evade timely detection, that would be seriously objectionable. The principle that you need the operator's consent to use a service is so ubiquitous that it hardly needs spoken, and like copyright, it deserves to be one of the fairly few standards we hold ourselves to in curating the distribution. To do otherwise is to give Google and friends new ideas on ways to infringe *our* rights and give them some standing to call it fair.

Furthermore, programs such as this usually don't inform the user that they are violating terms or inhibiting harmony on the internet. Users of Debian who want to watch YouTube with free software may think this is genuinely a good option that's reasonable to everyone when it isn't. Despite the myth turning up every now and again, giving users plausible deniability by shielding them from licensing terms that they'd otherwise knowingly infringe doesn't make things right. Even the packages in contrib or non-free that fetch files from the web at installation time generally prompt the user using Debconf when required so they know what can of worms they might be fetching.

The situation is often more gray with other packages. Despite the name, yt-dlp is not just concerned with YouTube but with many other sites and includes extractors for generic web pages. Also, yt-dlp expects to be given a link, one that a user presumably got from web browsing or using some service normally, where it's more easily justified to say that the user has had a chance to inform themselves on pertinent terms already.
Also, software such as GNOME Online Accounts is different too: it usually uses APIs from service providers that were designed for this use and with everyone's consent. I don't know of any reason to suspect that it infringes anyone's rights or terms.

For a self-proclaimed YouTube-dedicated application such as this, the facts seem cut and dry that this is a solid test case for the general issue. How does everyone feel about this?
I acknowledge and apologize for inhibiting contributions (including from new contributors) to free software here. Finding the courage for an uphill battle against a proprietary "ecosystem" is admirable. In an informal meritocracy with distributed leadership across many Debian Developers (a title I don't even hold myself), it's egregious to turn away contributions from folks willing and able to put in the work. In this case however, it is my wish that the Project will demonstrate its integrity and follow the golden rule—that we'll respect others' terms for use of their creations and resources, even if unfortunate for us, when we weren't entitled to such in the first place.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: