Looks like a very interesting task

At chess application level, both pieces detect backward pawns and adjust score depending on open file and phase.
This can be expected from chess engines: backward pawns are explained in Kmoch part 1, chapter 1.

At source code level they are completely different, call it original. Even in the absense of Rybka's source, there is no way that Fruit's code can be compiled into Rybka's binary. The sources must be different due to the bitmap implementation highly optimized vs. 0x88-like coding and not caring about speed at all. This should not be news.

If we compare the structure/formula between the two programs:

Fruit's pattern:

if no friendly pawns behind or next to me (main condition):
  if the square in front has any side's pawn, or is attacked by an opponent pawn:
      --> is backward (case 1)
  or
  if pawn still on rank 2, and also there is an adjacent pawn on rank 4, and:
      if any side's pawn in front on rank 3 or 4
         --> is backward (case 2)
      or if opponent pawn attacks rank 2, 3, or 4
         --> is backward (case 3)

Rybka's pattern can't be reconstructed from the given code snippet alone, because
part of it comes from the masks in the lookup table. But some information is in there:

The main condition is likely the same. (But it corresponds to general chess knowledge.)
The condition for case 1 can be the very similar as well, except for ignoring own pawns.

The other conditions related to 2nd rank pawns seem rather arbitrary in fruit, and they don't seem to match in Rybka:
The condition for case 2 and 3 look rather different from judging by the structure of the expression alone.

So the patterns used by both programs appear to be essentially different.

There are some similarities still:

The score adjustment doesn't depend on any other attributes in both programs,
such as board location, piece attacks on the pawn, presence of opponent
rooks on the file if is open (or presence of opponent rooks at all).

The same score adjustment is given under all conditions, instead of tuning each condition in isolation.

Except that both programs take file status into account. (That is common practice by itself as well.)
But both do so only for the opening and not the endgame. That is rather weird.
What are possible explanations for this:
1. Definition was taken from fruit or a common ancestor.
2. Definition was inspired by fruit or a common ancestor.
3. Conventional chess wisdom dictates this must be the case. Every IM knows this.
4. Tuning was in fact done with 2 endgame parameters, but coincidently yielded the same value for both conditions.
5. Tuning started out with 2 parameters, yielded very similar values, and they were folded back into one.
This is hardly an essential similarity. But overall also not a big deal.

The values themselves, in [cP]:
Backward/Opening: 8 vs. ~12.7
Backward/OpeningOpen: 16 vs. ~27.3
Backward/Endgame: 10 vs. ~9.3
Thus the weights are different even after scaling to cP.
(The approximate values are rather similar, but that is dictated by the game.)

Code copy? No, no such claim was made in the report.
Formula copy? No.
Derivative? In the report this item comes back as one number in a comparison table.
This particular item was scored as 50% similar in the comparison report, not 100%.
50% is given for the presence of a similar evaluation terms in both programs but different details otherwise.
The same score as Phalanx, Pepito and Crafty. Only Faile was considered to be matching somewhat better.

An argument can be that the 50% should be lower for such terms.
Then the next exercise to do is to see what happens to the comparison if all 50%s are changed throughout the cross-table.