[OpenIndiana-discuss] OpenIndiana roadmap

[Sašo Kiselkov]

On 02/19/2013 03:12 PM, Jim Klimov wrote:
> 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?

Correct.

> 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).

Ultimately, you'll end up burning a lot more time pursuing abusers
then... a brilliant way to kill an open-source project is to micromanage
its uses.

> 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

This only works if the users don't have access to the fingerprinting
library sources and the code is signed and possibly obfuscated. This is
180 degrees opposite of open-source.

> 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.

Oracle, FWIW, doesn't actually use licensing keys on their products, you
can download Oracle DB Enterprise and use it without (technical)
trouble. You just won't get fixes and updates. Oh and forget about the
source.

> 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?)

And who's going to do the audits? If you show up on my doorstep, I'll
first call a cab and then the police. If you don't have the legal
leverage to enforce a contract, don't establish one.

> 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.

If you can establish a company to sell OI support, go ahead. But if you
do this to the OI project itself, I can pretty much guarantee you that
it will wither and die.

>> 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.

Except that enforcing this would break OI's promise and community
relationships, no question.

> 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.

I much prefer this method. Compulsion almost always results in pushback
in open-source projects.

> The rest are mechanisms - algorithmical, licencial, procedural...
> which lead to the needed result: collection of money,

.. and breaking the community promise of OI. Good job. Look, I'm not
saying that there isn't room for a company to step in and help by
offerring professional support services as a separate add-on - I'd love
to see that happen, OI needs that a lot. But not at the cost of
polluting OI-proper.

> 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).

I'm tired of this discussion. In short, if OI were to reverse on its
open-development promise, it will lead to its demise.  It's not like
there aren't alternatives available.

Cheers,
--
Saso