Open Source Isn’t a License to Take Everything

There is a difference between learning from someone’s work and having the right to use it.

That distinction matters more every day as AI-assisted filmmaking, game development, and collaborative creative platforms make it easier to build on what other people publish. The tools are becoming more accessible. The boundaries around the work those tools produce, however, are not always as straightforward as the interfaces make them appear.

Higgsfield’s Zephyr project offers a useful case study—not because it is an open-source production that everyone can freely repurpose, but because it demonstrates how a creative project can invite participation while still placing meaningful restrictions on what participants may do.

Runway Academy offers a complementary resource: practical instruction in AI-assisted game development, visual effects, and creative workflows.

Together, these examples help clarify a distinction that matters to our work at Loptr Lab: we can learn from tools and creative projects without surrendering our judgment, assuming rights we don’t have, or making our own work dependent on a single platform.

The first question isn’t “Can I remix it?”

It’s “What am I actually allowed to do?”

Zephyr is a cinematic science-fiction project published through Higgsfield. Its presentation invites people to engage with its world and experiment with creative remixes. That is an interesting model for participatory storytelling: a project becomes more than a finished piece of media. It becomes a starting point for further exploration.

But an invitation to participate is not the same as unrestricted permission.

The project’s OWL-NC-1.0 license establishes specific boundaries. In broad terms, it permits certain noncommercial activities, including study, teaching, research, tutorials, and community screenings. It also allows uses of licensed materials within Higgsfield’s platform to generate new imagery and video and extend the story, world, or characters, subject to the license’s terms.

There are important limitations. Commercial use requires separate permission. Attribution is required. The license restricts repackaging the materials as standalone asset packs, prompt packs, datasets, models, presets, or libraries. It also warns that rights involving third parties may not be fully cleared.

Anyone considering using the project should read the current license itself, rather than relying on a summary or an assumption about what “remixable” means.

This is not the same thing as an OSI-approved open-source software license. It governs a creative project and its associated materials, not simply source code under a standard software license.

That distinction is fundamental.

Open-source software, openly shared creative work, open-weight AI models, and public permission to reuse media are four different things. They can overlap, but none automatically implies the others.

A project can encourage experimentation without granting commercial rights. A model can have publicly available weights while its training data, outputs, or associated services raise separate questions. Software can be open source while the artwork created with it remains protected. And a publicly viewable image is not necessarily an image anyone may incorporate into a commercial production.

Accessibility is not ownership. Visibility is not permission.

Learn the craft without taking what isn’t ours

The most useful response to a project like Zephyr is not to ask how much of it we can extract. It is to study the decisions that make the project work.

How does it establish a recognizable visual identity? How does it communicate a world quickly? How do character silhouettes, environmental design, editing, camera movement, and sound contribute to a cinematic experience? How might a shared creative framework help people move from inspiration to experimentation?

These are questions about craft and production design. They do not require us to copy protected characters, lift proprietary assets, redistribute prompts, or build a derivative product from materials we have no right to reuse.

We can study the structure of a story without claiming its world. We can analyze a visual technique without taking its artwork. We can learn from a production workflow without assuming its assets are ours to distribute.

That is a more durable kind of creative literacy: understanding not just how to make something, but how to make something that we have the right to publish, share, and potentially sell.

Runway Academy: a practical resource, not our philosophy

Runway Academy belongs in this conversation because it teaches production skills that can be applied to real creative projects.

Its current course catalog includes three particularly relevant areas:

The courses provide a practical starting point for learning how these workflows operate. They can help a creator move from an abstract idea to a storyboard, a test shot, or a small production experiment.

That is valuable. We should learn from useful resources rather than dismiss a tool simply because it is proprietary.

But we should also understand the perspective of the source. Runway Academy is vendor-authored instruction for Runway’s own tools. It is not an independent comparison of every production method, a universal guide to creative rights, or proof that a proprietary workflow is the best long-term choice.

Our approach should be to learn the technique, test the result, and evaluate the dependency.

A tutorial can teach us how to generate a shot. It cannot, by itself, establish that every input is licensed for our intended use, that the resulting workflow is reproducible outside the platform, or that a commercial release is permitted.

That requires separate investigation.

For our purposes, I would prioritize the game-development and visual-effects courses first, then explore custom workflows if a multi-step process proves useful. There is no reason to treat completion of every course as a prerequisite or to purchase a subscription before identifying a task worth testing.

What this means for Return to the Void

In our own work on Return to the Void, the objective is not to reproduce somebody else’s science-fiction universe. It is to build a world with its own identity, its own rules, and a production path we can understand and maintain.

That starts with a practical question: What are we actually trying to deliver?

A cinematic proof of concept is not the same deliverable as a playable game. A convincing 60-to-90-second sequence can demonstrate atmosphere, visual direction, pacing, and storytelling. It does not, by itself, prove that the underlying game systems, interactions, environments, or production pipeline are complete.

We need to choose tools according to the deliverable, not the excitement surrounding a particular platform.

Option 1: Build the world in a game engine

Unreal Engine can serve as the foundation for real-time environments, camera work, lighting, animation, and gameplay. Blender can support original modeling, asset creation, animation, and scene preparation.

This path is attractive when the cinematic needs to grow into a playable experience. Work invested in the world can potentially serve both the film sequence and the game, instead of becoming disposable footage.

The trade-off is time. Building environments, characters, materials, lighting, and animation takes skill and iteration. A game engine does not eliminate production work; it gives that work a reusable structure.

Option 2: Use hosted AI video for targeted experiments

Hosted generators can help explore shots, motion, mood, and transitions quickly. They are useful when the immediate goal is to test a visual idea rather than build a persistent interactive world.

The costs may be modest at the proof-of-concept stage, depending on the provider’s current pricing, credit allowance, generation model, and the number of retries required.

But generated footage is not automatically consistent across shots. Character identity, continuity, camera logic, and the ability to reproduce a specific result all need attention. Subscription terms and commercial-use rights also need to be checked for the actual service and plan being used.

The sensible approach is to generate a short sequence, evaluate it, and decide whether it solves a real production problem before committing to a larger spend.

Option 3: Explore an open-model workflow

Tools such as ComfyUI can provide a visual workflow for working with image and video models. Selected open-weight models may offer more control over deployment and experimentation.

However, “open model” does not mean “everything is unrestricted.” Model weights, code, training data, dependencies, generated assets, and commercial-use conditions may each have different terms.

A workflow is only as reusable as its weakest licensing assumption. For each model and component, record the exact version, source, license, relevant restrictions, and any required attribution.

Cloud GPU rental can make experimentation possible without buying a workstation. Local hardware can provide more independence, but a new workstation can cost thousands of dollars.

Unless the existing computer demonstrably prevents progress, buying hardware before running a small test is difficult to justify.

The point is not to declare one tool universally superior. It is to match the tool to the job, understand the dependencies, and retain as much control over the finished work as the project requires.

The actual cost includes more than compute

The price of a generation subscription or a rented GPU is easy to see. The less visible costs often matter more.

Someone still has to develop the concept, design original characters and environments, select and revise shots, edit the sequence, create or license sound, test continuity, review accessibility, document the workflow, and verify rights.

Those hours are part of the budget whether they are paid to a contractor or supplied by the people building the project.

For Return to the Void, I would begin with a deliberately limited test:

This gives us evidence instead of a shopping list.

It also separates two decisions that are too often conflated: whether a visual approach is compelling, and whether the approach is sustainable for the project that must ultimately deliver it.

A spectacular test is not enough if it cannot be revised. An inexpensive workflow is not a bargain if its license blocks the intended release. And a beautiful cinematic is not a playable game.

We should know which problem we are solving before we spend money trying to solve it.

Open source is not one giant permission slip

The language surrounding AI and creative technology can make openness sound binary. Either something is open or it is closed; either it can be remixed or it cannot.

Real projects are more complicated.

Consider the different layers involved in a production:

These questions are related, but they are not interchangeable.

Even when a tool is open source, the content used with it may not be. Even when a creator encourages remixing, the permitted remix may be noncommercial or confined to a particular platform. And even when a license grants permission, third-party rights may remain unresolved.

This is why provenance matters. We need to know where our materials came from, which terms govern them, what changes we made, and what evidence supports our decision to use them.

For a serious creative project, that record is not bureaucratic overhead. It is part of the production infrastructure.

Teach the boundary, not just the tool

This is where the wider Loptr Lab training ecosystem has an opportunity.

A useful training resource should do more than explain which buttons to press. It should help people choose a production path, understand the consequences, document decisions, and recognize when they need additional rights or technical review.

A practical learning exercise can use Runway Academy to learn techniques while asking participants to:

The Zephyr reference can help teach the difference between a remix invitation and unrestricted reuse. Runway Academy can help teach production techniques. Neither replaces the learner’s responsibility to document their own choices.

The outcome should be original work with a transparent production record—not a collection of borrowed assets tied to one vendor.

This also makes the learning portable. The same habits apply whether someone later works with a proprietary video platform, a community-developed model, a game engine, a sound library, or a team of human collaborators.

Build original worlds. Make the process legible.

The creative technology landscape is changing quickly. Some tools will become cheaper. Others will disappear, change their terms, or move essential capabilities behind new subscriptions. Models will be replaced. Platforms will evolve.

A production built entirely around an opaque dependency may become difficult to reproduce or maintain. A production that records its sources, documents its decisions, and keeps its original assets organized has a better chance of surviving those changes.

This does not mean every component must be open source. Proprietary tools can be entirely reasonable choices. Nor does it mean that every project needs a complicated legal process before anyone can experiment.

It means the team should understand which choices are reversible, which dependencies matter, and which rights must be secured before release.

For Return to the Void, the goal is to develop an original creative world and a production process that can grow with it. For the training ecosystem, the goal is to make that process understandable to others. For the larger network of projects, the opportunity is to make exploration easier without making ownership, consent, or attribution an afterthought.

Zephyr gives us a concrete example of creative participation with boundaries. Runway Academy gives us a practical place to begin learning production techniques. Our job is to use both thoughtfully, test what works for our own objectives, and preserve the ability to make informed choices.

We do not need to cross someone else’s boundaries to learn from their work. We do not need to buy every tool to discover which workflow suits us. And we do not need to confuse openness with the absence of responsibility.

Learn openly. Build originally. Document honestly. Respect the rights that make creative work possible.

That is not a limitation on creativity. It is how we build something we can stand behind.

Further reading

Editorial note: Course availability, tool features, pricing, and license terms can change. Verify current terms, exact model versions, and commercial-use permissions before committing to production or distribution. This article is educational commentary, not legal advice.