Subject: Re: "Reasonable Profits"
From: Craig Burley <>
Date: Wed, 2 Sep 1998 03:50:25 -0400 (EDT)

>> Sure, they can edit the source code they get to remove the license
>> protection, but then they'd lose the support.
>You're making an unstated assumption here that you are and can be the
>only possible source of support.  (David Welton makes a similar point
>about ACT in an unrelated message.)  I don't believe that in a libre
>software environment this is enforceable either by technical or
>contractual means.

I admit I can't think of sufficiently easy/cheap ways to enforce
this against clients that insist on "subverting" the system, but...

...surely it must be legal to, at least, insist on supporting only
those users who are running the unmodified, original versions of
the code?!?  Heck, "we" (in the FSV arena) tell people to not
complain to us about bugs in modified versions of our code quite
often (at least I have) -- though perhaps since we're offering only
voluntary help, that is legal in a way a contractual relationship
might not be.

This gets into all the other interesting options regarding whether
to charge for seats, contacts, etc., which others have explained much
better than I could.  (As an end user, I'd have little or no difficulty
running my own modified version of a license-checking package such
that I avoid the tedious license checks and *always*, hopefully,
remembering to verify a buggy behavior with the original version before
picking up the phone...but as an end user *entity* with a bunch of
programmers using a corporate-wide "anointed" version modified internally
for the same purpose, well, that's a much tougher bunch of monkeys to
"re-can" every time one of them wants to pick up the phone, and it
effectively increases the internal cost of each support call.  Does
this make sense?)

[...much interesting analysis...]

>> To get the benefits of GPL'ed software, there'd probably have to
>> be some "blessed" way to use the license-less source for development
>> and other purposes.
>To me this seems to be a attempt to differentiate in your software
>license between different types of use.  Such licensing arguably
>violates at least the spirit of the provision in the Open Software
>Definition about not restricting people from "making use of the program
>in a specific field of endeavor".

I didn't mean to say that the way I did.  What I meant was that for
the "owner" organization to officially support a certain level of
"development" contact with another entity, that entity could be
required to register as a developer via a special development-support

This contract might involve little or no charge either way, and wouldn't
enable any of the normal stuff people do with GPL'ed code that the
owner effectively distributes.

What it could enable are things like rapid response from the owning
entity (the company that spent the VC bucks writing the thing),
online "logging in" to the development and bug-tracking data bases,
registration as an entity that can *also* maintain the "user support"
contract while publishing patches to the code (perhaps independently),
and so on.

This is hardly a fully-fleshed out idea from a business perspective,
just some speculation as to what it *might* look like if things
I do see happen on my end of GPL-based development were to be
codified as business practice in some form.

(My perspective is that I have a group of "special" developers, above
and beyond the rest of the world in "status".  Basically they have
no special rights to the code per se, but I pay a lot more attention
to them when they send patches, for example.  Only one or two of these
happen to have sent me cash, and in no case was this important in
my effectively granting them this status.  Also, I'd *like* to think
that any decent patch coming from anywhere would deserve equal
treatment from me, but the fact remains, I'm a bit "class-conscious"
when it comes to this area: a questionable patch from "outside" often
remains unapplied to the main sources, because I don't know whether
the patch provider will "stand by it" if it proves to be problematic.)

(No, I don't think I'm anywhere close to handling the above situation
in an ideal manner, but I don't think the problems with it are
necessarily in the realm of making the distinctions between,
essentially, those casually interested in changing the product somehow
and those substantially more committed to it.  It's the distinction
between gauging commitment that I'm speculating about -- as an FSV
[Free Software Volunteer], I'm comfortable with my "take" on using
email-list participation and so on, but what this would look like if
based on purchasing support contracts, designating official corporate
contacts, counting supported seats, and so on, I can only speculate
on at this point.)

(As an offhand example: the egcs development list I'm on is still
somewhat slow "reflecting" email sent to it.  I'd already dreamed
up prioritization schemes for this sort of thing based on *cooperative*
models back in the '70s, so I won't get into "technical" solutions
for this in general [the simple, widely known ones being "get a
better mail-list manager", etc.].  But a simple "business" solution
is: prioritize people based on number of support seats purchased
by their employer, or some such metric.  Is that feasable or worthwhile?
Dunno, but it illustrates the point that, when it comes to FSBs,
*always* consider ways to reward paying customers, however "trivial"
they might seem to you -- "codify the ego-boo" is a catch-phrase
that approximates what I'm suggesting, though, as catch phrases
usually do, it can mislead people into thinking it's saying something
it wasn't intended to.)

        tq vm, (burley)

P.S. This has got to be one of the coolest online forums I've been
involved in.  The recent discussions have been particularly
fascinating, even though about all I've had time to do is skim
and save them.  Almost makes me want to start an FS (though I'm
the sort of person who, upon watching a really good video on how
to catch bass, gets a strong urge to take up fishing ;-).