Document the origin of code copied from other projects

[Giszmo]

As a project aiming to be used in Bitcoin wallets, quality of code and accountability are of high importance. Projects integrating with fio will ask if the source code is secure and audited. While knowing the origin of source code cannot replace audits, it does help estimate who else has audited the code or if issues are found, it is important to also estimate the broader implications.

This date library looks a lot like coming from this date library but I can't find any documentation of which revision it actually is. It was added July 2019 but even diffs with revisions from back then are massive.

I see several options here:

• Add date as a submodule.
• Fork date and maintain a stripped-down version which gets added as submodule.
• Document well which revision of date is being used.

If no changes are required, I would opt for the first option. Else for the second. Only those two options allow a relatively easy merging of upstream fixes and improvements.

Edit: This looks similar like this and this looks like this.

So the date and the rapidjson classes live in their own folders inside the abieos folder which also should be cleaned up.

[Giszmo]

I did some digging.

• The rapidjson part appears to be a copy of revision a63216054dfcd37ec94ff48b51d44615f588e425 with a one-line change.
• The abieos part looks more like revision a3a8aa3 than their current master but ... a3a8aa3 is far from a good match.
• The date part almost fits with this revision except for these 543 lines I can't find where they came from.

[Giszmo]

Part of the repo looks like it has its beginning in eosio-java.

[ericbutz]

We will add this to our kotlin readme:

Background

The initial version of the kotlin SDK was a port of the EOS Java SDK from java to kotlin. The kotlin code was
then modified to specifically support the FIO protocol. Included in the port was the The Android Serialization Provider, ABI Provider
and the SoftKey Signature Provider.

The C++ code was also brought over from the EOS Java SDK. The only change to the C++ code was the Class Loader path
information.

The current relevant EOS SDK code base can be found at:

• https://github.com/EOSIO/eosio-java
• https://github.com/EOSIO/eosio-java-softkey-signature-provider
• https://github.com/EOSIO/eosio-java-android-abieos-serialization-provider

[Giszmo]

That's how far I got, too. It would really make things easier if you would know the revision you forked from. Then auditors could look into the EOS SDK from there, check what critical fixes came later and check if those were ported over to FIO and also check the diff with that revision to see what FIO added. I don't know EOS but I know EOS has way more eyes on it than FIO, so I would consider their code as more trustworthy than FIO code and I would concentrate on what FIO added.