Update xbox supports expressions for failing ports with copyleft licenses

[walbourn]

Open Source libraries that only offer 'copyleft' style licenses are not compatible with the Xbox developer agreement. Therefore, to avoid developer confusion this PR updates all ports that currently fail to build with the xbox triplet -AND- only offer a copyleft license to indicate they don't support xbox. In other words, there's no reason to "fix" these ports to support xbox given their current licensing model.

Package maintainers can update their ports in future to support xbox if they (a) modify the source to build with WINAPI_FAMILY, and (b) offer a license option compatible with the Xbox Developer Agreement (license: null if a commercial option is available, or adding an "OR" option with a permissive style license).

[dg0yt]

This PR pull a legal perspective in the supports field which carries a technical perspective. This seems inappropriate to me.

https://learn.microsoft.com/en-us/vcpkg/reference/vcpkg-json#supports

This field documents that a project is not expected to build or run successfully on certain platform configurations.

[walbourn]

This PR pull a legal perspective in the supports field which carries a technical perspective. This seems inappropriate to me.

https://learn.microsoft.com/en-us/vcpkg/reference/vcpkg-json#supports

This field documents that a project is not expected to build or run successfully on certain platform configurations.

A number of these ports do not build successfully for the Xbox platform as they are.

The key point is even if they do happen to technically build with the WINAPI_FAMILY_GAMES partition they still can never be used on the Xbox console in a shipping title. If they didn't build, there's no point in ever updating them to build in that scenario. Xbox developers are better served by knowing up-front that the library they are using--or more likely a library they are using has a dependency--that cannot be shipped in their title.

[dg0yt]

A number of these ports do not build successfully for the Xbox platform as they are.

This is normal for new platforms. Platform sub-sets (uwp, xbox) seem to make things worse.
What I would need technically is windows-desktop for desktop APIs, not a growing (!uwp & !xbox & !new-foo).

The key point is even if they do happen to technically build with the WINAPI_FAMILY_GAMES partition they still can never be used on the Xbox console in a shipping title

The same is true for iOS as long as you must ship via the App Store.
What I would need semantically is copyleft, not a growing (!xbox & !ios & !new-bar)

[walbourn]

This is 'low-hanging fruit' for excluding ports from consideration for xbox. Currently we assume that unless otherwise stated, a windows & x64 port is supported on Xbox. By removing ports that have 100% incompatible licenses (i.e. there is no circumstance where the developer can meet the requirements of the library's license) for consideration for Xbox, we narrow down the number of ports remaining to evaluate.

If we promote xbox from 'community' we'll likely want to flip the logic, and the more ports we have a firm answer on the better IMO.

[dg0yt]

This is 'low-hanging fruit' for excluding ports from consideration for xbox.

This is forcing rebuilds on all users, no matter if they care for xbox or not. This should only be done if it is meant to stay.

Low-hanging fruit is to add those ports to scripts/ci.baseline.txt, expecting that this is getting CI coverage.

Given that you already touch all those ports, you could cover the topic as well by a dependency on a meta-port platform-supports-copyleft. Then the condition only needs to be modeled and extended once in this single port. Doesn't even need a tool change.

[Neumann-A]

I agree with @dg0yt. Supports shouldn't be used to exclude platforms for "legal" reasons which might change over time. (since the list includes eigen3 I also think that xbox development currently is a big waste of human time which could otherwise be used to change the agreement ;) )
Furthermore, internal tools might be fine with whatever license since they are never shipped (and xbox is just a fancy name for a pc with fixed specs running some special OS/Firmware).
To add to this: the xbox triplets are not the only triplets with this problem it just happens to have a global filter with the license agreement. As such having a setting in the triplet to disallow certain licenses would make sense (VCPKG_DISALLOWED_LICENSES "<cmake list of disallowed spdx>") to allow to apply the setting on a triplet level instead of the port level. A current solution to the problem could be to use per port customization and FATAL_ERROR on certain ports giving a meaningful message to the user why it is a legal problem. Of course this requires changes to ci.baseline but this is certainly a better approach than to force a rebuild of nearly everything for all other users.

[Osyotr]

This will be hard to maintain.
What you really should do in this case is implement a switch for vcpkg-tool that does not allow building ports with copyleft licenses (except when explicitly allowed).

[walbourn]

I agree that we also need some better mechanism here, and I believe that we can implement that in the vcpkg tool based on the SPDX identifiers.

Note that of the 176 ports updated here, 124 of them fail for the Xbox triplets as they are. There's no sense in expecting these to add xbox support per the comments above, so they should be marked as not supporting xbox based on the build failures alone:

7zip  
arb  
atk  
atkmm  
aubio  
avisynthplus  
boinc  
bxzstr  
cairo  
cairomm  
cctag  
cgal  
chromaprint  
cserialport  
czmq  
discordcoreapi  
epsilon  
exiv2  
fluidsynth  
freealut  
freetds  
gdk-pixbuf  
gettext-libintl  
gettext  
glib  
glibmm  
glpk  
gmime  
gmp  
gppanel  
grantlee  
gst-rtsp-server  
gstreamer  
gtk  
gtkmm  
gul14  
hunspell  
ideviceinstaller  
idyntree  
igraph  
jsonifier  
kf5archive  
kfr  
lcm  
libadwaita  
libao  
libcsv  
libdatachannel  
libde265  
libdjinterop  
libfreenect2  
libheif  
libhsplasma  
libimobiledevice  
libirecovery  
libleidenalg  
libmariadb  
libmesh  
libmicrodns  
libmikmod  
libmodbus  
libmysql  
libnice  
libnice-gst  
libofx  
libpff  
libproxy  
libqcow  
libqglviewer  
libraw  
libsbml  
libsndfile  
libsrt  
libssh  
libunistring  
libusb-win32  
libxmp  
libzim  
live555  
mapnik  
marble  
mathgl  
mchehab-zbar  
moos-core  
mpfr  
mpg123  
nspr  
nss  
nuspell  
omniorb  
open62541  
openal-soft  
opencascade  
openmama  
openmvg  
openmvs  
openscap  
openslide  
openvdb  
osgearth  
pagmo2  
pango  
pangomm  
plib  
podofo  
poppler  
qcustomplot  
qscintilla  
qt-advanced-docking-system  
quazip  
restbed  
rubberband  
shiftmedia-libgnutls  
spatialite-tools  
usbmuxd  
wolftpm  
wt  
wxchartdir  
wxwidgets  
x264  
x265  
xapian  
xmlsec  
zeromq  

[walbourn]

Of the remaining 52 ports here that 'build' with WINAPI_FAMILY_GAMES, there are a number of them that simply never apply to the Xbox console platform (i.e. their function does not apply to the console or would never work due to the security model of the platform). In some cases, the libraries are 'header-only' meaning the build success is a false-positive in any case.

ableton  
ableton-link  
alpaka
chmlib
comms
cunit (supports only legacy versions of VC not supported for the platform)
faad2
jack2
libical
libjuice
libplist
librttopo
libusb
libusbmuxd 
mp3lame
sdl1 (legacy Direct3D not supported by platform)
unicorn (requires JIT)

For developer-only scenarios, these might be useful since they don't have to use them for their release build.

argtable2
argumentum  
check
getopt-win32

That just leaves the following ports as the only ones I'm actually removing purely based on the license:

cdt
eigen3
fann
fftw3
fluidlite
fuzzylite
geos
gsl
libdatrie
libexif
libgme
libkeyfinder
libmt32emu
libnoise
libsbsms
libsigcpp
libsmacker
mpir
ngspice
readosm
shiftmedia-libgcrypt
shiftmedia-libgpg-error
spectra
tag-lib
treehh
uchardet
vcglib
wildmidi
wolfmqtt
wolfssl
zziplib

For the ports in the last two categories, I could revert those particular port changes and we can pursue a more code-driven system for warning about the copyleft issue for those. The rest of the expression changes are all valid based on technical support considerations.

[JoergAtGithub]

I don't think this is the right approach:

• For many GPL libraries it's possible to buy a commercial license (like Qt)
• Also the Xbox developer agreement might change in future - how should we find out, if the !xbox was for technical or legal reasons?

[walbourn]

• For many GPL libraries it's possible to buy a commercial license (like Qt)

For license that have a null term or have multiple options where one of them is a non-copyleft license, I've made no changes. If you can find an example of such library in this list of modified ports, please let me know. Ideally they would have an "OR" clause in their license term or a null for clarity anyhow.

Note that any commercial licensing has to be handled on a case-by-case basis. The owner of the library would have to themselves sign the Xbox Developer Agreement with a Middleware Addendum.

• Also the Xbox developer agreement might change in future - how should we find out, if the !xbox was for technical or legal reasons?

The purpose of the xbox triplets to enable Xbox developers to consume open source in a way that is compatible with the platform easily and efficiently, as well as making it easier to track dependencies. It also allows package maintainers a way to validate their library for the xbox platform even without access to the Dev Kit. Right now about half the ~2000 packages will build for this platform.

Generally speaking, "permissive" open source licenses are totally fine, and that's most of the ports in VCPKG. This PR is focused on the ~1% that uses a "copyleft" license. A "strong copyleft" license is not compatible with a closed platform like Xbox or iOS or any other console from another manufacturers. That fact is not going to change. A "weak copyleft" license is in practice not compatible with closed platforms either as there's no way an end-user can rebuild and replace a LGPL DLL for these platforms. Marking these ports as not supporting xbox is because (a) they already fail to build for xbox, and (b) there's no point in trying to get them to build because they have incompatible licenses.

Overall, we are talking about a very small number of ports. If you look at them individually, you'll most of them don't apply anyhow. That said, my primary concern is that through the 'dependency cone' developers or package maintainers could end up consuming a 'copy left' licensed library indirectly for the xbox triplet would ultimately lead to problems for titles trying to use it.

[dg0yt]

AFAICS it is the same situation as with iOS (and maybe other fancyOS).

[walbourn]

I've rescoped this PR to just adding !xbox to all the ports that have COPYLEFT licenses AND fail to build with the xbox triplets.

I'm opening a distinct issue for the 'copyleft warning' issue generally. #31820

[walbourn]

@FrankXie05 This PR is no longer "bloated". It's updating the supports term for xbox for 124 ports that fail to build with that triplet, and there's no reason to expect they every will support xbox.

[JoergAtGithub]

For license that have a null term or have multiple options where one of them is a non-copyleft license, I've made no changes. If you can find an example of such library in this list of modified ports, please let me know.

You always have to ask the copyright owner(s), if he/they offer the code under other license. As for example ableton / ableton-link: https://github.com/Ableton/link#license

[walbourn]

@JoergAtGithub ableton / ableton-link wouldn't work on xbox anyhow since you can't just connect arbitrary devices to the system anyhow... FWIW.

[FrankXie05]

Convert this PR to draft.

[walbourn]

Convert this PR to draft.

@FrankXie05

I've addressed the concerns here about updating ports purely for licensing reasons. The port edits here are legitimate metadata changes to indicate these ports do not support the xbox platform in the supports expression.

All ports that need a 'to be discussed' solution were already reverted and a new tracking issued opened.

[walbourn]

Rebased to resolve conflicts. This is ready to submit.

All ports that are "copyleft" and do not fail to build with Xbox despite potential technical issues at runtime or legal concerns are unchanged in this PR and have been added to this tracking issue for future work. All ports updated in this PR are those that currently fail to build with WINAPI_FAMILY_GAMES.

[BillyONeal]

Convert this PR to draft.

Hmmm it isn't clear why this needed a response from @walbourn ? @FrankXie05 can you explain? :)

[FrankXie05]

Just pushing forward the progress of PR and resolving the conflict between PR and master. :)

[walbourn]

I didn't touch nettle but it's failing in the CI after a rebase.

[dg0yt]

I didn't touch nettle but it's failing in the CI after a rebase.

Source asset download error.

[walbourn]

Rebased again and everything builds.

[walbourn]

Rebased and resolved conficts again

[walbourn]

Rebased and resolved conflicts again

[BillyONeal]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[BillyONeal]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[BillyONeal]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).