[OpenIndiana-discuss] OpenIndiana roadmap

[Jim Klimov]

On 2013-02-19 14:38, Sašo Kiselkov wrote:
> You don't get access to RedHat's repos without paying. There are some
> portions of the code that CentOS doesn't ship (such as the policy
> enforcement libraries). In this respect, RHEL is closer to what Solaris
> was before the Oracle takeover (a closed-source distro built from freely
> available sources).

 > No, if you want to track usage without people cheating, you need to ship
 > closed policy enforcement code - that's why you'll never see an
 > open-source DRM. It just doesn't work, by definition.

Ok... in this case, I believe, the enforcement parts are not GPLed? ;)
However, if "RedHat" gives you access to GPLed code (even for money),
you have any right to republish it and they have no right to request
an NDA on it, right?

>
>> Also, the paid-for distro users have someone to complain to in
>> case of bugs/RFEs, and the community (including free spinoff
>> users) have the results for free, but later (after testing,
>> rebuilds, etc.) Qualified users are free to pull the source
>> code updates and constantly rebuild their free OSes if they
>> like, but the general populace would likely wait for new RPM
>> revisions to appear and become automatically downloaded and
>> applied to their installation.
>>
>> As for user identification, Oracle MOS has an example with
>> individual user certificates issued for support contract
>> holders, to access IPS repos over HTTPS. On one hand, these
>> certificates automatically have an expiration date which
>> forces one to continue buying support and automates the
>> non-provision of commercial updates to unpaid users. On
>> another hand this allows to track the usage - i.e. how
>> many IP addresses downloaded a patch with certain user
>> certificate, or even how many times it has been used for
>> the same patch in a short timeframe (though... then what
>> about updates of many local zones...)?
>
> Except that you could use this to install a certificate on any number of
> NAT'ed machines. A little bit of manipulation in the IPS libraries and
> you can get all machines to look and smell like the same machine.

That's what I meant about tracking the intensity of usage of
the certificate for the same packages in some time frame, from
one or multiple internet addresses.

To an extent this would interfere with local zones - or with
your multiple systems that would look like one system's zones.
But using some analytics - i.e. requests for GZ-only packages
or some other "suspicious" behavior, you might detect possible
abuse of licensing and suspend a user's certificate (via CRL
on the IPS CA).

To go Nazi'er about this, you could use Remote Physical Device
Fingerprinting techniques, see
http://www.caida.org/publications/papers/2005/fingerprinting/

http://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-devicefingerprinting.pdf

But realistically, any harsh requirements would be circumvented.
Even Microsoft and Oracle and MPAA, despite a bully attitude
and billions to invest into police collaboration, can't force
everyone to pay. The attitude should be different, maybe more
honorable? Perhaps, bundle prices and early application of "site"
support licenses would help (i.e. you pay for 1000 OI installs
as for 10, but you have peace of mind that you're audit-clean);
and as long as this only concerns automated support - patching -
the support provider does not have much more spending either
(perhaps only bandwidth?)

In fact, many commercial companies go this way about their support
sales - they are interested in getting a minimum amount of dollars
from the transaction. Discounts from list prices might be negotiated
to orders of magnitude, so you can get almost any amount of support
rights after you pay a certain minimum price - especially if you do
buy something else to sweeten the deal for all sides.

> I don't want to go through a billion hoops just to deploy
> security-supported machines. Want to make a closed-model variant of OI?
> Go ahead. But if this is the direction OI itself takes, I'm out (and I
> gather I'm not the only one).

No, that is not what I want. I am elaborating on my current point
of view for the basic question "*how to provide funding to support
a regularly security-supported release?*" Discussion might change
this point of view by uncovering its deficiencies, of course ;)

One way is to *require* people (or organizations) to pay.

Another way is to *ask them nicely to pay* (gift, whatever) before
we kick the bucket and they'd have to migrate and blame themselves
for the headache and loss of OS qualities.

The rest are mechanisms - algorithmical, licencial, procedural...
which lead to the needed result: collection of money, payment to
people who track CERT or Linux security patch streams and apply
patches to illumos and build the binary releases, and availability
of these releases to at least the paying users but preferably to
everyone ("instantly" or "sooner or later").

As another example I might point to multiple open/closed projects
(where "closed" is a feature-enhanced version of "open"; often the
tested in enterprise battlefield "closed" features make it into
new "open" releases as the next version's baseline of features -
thus the paying users are the lab rats, not free ones as is often
grumbled about), and/or projects with obscure or proprietary source
and free licensing to some categories of users.

For example, VirtualBox PUEL requires that the free user downloads
and installs his VBox software himself. Then he can do anything -
run developer tests or build an enterprise empire upon a farm of
webservers. If VBox is installed by admins as a service for users
(including, I think, VDI usage nowadays) - then it should be bought.
If you like the software and want to pay anyway - you can, too :)

You run a business and gain money? Cash up please. You run a home
PC or run around with a laptop - here are your patches. This does
certainly rely on a measure of honorability. Those who pay would
likely prefer to have bonuses - like a help-desk to call. This is
more cost on support provider, and it might be an additional level
of support in pricing (as well as something that project partners
could do, being near such users and speaking in their language -
as in tiered support partners; perhaps helping with installations,
localizations and whatnot as other additional services, as well).