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

Mailman List Mirror (Read Only)
1

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

2

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,

Probably signed binaries, veriexec with a signature list of allowed
executables, proprietary system daemons, hardware drivers, and
read-only filesystems. Protections may be in hardware, and you do not
have source code. You can in JunOS "start shell user root" as
much as you like and get a root shell on various platforms, but some
functions are limited.

Using a 'key' is slightly less of a network operator nightmare than
having 100 featuresets, and thousands of mystery meat images for
the same software version. At least you don't need to go buy a new
software image, and do a full upgrade procedure to gain feature
access.

Applying a key seems less risky and less likely that downtime is
needed, when you decide that you now need this feature.

etc? Wouldn't such access allow smart users to unblock whatever feature

[snip]
Perhaps, but that would be tedious and probably waste a lot of user
time, which can have higher cost than buying a key. The warranty might
be voided, and the installation wouldn't be supported anymore, new
bugs can be discovered. Upgrades can be required.

Even CPU manufacturers are noted for artificially restricting features
in software (such as VT or hyper-threading, even artificially
disabling cores). Not all buyers of L3 switches need or want to pay
for that, and there is more $$$ to be made from those that do.

The manufacturer can either segment their market by not offering
OSPFv3 on the device, release a new higher-end hardware model for V3
support at 10x the cost, or offer an add-on license, as an
incremental upgrade to a larger number of users (including the
installed base).

3

Most of their license keys are implemented as nag-ware. If you don't
mind logs full of "Use of this feature requires a license..." messages,
then, it's between you and your lawyers as long as you don't get
caught.

Owen

4

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.

(...)

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.

At least for IPv6 features, that feature gap only happens with Juniper
EX. All other Juniper gear has, according to them, IPv6 feature parity
within all license levels and packages.

Rubens

5

Using a 'key' is slightly less of a network operator nightmare than
having 100 featuresets, and thousands of mystery meat images for the
same software version. At least you don't need to go buy a new
software image, and do a full upgrade procedure to gain feature access.

Applying a key seems less risky and less likely that downtime is
needed, when you decide that you now need this feature.

Indeed. Just as importantly, developing a single image with
license-enabled features saves both vendors and customers a lot of time
on QA, acceptance testing, etc. Since you're always running the same
image, you only need to test it once, with all features enabled, to be
sure that everything works; if there are different images for different
feature sets, you have to run a full test suite on each image. That's a
lot of extra work for no real benefit. Having to switch from one image
to another to enable a particular feature also entails additional risk,
downtime, etc. that simply loading a license key does not.

Even CPU manufacturers are noted for artificially restricting features
in software (such as VT or hyper-threading, even artificially
disabling cores). Not all buyers of L3 switches need or want to payfor
that, and there is more $$$ to be made from those that do.

The manufacturer can either segment their market by not offering
OSPFv3 on the device, release a new higher-end hardware model for V3
support at 10x the cost, or offer an add-on license, as an incremental
upgrade to a larger number of users (including the installed base).

Indeed. Vendors face a lot of price pressure, so being able to disable
non-mandatory features to meet low-end customers' price demands is a
major competitive advantage. However, they still need revenue to
support the development that the handful of high-end customers demand
for "new" or "optional" features, and charging for licenses to enable
those features seems to be the best way that anyone has figured out to
do that.

Heck, I work with one vendor that requires separate licenses for
virtually every checkbox in their GUI; turning up one customer port may
involve purchasing dozens of new licenses. The customers of their
product don't like it, sure, but suggest that they pay the full cost of
enabling all options on all ports and they flip out. Licensed features
enable customers to purchase only what they need, not what some
marketing puke decides they need (or some one-size-must-fit-all pricing
scheme, which rarely works well).

S