The Evolution of Open-Source Forks: Navigating Licensing, Architecture, and Community Dynamics

The Origin of the Divergence

WaEnhancer (Wae), maintained by Dev4Mod, evolved toward a Kotlin-based codebase as part of its ongoing modernization. Kotlin is the officially recommended language for Android development and offers null safety, coroutines, and concise syntax.

WaEnhancerX (WAEX), maintained by mubashardev, took the opposite position. Rather than following the upstream migration to Kotlin, mubashardev made the deliberate, documented architectural decision to maintain a 100% pure-Java core - and formally detached the repository from the upstream network to pursue this direction independently.

The Technical Case for Pure Java in LSPosed Hooking

An Xposed/LSPosed hook is fundamentally a Java Reflection API operation. The module locates a target method inside the host application's process by its class name, method name, and parameter type array, then registers a callback that intercepts that method's execution at runtime. This mechanism - XposedHelpers.findAndHookMethod - operates entirely on raw JVM primitives.

Kotlin's compiler introduces several compiler-generated artifacts that complicate this context:

• Null-check intrinsics: Every non-null parameter in a Kotlin function generates a call to kotlin.jvm.internal.Intrinsics.checkNotNullParameter. In hook callbacks invoked on high-frequency WhatsApp UI render loops, this overhead is measurable and cumulative.
• Primitive type ambiguity: Boolean::class.javaPrimitiveType can resolve to null, causing hooks to fail silently. Java's boolean.class remains completely unambiguous.
• Metadata overhead: Kotlin embeds a binary @Metadata annotation into every compiled class, which is dead weight inside an LSPosed process using java.lang.reflect.* exclusively.

XposedHelpers.findAndHookMethod(
  "com.whatsapp.messaging.a",
  lpparam.classLoader,
  "b",
  Boolean::class.javaPrimitiveType, // Can resolve to null
  object : XC_MethodHook() {
    override fun beforeHookedMethod(param: MethodHookParam?) {
      // Kotlin inserts Intrinsics.checkNotNullParameter
      val readFlag = param?.args?.get(0) as? Boolean ?: return
    }
  }
)

XposedHelpers.findAndHookMethod(
  "com.whatsapp.messaging.a",
  lpparam.classLoader,
  "b",
  boolean.class, // Direct and explicit primitive
  new XC_MethodHook() {
    @Override
    protected void beforeHookedMethod(MethodHookParam param) {
      boolean readFlag = (boolean) param.args[0]; // Predictable execution
    }
  }
)

The Specific Question of Language Ports

When a developer translates an algorithm or architectural pattern from Kotlin to Java - preserving the functional behavior while rewriting the syntax, restructuring for idiomatic Java patterns, and adapting calling conventions - the question of authorship becomes complex. The conceptual logic may originate with the upstream author. The actual bytecode, class structure, and implementation are new artifacts.

Commit-level co-authorship is a Git convention rather than a GPL requirement. Adding a co-author to a commit is a courtesy practice in collaborative development, typically used when two developers worked on the same change in the same session. Applying it retroactively to translated logic in a separate, independently managed repository raises practical complications.

mubashardev's documented approach - providing prominent attribution in WAEX's README and internal credits, explicitly acknowledging Dev4Mod and WaEnhancer as the source of the foundational logic - represents standard practice for derivative ports in the GPL ecosystem and fully satisfies the GPL's actual requirements.