RAD Game Tools License Concern - Immediate Action Required

[Deledrius]

Hi Adam,

You are where I was this morning, until I got a further explanation. What I did not realize was whoever at Cyan wrote plLayerBink.cpp had copied the code nearly verbatim from the RAD Tools SDK sample code. And that is what is in violation of Cyan's agreement with RAD Tools. Which carries *very* substantial penalties that Cyan Worlds would have to pay. Substantial enough to put Cyan in dire straits.

Please, to me this seems like a very small request to remove this file in face of the enormity of the situation.

Thanks for your understanding.
Mark

Thanks for the explanation, Chogon. It seems so silly that RAD would threaten you at all over the usage of sample code, but that is their right. It's definitely going to be easier to remove it quickly and then work around it than any of the nastier alternatives.

I've removed the file from my fork's history and all branches on github, and since my bitbucket fork was unused, I deleted it entirely and will re-fork if I ever need it again from OU's master.

[rarified]

Shouldn't this be restricted too? http://foundry.openuru.org/hg/CWE-ou-minkata

Yes, I commented out the wrong access line. "Fixed"

_R

[Lyrositor]

We have found a technique to remove the file from our Git repos while keeping in sync with each other (so long as everyone executes the same command).
We'll make a script soon to automate this.

In the meantime, I've fixed all my Git repos, and hidden my Bitbucket ones while I wait for a recommended fix. I've also stopped distributing binaries compiled with the old sources, so as to not violate the GPL.

rarified, could you hide my Foundry builds? There are a few successful builds in there, and the output binary doesn't match any public source anymore. I don't want to violate the GPL.

[rarified]

rarified, could you hide my Foundry builds? There are a few successful builds in there, and the output binary doesn't match any public source anymore. I don't want to violate the GPL.

I'll just purge your historical build artifacts. When we get things mapped back correctly the only accessible artifacts will be from future builds.

_R

[Annabelle]

I'll just purge your historical build artifacts. When we get things mapped back correctly the only accessible artifacts will be from future builds.

_R

I don't quite understand everything going on today... but these sentences stated by rarified are worst to me than a horror movie... Do I have the right "frightful" sensation? If there's no looking back just looking ahead, we are loosing something isn't it?

[Mac_Fife]

Not really, Annabelle. What rarified is talking about here is the output from the Foundry's build engine, which depends on which version of source code the developer feeds into into it. There are limitations that arise out of the RAD Game Tools issue, but that could be an old version, a new version, a partially complete trial version, etc., depending on what the developer is trying to do at that point. The output is essentially "transient" and if the developer gets a build that they're happy with they'll likely move it to somewhere more permanent for "release". I gather from Lyrositor's post that there's some meaningless cruft lying around from old builds, so "future" here means "related to any builds you do in the future", rather than implying that the code can only ever be moving forward.

[JWPlatt]

Mac beat me to a reply (drat those time zones!), but mine takes a different slant to provide some background and head off a different question:

Removal of the plLayerBink.cpp file will not impact any functionality of the CWE client because Bink functionality had already been removed before CWE was released for open source.

The Software Development Kit (SDK) used in Cyan World's Plasma client code to play the Bink video file format in all incarnations of Uru Live is licensed to Cyan Worlds by RAD Game Tools. There are two Bink videos in MOULa. They are the Cyan logo video and the Yeesha intro video ("The tree... remains"). The Bink SDK was not released with open source and that is why the Cyan Worlds Engine (CWE, nee Plasma) clients cannot play Bink videos. Therefor, neither the Cyan logo nor the Yeesha video play when you start the client.

As Chogon says, "whoever at Cyan wrote plLayerBink.cpp had copied the code nearly verbatim from the RAD Tools SDK sample code." That is okay within Cyan Worlds because they are licensed to use it. It is not okay for open source because Cyan Worlds is not licensed to redistribute the SDK to others. Anyone who uses any portion of the SDK must license it from RAD Game Tools. Other code within the CWE client that conditionally compiles the Bink SDK if it is present on the build system is also okay because Cyan Worlds developed that code - not RAD Game Tools. The conditional compiler directives were added by community developers so the client would compile without the SDK. The problem exists because that copied sample code was redistributed with open source. It was only when RAD Game Tools compared the open source code to their SDK that one file, plLayerBink.cpp, was found to be mostly a copy.

What must happen now is for the existing code to get patched around the absence of plLayerBink.cpp, or rewrite the code in that file to be free of any RAD Game Tools source.

This event could be turned into an opportunity to get some movement on a replacement library for Bink videos. There exists an open source alternative in the FFmpeg/libavcodec library that would allow the CWE client to once again play Bink videos. This would be an asset because Bink videos can be played on any Plasma surface in the game.

[Christian Walther]

I have taken down my Bitbucket and GitHub repositories for the time being. (At least on GitHub, commits are still reachable by their hashes however, that will probably continue until all forks have released their references and GitHub has done a garbage collection.)

When doing the rebasing, we need to be careful that we all end up with the same result, in particular where there was a correspondence between Mercurial commits and Git commits (via hg-git), it should again exist in the new repositories. It looks like on the Git side, Deledrius’ version has been chosen as the canonical one (not Hoikas’)? Maybe the easiest option is to start from there and take everything over to Mercurial, since Git generally does better at history rewriting anyway. I’ll take a closer look at what has been done when I have more time.

[rarified]

but these sentences stated by rarified are worst to me than a horror movie... Do I have the right "frightful" sensation?

Sorry, Annabelle. I didn't mean to alarm anyone

I tend to write a very dry terse response such as these when I'm acknowledging something that needs to be done while I'm in the process of performing the task. Which doesn't provide any context for someone unfamiliar with what is being done to understand the big picture of what is going on.

As Mac and JW have already noted, this is more a bookkeeping issue from your perspective than a loss of anything. Even though a file in the source code had material that presents a problem, that code was never used in current open source clients. It was just mistakenly made available. But to correct the mistake as quickly as we can, the right thing to do is make the inappropriate code unavailable at all (which right now means limiting access to current code repositories). A big hammer to be sure, but one that can be used quickly. Then while they are unavailable we can do the work to "change history" in the context of the repository, to rebuild it In a way as though the inappropriate code never existed. Since that code wasn't being used when we build a client, that won't really change things from your perspective at all.

That rebuild process will take a bit of time to do properly, which is why is not the first step to solve the problem in the most expedient way.

There are a cascade of other obligations we (anyone making a program available whose source code is licensed under the GPL) are subject to, which is what Lyrositor is referring to. The salient requirement is that a program built from GPL licensed source code must be accompanied by the exact source code used to build it. Since any client built from the source base prior to today was built with the errant file, providing that client without the source files runs afoul of the GPL. So the best thing to do is stop distributing the program until it can be rebuilt without the problem material.

So in short, no horror is required on your part, just an understanding that a lot of paperwork is being shuffled.

_R

[Lyrositor]

There are a cascade of other obligations we (anyone making a program available whose source code is licensed under the GPL) are subject to, which is what Lyrositor is referring to. The salient requirement is that a program built from GPL licensed source code must be accompanied by the exact source code used to build it. Since any client built from the source base prior to today was built with the errant file, providing that client without the source files runs afoul of the GPL. So the best thing to do is stop distributing the program until it can be rebuilt without the problem material.

This means Minkata, MO:ULa, Gehn, TOC, and any other Shard out there must stop providing their client to players the moment they edit the history of their source. I have done so with my own shard, and have removed any and all download links I have of clients I built.