For something to be called FRP, they at least need both continuous and discrete abstractions; the simplest description of FRP involves re-evaluation A + B over time, which is not meaningful in Rx or Elm, really.
In Elm behaviors and events are the same thing. Usually operations like filter and fold are only on events, and applicative functor and monadic operations are only on behaviors, but in Elm one type support filter and fold and the applicative functor operations, and monadic bind is not supported at all. I don't think that's good design, but it does mean that Elm has the functionality of both events and behaviors.
Warning: FRP is much more purest than Rx (which is just data flow) or Elm (which is more FRPish but asynchronous). You probably don't want FRP but something more pragmatic like the fore mentioned systems.
There are some nice papers that give an overview of the FRP landscape.
“A Survey on Reactive Programming”: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.416...
“Towards Reactive Programming for Object-oriented Applications”: http://www.guidosalvaneschi.com/attachments/papers/2014_Towa...
Outside, FRP still means FRP, and using the term will automatically put your work in a certain specific bucket that you might not want to be in.