Add build workflow

[erodozer]

Introduces a build workflow for github that builds the extension for supported targets and packages an artifact for easy distribution.

[erodozer]

Example run of the workflow can be seen at https://github.com/erodozer/gd_cubism/actions/runs/13776481923

It's important to note that Artifacts on github expire after 30 days. It's recommended to take built artifacts and push them to a proper release when tagging commits.

[MizunagiKB]

Your proposed approach and method are excellent.

However, if the build output results in a new library rather than an application, it would violate Live2D's terms and conditions.

The primary reason is that obtaining the Live2D Cubism SDK requires agreeing to Live2D's Software License Agreement.

Software License Agreement
https://www.live2d.com/en/sdk/download/native/

If I were to provide the binaries, it would create a means to access the SDK without reviewing the license agreement.

Regarding the license, I have inquired on the Live2D Creators Forum about the acceptable distribution methods, and it was confirmed that providing it in source form is the least problematic approach. Please see the discussion here for reference:

Live2D Craeters forum
https://creatorsforum.live2d.com/t/topic/1942/2

This is likely due to the fact that the core components of Live2D are proprietary software rather than open-source, which is understandable.
However, I aim to ensure that individuals interested in GDCubism do not unknowingly violate these terms.

I am not an expert in legal matters, but the method you proposed might be acceptable if it is executed in a private repository.

[erodozer]

Thank you for this link to the forums. I was uncertain if this would be in violation to the license as I had my worries with this case.

The problem appears to be that there's several licenses at work, particularly with the Framework's component license is separate from the Core SDK.

Do you think it would be safer legally if the extension's could be changed to rely on linking to shared libraries as opposed to compiling it all into file? That way we could set up the runner to build the extension, and possibly the open framework components, then we ask that users to supply their own copy of the Core libs after accepting the license.

---

I could also change the workflow to only operate on manual dispatch, with the expectation being that you'll never run it on the public repo. I think that would be helpful for people, as they could fork the project for private purposes and have a workflow that they can use to generate binaries for themselves.

[MizunagiKB]

Rather than the technical implementation, I consider the process required to obtain the Cubism SDK for Native to be a challenge when constructing workflows.

Specifically, the following steps:

1. Users must first read the terms and conditions.
2. If they agree, they must check a box to confirm their acceptance.
3. Only then are they permitted to download the SDK.

This process might be due to the design of Live2D's website. However, since the procedure ensures users agree to the terms before obtaining the SDK, I want to make sure to uphold this practice.

In this case, the issue lies in directly obtaining the SDK using curl. This creates a bypass route where the terms and conditions are not read. Personally, I believe that accessing locations where addresses are not publicly disclosed by design is not appropriate.

Your proposal effectively addresses the following:

• Preventing build errors for committed code by running the build.
• Offering a new way for GDCubism users to obtain the necessary libraries.

I fully understand the value of your suggestion, and you might wonder why I am hesitant to implement it despite recognizing its benefits.

The reason is that, as GDCubism has been introduced on the official website and shared on X(Twitter), I want to ensure that users who follow our workflow do not inadvertently violate the terms and conditions.

---

If it is not inconvenient for you, I believe this pull request could provide others with an opportunity to learn about both the proposed methods and the challenges related to licensing. Therefore, it might be a good idea to leave it open for now (or perhaps revise the documentation to include this information?).

By not closing it, we will also have the flexibility to continue the discussion seamlessly if there are any changes to the situation in the future.

[erodozer]

I fully understand your concerns regarding the complexities of the needing to deal with multiple restrictive licenses in a single project. Which is why I'm proposing seeing if it's possible to take an approach that leverages using dynamic linking to shared libraries. That would keep the binaries separate and full acquisition up to the user after they agree to licensing terms, while gd_cubism could supply binaries of just the godot binding.

The gdextension definition would require adding a dependencies section, ie.

[configuration]

entry_symbol = "gd_cubism_library_init"
compatibility_minimum = 4.3

[libraries]
linux.debug.x86_64 = "bin/libgd_cubism.linux.debug.x86_64.so"
linux.release.x86_64 = "bin/libgd_cubism.linux.release.x86_64.so"

[dependencies]
linux.debug = {
  "lib/libLive2DCubismCore.so":"",
  "lib/libCubismNativeFramework.so":""
}
linux.release = {
  "lib/libLive2DCubismCore.so":"",
  "lib/libCubismNativeFramework.so":""
}

We can also still keep the build workflow as is purely for build testing and simply disable publishing artifacts so there's nothing being distributed.

[MizunagiKB]

By dynamically linking the Cubism SDK for Native, the following can be achieved:

• Users are not required to build the SDK locally.
• The SDK itself must be downloaded directly from Live2D.

Since Live2D already provides support for dynamic linking, this approach is worth considering. While it remains uncertain whether distribution in this format is feasible, offering it as a build option would expand the available choices.

Regarding another workflow, I have concluded that it would be difficult to integrate it into the repository. This is because Live2D SDK download page requires users to read and accept the terms of the “Live2D Proprietary Software License Agreement” and the “Live2D Open Software License Agreement” before downloading.

This requirement is explicitly stated at the top of their website, as follows:

To download, please read and agree to the “Live2D Proprietary Software License Agreement” and “Live2D Open Software License Agreement.”

https://www.live2d.com/en/sdk/download/native/

This requirement creates the impression that there are limitations in the process of acquiring the SDK, even before executing the workflow.

Although similar procedures exist for other tools and may be implicitly accepted, it is possible that the designer of the website did not consider these implications thoroughly.

In general, SDKs gain value through their usability, and it is unlikely that a more restrictive approach would be intentionally taken. However, the Live2D SDK appears to be primarily designed for corporate use while still being accessible to individuals for experimentation.

Currently, the lack of a workflow does not present an insurmountable problem.

While this situation may cause minor inconveniences for everyone involved, I have decided not to implement a workflow for my repository at this point.

[MizunagiKB]

I have posted on the Live2D Creators Forum regarding the possibility of distributing pre-built binaries that require a separate DLL.

• https://creatorsforum.live2d.com/t/topic/3414
• (The site is in Japanese.)

In my opinion, enabling functionality simply by placing the DLL could allow more people to enjoy Live2D with Godot Engine. However, from a corporate perspective, this may make control more challenging, so the response itself might be difficult.

I will update this post if any replies are received.

[erodozer]

The response in the forum thread sounds positive towards using the dynamic linking approach as long as GDCubism adds a stipulation in its README with regards to accepting the Live2D terms. This is great, as it'll make distributing much easier, and also speeds up build times for the extension.

Once #153 is merged I'll update this PR to create artifacts of just the GDCubism binaries without the Core dll.

[MizunagiKB]

The response from Live2D exceeded my expectations. I perceive their reply as highly beneficial not only for GDCubism but also for those seeking to integrate Cubism SDK for Native.

I considered mentioning the build workflow as well, but I felt that introducing various conditions might complicate decision-making. Therefore, on the forum, I limited my inquiry to distribution methods.

That said, I am planning to provide binaries moving forward and will reconsider the method of building within a private repository. The reason for this is that although I am able to build for macOS, Windows, and Linux on my end, maintaining a completely clean environment has proven to be quite difficult.

Regarding the workflow, I am planning to prepare a dedicated build repository. Based on the workflow you proposed in your pull request, it seems feasible to set up an independent build workflow.

For example, the workflow could follow these steps:

1. Create a new private repository.
2. Review Live2D's terms and obtain the SDK ZIP file.
3. Add the SDK ZIP file to the private repository.
4. Clone the GDCubism repository and extract the ZIP file into the appropriate location.
5. Execute the workflow.
6. Retrieve the build results.
7. Delete the private repository, if deemed unnecessary.

Using a private repository would ensure compliance with the terms of obtaining and using the SDK for personal purposes. Additionally, it would address my concerns regarding direct downloading of the ZIP file.

Since you have already discussed the method of using private repositories, this might seem redundant at this point. I sincerely apologize for my roundabout approach to this matter.