First I'll reiterate what HDCP is and why supporting it cannot take away any freedoms. Then I'll give some background on Weston's ideology and justify supporting HDCP in Weston with both economical and technical arguments. While I do work for Collabora, these are my personal opinions.

HDCP

HDCP is a specification with multiple versions (e.g. HDCP 2.2) which among other things define encryption of the video data going through some standard cables like HDMI. The aim of HDCP is to authenticate the video sink (e.g. a monitor or a TV) with the hopes that an authenticated sink cannot leak the video content where it is not intended. At least, that is the theory. HDCP is essentially a hardware feature. You flip a switch in hardware and it attempts to enable HDCP secured link with the video sink devices. The hardware tells you if it succeeded or not. That is all. There is no change at all in how software (e.g. Weston) will drive the display.

As already explained by Daniel Stone a long time ago, supporting HDCP in a free open-source software (FOSS) project cannot take any user rights or freedoms away. It cannot restrict what you can do. It is just a way to make use of a hardware feature when you choose to do so. Otherwise it will just sit there doing nothing.

Only if your whole operating system (OS) has already been locked down and left you outside, only then could HDCP actually enforce someone else's policy of Digital Rights Management onto you against your will. On the other hand, you could lock down your own OS according to your own policies to prevent others from stealing your content. Want to lend a laptop to someone to watch some animations you made, for instance? Maybe a professional photographer wants to let people watch the drafts in their own TV without fear of them stealing all the pictures? These are examples I made up.

The Wayland protocol extension for HDCP is also very simple: the client (application) tells the compositor that it wants its content protected, and the compositor replies yes or no. The compositor is completely free to lie about protection, and there is no way for the client to know it was lied to. Both the HDCP design in general and the Wayland protocol extension presume the compositor (display server) is trusted.

HDCP support in Weston gives you the freedom to enable it if you want it.

Weston's ideology

Weston's license is MIT. Why is it not GPL or LGPL?

I was not participating in the project yet when the license was chosen, but I agree with it. I, with my upstream Weston maintainer hat on, want Weston to be used by companies, including in their shipping products. MIT license makes that very easy for the companies. GNU GPL or LGPL could make it hard, especially GPL v3+ which many companies just steer very clear of. This is the reality outside of our control, however sad you might think it is. Forced with a trade-off not unique to the Weston project, it chose to favour adoption over strong copyleft, as did other open source projects before, Xorg and Mesa for example.

When Weston is used in shipping products, it is much more likely that companies will provide resources to improve Weston also in upstream. Even if companies did not directly do that, they might hire others like Collabora to work on Weston, and then Collabora can redirect some of that revenue back to Weston upstream development. That will likely benefit also other users of Weston, even the private home users and hobbyists. It is all the same reasons why hardware drivers should go into the Linux kernel upstream, just in much smaller scale.

The above paragraph is not speculation. It is happening, and it has already allowed significant investments from e.g. Collabora into Weston upstream over the past years.

HDCP support in Weston is but one more reason to consider using Weston in shipping products. It is indeed unlikely that HDCP support would be useful under a normal FOSS OS. HDCP support is there to attract more resources around Weston to hopefully benefit everyone. Who knows, maybe someone will figure out a use for HDCP that does not involve attempting to enforce the Digital Rights Management policies of major media companies.

Technical reasons

Weston is a reference Wayland compositor. As such, it is used to test and prove new technologies, ideas, protocol extensions, APIs, and so on. Some of that is downstream forks only, some of it ends up in Weston upstream.

Above the upstreaming of a hardware driver into the Linux kernel was mentioned as a highly desireable thing from both user and vendor perspectives. Sometimes the hardware has features that the existing kernel-userspace programming interfaces (UAPI) do not support. In that case, new UAPI must be introduced. HDCP 2.2 is a feature that requires a small UAPI addition.

The problem with UAPI is that once it has been released with a Linux kernel and programs using that UAPI have appeared, it cannot be broken or removed. Ever. The kernel has an extremely strict policy on this: if upgrading the kernel breaks a program, the kernel is at fault. It does not matter if the program is misusing the kernel, works by luck, or is plain incorrect in its UAPI usage, but the program used to work and then it does not work anymore, the kernel is at fault. This makes it really important to get UAPI as right as possible from the start, as it will be a maintenance cost forevermore.

Therefore the Linux Direct Rendering Manager (DRM) subsystem has a rule: all new UAPI must come with real userspace consumers. A test program is not enough.

Weston can be used to prove the suitability of new Linux UAPI. This is a big part of why HDCP support is coming to Weston. The HDCP support reviews with Weston have already induced changes to the proposed UAPI by asking for an event for HDCP status changes.

Weston is also a Wayland compositor where one can implement and prove Wayland protocol extensions, similar to how one proves Linux UAPI. The HDCP support comes with a Wayland protocol extension, so that Wayland clients (end user applications) could make use of HDCP. One can even argue that proving the Linux UAPI for HDCP will not be complete without the Wayland protocol extension, because a display server cannot guess which content actually needs protection and Wayland is here now with some fundamental differences compared to e.g. X11 protocol.

Conclusion

By the release of Weston 7.0.0, the Wayland protocol extension support for HDCP has alrady landed in Weston upstream, but the HDCP UAPI usage has not. This means that while Weston 7.0.0 is internally prepared to handle protected content, the DRM-backend will not yet attempt to actually enable HDCP in hardware. The remaining patches were tracked in Weston MR 48 and have landed post 7.0.0 release.

HDCP support in Weston cannot take away anyone's freedoms. It does not allow building Digital Rights Managed video players that could reliably work against your will on your desktop, you can simply hack Weston to lie to them. You could even make the lying a feature and submit it to Weston upstream, if it meets the code quality requirements it will get merged. HDCP support adds the freedom to turn on HDCP encryption if you want to.

Technical and economical reasons are the major points why HDCP support is coming to Weston. Making Weston more attractive to companies will provide more resources to Weston upstream work that will benefit everyone in the long run.

It is true, that this work is adding features and protocol that could be used in non-free shipping products that are designed to restrict users' capabilities. Specifically supporting technologies that are used in Digital Rights Management could be seen as endorsement, even though it has no such intent. However, such non-free products are going to be made with or without Weston's support, and I think in this case the benefits to the Weston project outweigh the negative impact.