Raul Miller <rdm@test.legislate.com>:
: > > The fanaticism that surrounds free software is a problem, in my
: > > opinion. It is the next big problem that faces the community. It
: > > forces people to choose between completely free or completely
: > > non-free. As with almost everything, the end point is not the right
: > > place to be, the midpoint is a better answer.
:
: I'm not sure that it's fanaticism. How is "we won't use/ distribute/
: promote this product if the license doesn't suit us" fanaticism?
OK, how about dogmatic? That work better? The deal is that some people
will (and are) chased away by the insistance on free software only.
Which is a shame. Given a choice between proprietary software and
free for free/money for money style software, which do you want?
Assuming that you, like me, would prefer to get more stuff for free,
it makes sense to encourage the compromise.
And allowing the midpoint does nothing bad to the free software guys. If
there is stuff there that you insist on being free, you are welcome to
rewrite it.
: Also, note that a number of companies have been making money off of
: software with free licenses. [I'm sure you've heard of Cygnus and
: Red Hat.] Which merely underlines the point that making money off
: of software doesn't necessarily require that its use is restricted --
: though it does require understanding your market.
I'm very aware of how both companies work. I have dinner with two of
the Cygnus founders several times a month, and I'm well informed on
their plans. They are trying to go public and you should watch what
they do over the next year or so. Your point is not valid with respect
to Cygnus, at least their current management would not agree.
As to Redhat, I know those guys personally as well and they provide
a great service. But they provide on the backs of people "donating"
their time to produce something for RedHat to ship. If you were to
consider the costs of producing all of that software, RedHat isn't making
anything like what it would take to produce that. In fact, RedHat, SUSE,
and Caldera all put together have far less annual revenues than Sun's
software budget as of 1993. What's that tell you? (Glib answers like
"Sun sucks", while tempting, aren't really helpful.)
: Given your stated goals [getting compensation from the large business
: community] I'd think you'd want to require money for the sort of
: needs which are unique to that community? [The classics have to
: do with service, support, and perks.]
Doesn't work. Look at Cyclic. Look at Cygnus.
: [Further aside: I'm not sure that the stated goals of your project --
: making the patching process faster -- have anything to do with the
: current problem. The current problem is that coordinating patches that
: may conflict with other patches is a tough problem, and requires
: someone understand the conflicts.]
That point has been the subject of some discussion on bitkeeper-users@bitmover
and I think that we have a really good handle on it. The basic answer is like
so:
- postulate change sets (a wad of deltas plus comments)
- postulate lines of development (sort of a named branch except it
doesn't ahve to be a branch, it can just be a subset of a revision
graph and it can start on the trunk and go around the corner to
a branch if need be ue to conflict)
Then patches are a change set with their own line of development tag.
The patch itself carries history information and can be revised as it
works its way to the "center" (aka Linus). Patches also contain information
about where they fit in the tree, making it trivial to ask questions like
- pick non-conflicting patches from the pending list and apply 'em
- reject all patches that are not up to date with my tree (the
patch owner can simply do a resync with the main tree and resubmit)
etc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/