the VMProtect SDK EULA doesn’t look like a permissive open-source license.. why are you repackaging it?

why are you bundling ".idea" in the release files?

the VMProtect SDK EULA doesn’t look like a permissive open-source license.. why are you repackaging it?

why are you bundling ".idea" in the release files?

VMprotect SDK is open source and available to everyone. I make port for convince of it integration. I store .idea folder in repository to make it easier for other developer to maintain it and complying with code style. VMprotect sdk also available in Rust and Go language package managers. Its time to bring it into vpckg.

VMprotect has not free license but it's only applies only on product itself not on sdk.

VMprotect sdk also available in Rust and Go language package managers. Its time to bring it into vpckg.

upstream EULA clearly defines the product as commercial with redistribution restrictions. it is not an OSI-approved open-source license and does not allow packaging/distribution as vcpkg does. please provide a valid SPDX-compatible license text!

I store .idea folder in repository to make it easier for other developer to maintain it and complying with code style.

in vcpkg, the port’s directory is expected to reflect the upstream source and the port recipe, not arbitrary local IDE environment data. keeping .idea in the port polls the repo with irrelevant files that don’t contribute anything the package manager needs; invites noise/conflicts in diffs and builds, and isn’t portable to users who don’t use that IDE..

upstream EULA clearly defines the product as commercial with redistribution restrictions. it is not an OSI-approved open-source license and does not allow packaging/distribution as vcpkg does. please provide a valid SPDX-compatible license text!

its my own realization of VMprotect SDK, so its not part of VMprotect product that can be restricted by EULA

its my own realization of VMprotect SDK, so its not part of VMprotect product that can be restricted by EULA

even if you personally wrote code that wraps or re-exposes the SDK, the SDK you’re packaging still depends on the upstream binaries/documents that are governed by that EULA. packaging/redistributing those artifacts in vcpkg implies you’re redistributing VMProtect’s commercial software under terms it doesn’t allow. the rights granted by a proprietary EULA don’t magically become open source just because someone wrote a shim around them - redistributing the underlying proprietary bits is still restricted

not a lawyer btw, just expressing my concerns

its my own realization of VMprotect SDK, so its not part of VMprotect product that can be restricted by EULA

even if you personally wrote code that wraps or re-exposes the SDK, the SDK you’re packaging still depends on the upstream binaries/documents that are governed by that EULA. packaging/redistributing those artifacts in vcpkg implies you’re redistributing VMProtect’s commercial software under terms it doesn’t allow. the rights granted by a proprietary EULA don’t magically become open source just because someone wrote a shim around them - redistributing the underlying proprietary bits is still restricted

not a lawyer btw, just expressing my concerns

It does not contain any vmprotect binaries and only rely on source of vmprotct-sdk repository itself. VMProtect only insert own code instead these markers when you protect a binary file. vmprotect-sdk do NOT include any .lib .dll files that bundled with vmprotect and could not be applied as a parts of vmprotect.

packaging/redistributing those artifacts in vcpkg implies you’re redistributing VMProtect’s commercial software under terms it doesn’t allow.

This package doesn't distribute any parts of commercial software because this is a different implementation of the VMProtect's SDK (only the library names match).

The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.

I dont think this is fullfilled here. So the port name probably needs changing.

The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.

I dont think this is fullfilled here. So the port name probably needs changing.

I think name fits perfectly and it doesn't conflict with anything

The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.

I dont think this is fullfilled here. So the port name probably needs changing.

Aw here we go for [orange-vmprotect-sdk] at that case? Although target and namespace would keep find_package(vmprotect_sdk CONFIG REQUIRED) vmprotect_sdk::vmprotect_sdk I suppose?

orange-vmprotect-sdk

lets wait for what official vcpkg will say. Frankly i think to just leave it as vmprotect-sdk, its just more clear

Thank you for clarification.

another concern I'm willing to raise is the state of the CMakeLists in the upstream - for no apparent reason it seems to require C++26??

+1 for orange-vmprotect-sdk. the name vmprotect-sdk may cause confusion in regards to ownership and status of the port

upstream EULA clearly defines the product as commercial with redistribution restrictions. it is not an OSI-approved open-source license and does not allow packaging/distribution as vcpkg does. please provide a valid SPDX-compatible license text!

vcpkg does not make license restrictions on what is in our registry so long the license restrictions themselves do not forbid it.

@orange-cpp can you be specific about how your repo is different than the ones in the DMCA takedown notice here? https://github.com/github/dmca/blob/master/2025/05/2025-05-13-vmprotect.md

@vmpsoft

This package doesn't distribute any parts of commercial software because this is a different implementation of the VMProtect's SDK (only the library names match).

Are you saying that you are the source of that DMCA takedown and that you believe @orange-cpp 's repo is unaffected?

The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.

I dont think this is fullfilled here. So the port name probably needs changing.

I think name fits perfectly and it doesn't conflict with anything

Unfortunately I think we need orange-vmprotect-sdk or something like that as this isn't on repology and search gives me several conflicting targets:

• https://github.com/MainLibraries/VmProtect-GO/blob/main/VMProtectSDK.h
• https://deepwiki.com/yumieiko/vmprotect/5-software-development-kit which points to https://github.com/yumieiko/vmprotect/blob/8e462f20/sdk/VMProtectSDK.h#L79-L98 which is where I found out about the above takedown notice
• https://github.com/Cystemzz/vmprotect-go

and so on. (I know some of those are explicitly for go but they seem to have C++ headers)

Unfortunately I think we need orange-vmprotect-sdk or something like that as this isn't on repology and search gives me several conflicting targets

If there's an official ACK from the owners of https://vmpsoft.com/ that this is what they want associated with their name I think that would also be sufficient.

@luadebug

Aw here we go for [orange-vmprotect-sdk] at that case? Although target and namespace would keep find_package(vmprotect_sdk CONFIG REQUIRED) vmprotect_sdk::vmprotect_sdk I suppose?

In general we are only sticklers about the name of the port, rather than symbols, CMake configs, or headers because that's the bit we basically can't ever change to mean something else. (We do have to remove things if there are actual conflicts but we aren't sticklers about hypothetical future conflicts outside of the port's name)

Unfortunately I think we need orange-vmprotect-sdk or something like that as this isn't on repology and search gives me several conflicting targets

If there's an official ACK from the owners of https://vmpsoft.com/ that this is what they want associated with their name I think that would also be sufficient.

Okay i will rename it, thx.

upstream EULA clearly defines the product as commercial with redistribution restrictions. it is not an OSI-approved open-source license and does not allow packaging/distribution as vcpkg does. please provide a valid SPDX-compatible license text!

vcpkg does not make license restrictions on what is in our registry so long the license restrictions themselves do not forbid it.

@orange-cpp can you be specific about how your repo is different than the ones in the DMCA takedown notice here? https://github.com/github/dmca/blob/master/2025/05/2025-05-13-vmprotect.md

@vmpsoft

This package doesn't distribute any parts of commercial software because this is a different implementation of the VMProtect's SDK (only the library names match).

Are you saying that you are the source of that DMCA takedown and that you believe @orange-cpp 's repo is unaffected?

The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.

I dont think this is fullfilled here. So the port name probably needs changing.

I think name fits perfectly and it doesn't conflict with anything

Unfortunately I think we need orange-vmprotect-sdk or something like that as this isn't on repology and search gives me several conflicting targets:

• https://github.com/MainLibraries/VmProtect-GO/blob/main/VMProtectSDK.h
• https://deepwiki.com/yumieiko/vmprotect/5-software-development-kit which points to https://github.com/yumieiko/vmprotect/blob/8e462f20/sdk/VMProtectSDK.h#L79-L98 which is where I found out about the above takedown notice
• https://github.com/Cystemzz/vmprotect-go

and so on. (I know some of those are explicitly for go but they seem to have C++ headers)

As vmpsoft said, my sdk realization is written by myself, so its not part of VMprotect and it doesn't not contain initial VMprotect source code and cannot be DMCA'ed. Only function names match for compatibility. These DMCA was initiated because repositories leaked VMprotect original source codes.

@BillyONeal renamed port to orange-vmprotect-sdk, now we should be good to merge 👍🏻

my sdk realization is written by myself, so its not part of VMprotect and it doesn't not contain initial VMprotect source code

Ah, in that case that confirms it and also says even more strongly that it shouldn't take vmprotect's name (in case @vmpsoft would ever decide to use that name themselves as it seems pretty unambiguously "owned" by them)

my sdk realization is written by myself, so its not part of VMprotect and it doesn't not contain initial VMprotect source code

Ah, in that case that confirms it and also says even more strongly that it shouldn't take vmprotect's name (in case @vmpsoft would ever decide to use that name themselves as it seems pretty unambiguously "owned" by them)

So does orange-vmprotect-sdk as a name is okay?

my sdk realization is written by myself, so its not part of VMprotect and it doesn't not contain initial VMprotect source code

Ah, in that case that confirms it and also says even more strongly that it shouldn't take vmprotect's name (in case @vmpsoft would ever decide to use that name themselves as it seems pretty unambiguously "owned" by them)

Thx you!