## Mathematica, <s>52</s> <s>47</s> 45 bytes

Byte count assumes CP-1252 encoding and `$CharacterEncoding` set to `WindowsANSI` (the default on Windows installations).

    ±___=!(±1=1>0)
    a__±b__/;a!==b!||{a}==-{b}:=±a

This defines a variadic function `PlusMinus`, which takes the input list as a flat list of arguments and returns a boolean, e.g. `PlusMinus[1, -1, -1, 1]` gives `True`. It's theoretically also usable as an operator `±`, but that operator is only syntactically valid in unary and binary contexts, so the calling convention would get weird: `±##&[1,-1,-1,1]`. It will throw a bunch of warnings that can be ignored.

This will also throw a few warnings which can be ignored.

There *might* be away to shorten the somewhat annoying `a!==b!||{a}==-{b}` part, but I'm not finding anything right now. Keywords like `SubsetQ` and `MatrixRank` are simply too long. :/

### Explanation

The solution basically defers all the tricky things to Mathematica's pattern matcher and is therefore very declarative in style. Apart from some golfitude on the first line, this really just adds three different definitions for the operator `±`:

    ±___=False;
    ±1=True;
    a__±b__/;a!==b!||{a}==-{b}:=±a

The first two rows were shortened by nesting the definitions and expressing `True` as `1>0`.

We should deconstruct this further to show how this actually defines a variadci function `PlusMinus` by only using unary and binary operator notation. The catch is that all operators are simply syntactic sugar for full expressions. In our case `±` corresponds to `PlusMinus`. The following code is 100% equivalent:

    PlusMinus[___]=False;
    PlusMinus[1]=True;
    PlusMinus[a__,b__]/;a!==b!||{a}==-{b}:=PlusMinus[a]

By using sequences (sort of like splats in other languages) as the operands to `±` we can cover an arbitrary number of arguments to `PlusMinus`, even though `±` isn't usable with more than two arguments. The fundamental reason is that syntactic sugar is resolved first, before any of these sequences are expanded.

On to the definitions:

The first definition is simply a fallback (`___` matches an arbitrary list of arguments). Anything that isn't matched by the more specific definitions below will give `False`.

The second definition is the base case for the OVSF, the list containing only `1`. We define this to be `True`.

Finally, the third definition applies *only* to lists that can be decomposed into `X ++ X` or `X ++ -X`, and recursively uses the result for `X`. The definition is limited to these lists by ensuring they can be split into subsequences `a` and `b` with `a__±b__` and then attaching the condition (`/;`) that either `{a}=={b}` or `{a}==-{b}`. Defining `PlusMinus` as a variadic function in this weird way via an operator saves a whopping **5** bytes over defining a unary operator `±` on lists.

But wait, there's more. We're using `a!==b!` instead of `{a}=={b}`. Clearly, we're doing this because it's two bytes shorter, but the interesting question is why does it work. As I've explained above, all operators are just syntactic sugar for some expression with a head. `{a}` is `List[a]`. But `a` is a *sequence* (like I said, sort of like a splat in other languages) so if `a` is `1,-1,1` then we get `List[1,-1,1]`. Now postfix `!` is `Factorial`. So here, we'd get `Factorial[1,-1,1]`. But `Factorial` doesn't know what to do when it has a different number of arguments than one, so this simply remains unevaluated. `==` doesn't really care if the thing on both sides are lists, it just compares the expressions, and if they are equal it gives `True` (in this case, it won't actually give `False` if they aren't, but patterns don't match if the condition returns anything other than `True`). So that means, the equality check still works if there are at least two elements in the lists. What if there's only one? If `a` is `1` then `a!` is still `1`. If `a` is `-1` then `a!` gives `ComplexInfinity`. Now, comparing `1` to itself still works fine of course. But `ComplexInfinity == ComplexInfinity` remains unevaluated, and *doesn't* give true even though `a == -1 == b`. Luckily, this doesn't matter, because the only situation this shows up in is `PlusMinus[-1, -1]` which isn't a valid OVSF anyway! (If the condition did return `True`, the recursive call would report `False` after all, so it doesn't matter that the check doesn't work out.) We can't use the same trick for `{a}==-{b}` because the `-` wouldn't thread over `Factorial`, it only threads over `List`.

The pattern matcher will take care of the rest and simply find the correct definition to apply.