Juniper's artificial feature blocking (was legacy /8)

Sun Apr 4 19:33:38 UTC 2010

Tore Anderson <tore.anderson at redpill-linpro.com> wrote:

> Juniper.  If you want to run OSPFv3 on their layer 3 switches, you need
> a quite expensive "advanced" licence.  OSPFv2, on the other hand, is
> included in the base licence.

Really?  My level of respect for Juniper has just dropped a few notches
after reading this NANOG post - I didn't know that they were engaged in
such DRM-like feature blocking practices.

Where can I find more information about Juniper's stance on such
practices (having some feature X present in both HW and SW, but
artificially blocked until one buys an unlock key from them) and the
exact degree to which they engage in such?

The reason I ask is because I've been considering building my own PIM
for their J-series, a PIM that would terminate Nokia/Covad's flavor of
SDSL/2B1Q at the physical layer and present an ATM interface to JunOS,
optionally supporting NxSDSL bonding with MLPPPoA.  I have no love for
routers that aren't 100% FOSS, but I couldn't find any other existing
router platform which could be extended with 3rd-party physical
interface modules, and designing and building my own base router chassis
is not a viable option if I want to actually have something built before
the Sun swells into a red giant and engulfs the Earth.

So I thought that even though it isn't 100% FOSS, JunOS ought to be at
least tolerable given that it appears to be based on FreeBSD and I've
heard that it even allows the user to get direct access to the underlying
Unix shell (does it really?) - but hearing about DRM-like artificial
feature blocking seems to negate that.  I mean, how could their
disabled-until-you-pay blocking of "premium features" be effective if a
user can get to the underlying Unix OS, shell, file system, processes,
etc?  Wouldn't such access allow smart users to unblock whatever feature
is artificially blocked?

Someone please educate me...

MS