Competition legality

[henopied]

Is the modular-ftc package software is legal in competition? If not, is there some way to make a build without moving the code to ftctechnh/ftc_app similar to openftc's unmodified mode? I apologize if this has been answered somewhere.

[magneticflux-]

Thanks for your interest in the modular-ftc project!

There are two versions of modular-ftc: The "standard" mode, which makes no modifications to the original like OpenFTC's "unmodified" mode, and "lite" mode which strips out Blocks and OnBotJava (leaving everything else intact) to shorten the write-run-test cycle during development. The "lite" mode also modifies the UI slightly to indicate that it is not the unmodified FTC app.

There is one difference between modular-ftc's "standard" mode and OpenFTC's "unmodified" mode: while modular-ftc's "standard" mode does not modify the FTC libraries, it does include extra Android- and Gradle-specific "metadata" like working ProGuard rules and transitive dependencies. I'm cautious about saying either OpenFTC or modular-ftc are legal, but I believe that they are either both legal or both illegal for competition.

Additionally, you can emulate OpenFTC's easy modification of sources by using Gradle Composite Builds with locally cloned versions of modular-ftc libraries.

[henopied]

@magneticflux- The use of original AARs would constitute an unmodified SDK. OpenRC's stock mode uses the unmodified AARs, while some of the modular repackaged dependencies would be considered modified. Is there a way of using the non-repackaged versions to make an unmodified build?

[magneticflux-]

There is currently no way to use the original AARs apart from transferring the sources to the original ftc_app.

The unmodified AARs are unsuitable for use cases involving large libraries (such as Apache Commons Math, Google Guava, etc.) that reach the 64k method limit described here without enabling Multidex, which slows wireless deployment down even further. To support those use cases in an efficient manner, Proguard is used instead of Multidex. In order to make the end user experience as smooth as possible (as demonstrated with the simplicity and small size of the sample app, each library has appropriate Proguard rules and transitive dependencies added on.

---

To summarize, these are some reasons behind the current architecture of modular-ftc.

Possible alternative:

• Copy all the Proguard rules into one giant file in the final app.

Downsides:

• Proguard by definition modifies the entire app, including dependencies. This doesn't prevent dependencies from being modified, the only change by moving each dependency into a proper Maven coordinate is the location of the Proguard files. It would be pretty ridiculous to ban built-in Android build functionality.

Possible alternative:

• Rehost the ftc_app dependencies at proper Maven coordinates.

Downsides:

• This would involve manually writing a POM for the unmodified sources in the "standard" version, and manually extracting/decompiling/merging changes into the "lite" version. By just keeping them in the same repository, it's a bit easier to merge changes as updates arrive.

---

Finally, an argument directly for the rule in question:

<RS09> When using the Robot Controller SDK, Teams are not allowed to replace or modify the portions of the SDK which are distributed as binary .AAR files.

My current stance is that recompiling a library from source is not either replacement or modification. I believe replacement to mean re-implementing portions of the SDK and removing the whole original .aars, and I believe modification to mean recompiling the .aars with custom modifications. The modular-ftc project does neither of those things when using the "standard" version.

I believe my case is strengthened by statements from a members of the GDC:

For the Robot Controller SDK we restrict teams from modifying the .AAR files that are distributed with the SDK. We also prohibit them from streaming non-standard (i.e. data that is not normally streamed by our apps) data.
(Forum answered questions, 10/09/18, 1 week after latest rules update)

This seems to indicate that prevention of modification is the intent of the ruling, and that replacement is merely a loose synonym.

---

Sorry for the wall of text, this has been on my mind lately! 😄

[henopied]

Thanks for your reply. I would agree with you for the most part. However, small differences exist between the official and repackaged versions which could be considered modifications.

[magneticflux-]

The only intentional differences are the inclusion of Proguard files, and it doesn't matter where they exist; they all get processed at the very end when the app is built, so until then they're just text files inside of an archive. There may be differences in the compiled code due to recompilation with a different Java compiler and/or newer Android build tools, but I can't do anything about that unfortunately as I'm only approximating the original build environment.

If you spot any other differences, please let me know so I can address them!

[henopied]

The actual class files differ slightly, likely due to compiler differences. Some of the files modified could be considered suspicious (WIFI and other communication files.) Might there be a way to build an AAR with identical class files?

[magneticflux-]

I'm in the process of compiling a WinMerge plugin to diff Java class file bytecode so we can see exactly what is different. I'll post a report of differences in FtcCommon here soon!

[magneticflux-]

Attached to this comment is a CSV report of the difference between the modular-ftc FtcCommon class files and the official FtcCommon class files. There are no bytecode differences between them at all.

ftc-common.txt

Additionally, I attached the compiled plugin and sources that I used, slightly modified from this post to compare private members and raw bytecode.

unpackjavaclassfiles source.zip

Feel free to download/recompile the plugin yourself to reproduce my results!