Your great-grandparents could all sing in tune
and in harmony, and many of them played an
instrument. They were music-makers. Sheet
music sales were big business. In the
days before radio, TV, and records, people had
to entertain themselves, and they did. Few
people wrote original music, but almost everyone
sang and far more people could play the piano.
If you take your little network and hook it to
another little network, no one cares. Now,
let's suppose that you are a big network; in
fact, you are the monopoly cable provider in
your town. Now, let's suppose you like Fred Foo
for mayor, because he helped you arrange your
monopoly, and you hate Bart Barr, because he's
trying to get a competing cable franchise established. So you decide to give the Foo
campaign high QoS and 300 bps to the Barr campaign. Still no reason to regulate?
Or, to take a more realistic example: you
have a cable monopoly and you own a movie studio.
You provide high QoS jitter-free streaming interactive movies to your cable modem customers -- but only movies owned by
your studio. Competitors can only use your
generic, bursty service, with lots of packet
retransmissions and brief outages. Customers can
use DSL instead of a cable modem, but the
local phone company, which controls all DSL
traffic, has made a deal with a
different movie studio, so if you want to watch
someone else's movies you're still hosed.
You can try wireless IP, but there's not enough
available bandwidth and too much interference.
Long ago, the feds made a very wise decision:
they forced the major studios to sell their
theaters. In the old days if you were in a
small town you might only be able to get movies
produced by the studio that owned your local
theater. Content and distribution need to be
kept separate, by law if need be.
There's no problem with defining time_t to be
64 bits on a 32-bit architecture. There can
be a small performance penalty if it isn't done
carefully, but that's it.
The WHO is the most credible of any of the UN
institutions. The WHO are the people who successfully rid the world of smallpox (other
than samples stored in high-security labs),
and may soon succeed in eliminating polio.
They get things done.
Each side tries to excel. Third parties benefit
as the available software gets better and better.
Each side tries to whack the other side, spread
FUD, make the other side look bad. Systems become
incompatible with each other and people get locked
into one side or the other. Third parties lose.
This one could go either way. Remember BSD vs
System V, then System V vs OSF, and Open Look
vs Motif? All these battles just about killed
the Unix market in favor of Windows; fortunately
Linux and BSD came along to put new life into
Unix.
If the Gnome and KDE folks are interested in way
#1, then they will put substantial energy in
making sure that KDE apps work well on a Gnome
desktop and vice versa, and they will avoid the
nasty attacks on the other side we so commonly
see Example: when the Gnome Foundation was
created it was bitterly attacked by many KDE
partisans as something terribly immoral, yet
now we see the KDE League, a roughly identical
operation. Now, there's nothing wrong with
either one, so it was the attacks that were
bogus.
RMS has said that if the Linux kernel were available at the time that the Hurd started,
the FSF wouldn't have bothered with it. But
since a lot of work has already been done on it,
he wants to see it finished.
But the resources dedicated to the Hurd are not huge (if they were, it would probably be further along).
"but your failure to mention now something on which you later rely in court may be used against you in evidence"...
This is a difference between the US and UK
legal systems, in the US, not only may a defendent not be compelled to testify against
himself, but this can't be used against him.
The Consititution defines (or, rather, re-uses) a very flexible mechanism for international problems. It's called "treaties".
The relevant governments get together and agree to it, and each nation ratifies the result. In the US, ratification requires 2/3 of the Senate.
Yes, the gcc was included in the beta.
This doesn't change my criticism.
Red Hat (and other major distributors)
should discuss plans to include snapshot
releases with upstream maintainers, not to give them a veto, but so that any problems caused thereby can be worked out in advance.
I admire your company greatly and have had very productive relationships with Red Hat and Cygnus engineers going back many years. I am a member of the GCC steering commitee. I wish you nothing but success.
However, you do have a problem with openness that you are not acknowledging. There is one sense in which your practices do resemble those of Microsoft: your practice of keeping outsiders in the dark about upcoming plans that will affect them. To be specific: your management ordered its employees, including those who were members of the GCC Steering Committee, not to discuss anything about your plans for Red Hat 7.0 with other members of the committee. Advance discussion could have led to improved quality in 7.0, better relations with the outside developers you depend on, better planning by your customers and a whole lot less anger against you.
Did you file bug reports? Are you sure that your code that 2.7 accepted was good code? (gcc 2.7 and earlier accepted all kinds of crap that is
not C++).
Where did you get the idea that 2.95.2 is
"the buggiest release of GCC since early days"?
Have you ever used it? Did you know that it is
the production compiler on Debian 2.2 and they
are reasonably happy with it? That it had some
of the most thorough testing of any GCC release ever?
I've been an active user of g++ since 1990.
For C++, 2.95.2 is the highest quality release
ever put out. The problems with 2.95.2 are
platform-specific, the Alpha port wasn't great.
Don't spread false information.
Richard Henderson ignores the issue of binary compatibility with other distributions, and, I believe,
overstates the problems with 2.95.2. The
Alpha back end isn't great, but ia32 which
most folks use was decent and it was the best
C++ front end we ever had. And the kernel
developers did a lot of work so that at
least the Linux development kernels
build ok with 2.95.2 -- but "2.96" can't build
Linux (gcc problems building the kernel are
often kernel, not gcc, bugs, though sometimes
gcc is at fault).
Also, Richard is wrong when he says that their
"2.96" is compatible with the forthcoming 3.0
at the source level. It isn't; it still uses
libstdc++-v2 (the v3 library is not complete).
Streams aren't templates, the standard library
is not in the std namespace. It is compatible
with 2.95.2 at the source level, not
3.0.
Even so, I could have accepted his arguments
much more readily had they been made before
the release and not after, and if they had
polled customers and software developers about
the issue rather than just deciding internally.
Now, I'm grateful for all the hard work the Red
Hat/Cygnus folks have put in. But when different (GNU/)Linux distributions can't run each others' binaries, you have exactly the same situation
the Linux company chiefs
say they won't allow to happen: effective forking of Linux.
The non-Red-Hat members of the steering committee were annoyed mainly because Red Hat did not tell us what they planned to do,
and, worse, forbade their employees from telling us. Had we had some input, we could have at least discussed ways of making our lives easier
(choosing a version string that makes it clearer that their compiler release was a fork, not a
released 2.96, changing the address for bug
reports, etc).
The Red Hat folks say that they will do more
advance communication next time. I hope so.
You didn't get your ia64 gcc version from the
GCC steering committee, as there is no official
ia64 release yet. So whatever you have is an
early snapshot.
Any ia64 gcc you can find will be a highly
experimental, buggy piece of software.
You might be able to get some help from the
folks on the Linux IA-64 project.
You are probably thinking of the
hypothetical "memex" device proposed in
his article
As We May Think
that appeared in the
Atlantic Monthly in 1945. He did not demonstrate
anything, he only described it.
As
Courtney Love points out in detail, artists aren't eating under the
current system. Artists may well do better
giving away MP3s and asking for tips and making
money from concert tours than under the current
system. As she says:
Today I want to talk about piracy and music. What is piracy? Piracy is the act of stealing an artist's work without any intention of paying for it. I'm not talking about Napster-type software.
I'm talking about major label recording contracts.
Guido van Rossum writes:
At the same time, Stallman doesn't want to allow any choice of law clauses, because one could stipulate the law of "Unfreedonia" which might reverse the meaning of the GPL. Even though the state of Virginia does no such thing!
Sorry, Guido, Virginia is Unfreedonia.
It is the only state that passed
UCITA without
modification (Maryland passed a highly modified
version that struck out some of the more
obnoxious provisions). UCITA contains many horrors for
free software developers and software users alike. Stallman pointed
out many of these problems in
this article. Virginia is the worst possible
state in the US to specify as the jurisdiction
where disputes over licensing will be settled.
I don't know if RMS's warning about UCITA
potentially subjecting free software authors
to liability (while exempting those who use
shrink-wrap licenses) is correct or not, but
it is a worry.
If Python is incompatible with the GPL, what it
means is that people won't be able to link together Python code and GPLed code. This will
be a major pain in the butt, so I hope that it
can be fixed.
I don't know why everyone is giving RMS so much
crap when it is CNRI that is making a change to
a more restrictive license than it used in the
past. CNRI created the problem, not RMS; as
Guido said
The new license was imposed by CNRI on Python 1.6 (the last release done from CNRI's code base).
The best solution will be to find some
language that satisfies CNRI's concerns without
causing these problems.
Wow. You think that college should be about teaching you Visual Basic?
Someone with a good CS education (note that
I said a good CS education, which may
not correspond to what is available in your
school) can learn the computer language du jour
quickly and independently. Someone who goes
out of high school to a "Visual Basic in a month"
course is useless as soon as VB loses favor.
Unfortunately too many universities these days
are confused about this and providing their
students nothing but a trade-school exposure
to what's currently trendy.
Now that's not to say that it might not be a good
idea for some folks to delay college for a while
and try working in "the real world" first.
Students (especially grad students) who've had
more non-academic experience, I think, get more
out of their university education because they
are more focused.
I think I'll go license-free with any software I make public.
Fine. But if you do, you'll need to do it right.
You'll need to say something like "I hereby
place this code in the public domain." That
will work if you have the right to make
such a statement: if you work in the US as a
programmer, your employer may have a claim to
your code.
If you put out code without any claims at all,
then we get the default: it's not legal for
anyone to make a copy or a derivative work
without explicit permission from you.
No, you'd only suffer the penalty if your brother
asked for the source code for your change, and
you refused, and you still refused when he went
to the copyright owner of the GPL'ed work and
asked for enforcement.
A GPL'ed work is just as copyrighted as any
commercial application. Refusing to comply
with the license is a serious matter, and
if you do it there is a price to pay.
KDE developers who took GPL-licensed code whose
copyright belonged to the FSF, and linked it
to Qt, and distributed the result violated the
GPL. The GPL itself specifies a penalty for this
action: the person doing it forfeits all rights
to copy and modify the program at all.
That means that if RMS really wanted to be an
asshole, he could shut down Mandrakesoft (for
putting out a KDE distribution when they knew
full well about this), by enforcing this clause
against them (they wouldn't be able to distribute
vital parts of the GNU/Linux system).
What RMS is saying is that he is waiving this
penalty in the interests of ending this thing.
So when you ask "Who are you? God?" the answer
is no, he is the copyright owner whose license
has been violated.
Slashdot Mirror
Your great-grandparents could all sing in tune and in harmony, and many of them played an instrument. They were music-makers. Sheet music sales were big business. In the days before radio, TV, and records, people had to entertain themselves, and they did. Few people wrote original music, but almost everyone sang and far more people could play the piano.
If you take your little network and hook it to another little network, no one cares. Now, let's suppose that you are a big network; in fact, you are the monopoly cable provider in your town. Now, let's suppose you like Fred Foo for mayor, because he helped you arrange your monopoly, and you hate Bart Barr, because he's trying to get a competing cable franchise established. So you decide to give the Foo campaign high QoS and 300 bps to the Barr campaign. Still no reason to regulate?
Or, to take a more realistic example: you have a cable monopoly and you own a movie studio. You provide high QoS jitter-free streaming interactive movies to your cable modem customers -- but only movies owned by your studio. Competitors can only use your generic, bursty service, with lots of packet retransmissions and brief outages. Customers can use DSL instead of a cable modem, but the local phone company, which controls all DSL traffic, has made a deal with a different movie studio, so if you want to watch someone else's movies you're still hosed. You can try wireless IP, but there's not enough available bandwidth and too much interference.
Long ago, the feds made a very wise decision: they forced the major studios to sell their theaters. In the old days if you were in a small town you might only be able to get movies produced by the studio that owned your local theater. Content and distribution need to be kept separate, by law if need be.
The Salon technology coverage is still terrific; they are among the few journalists who can both write well and understand the free software movement.
If you don't like their Clinton/Gore lapdoggery, just skip direct to the technology page and bookmark that.
There's no problem with defining time_t to be 64 bits on a 32-bit architecture. There can be a small performance penalty if it isn't done carefully, but that's it.
The WHO is the most credible of any of the UN institutions. The WHO are the people who successfully rid the world of smallpox (other than samples stored in high-security labs), and may soon succeed in eliminating polio. They get things done.
There are two possible ways to compete:
This one could go either way. Remember BSD vs System V, then System V vs OSF, and Open Look vs Motif? All these battles just about killed the Unix market in favor of Windows; fortunately Linux and BSD came along to put new life into Unix.
If the Gnome and KDE folks are interested in way #1, then they will put substantial energy in making sure that KDE apps work well on a Gnome desktop and vice versa, and they will avoid the nasty attacks on the other side we so commonly see Example: when the Gnome Foundation was created it was bitterly attacked by many KDE partisans as something terribly immoral, yet now we see the KDE League, a roughly identical operation. Now, there's nothing wrong with either one, so it was the attacks that were bogus.
RMS has said that if the Linux kernel were available at the time that the Hurd started, the FSF wouldn't have bothered with it. But since a lot of work has already been done on it, he wants to see it finished.
But the resources dedicated to the Hurd are not huge (if they were, it would probably be further along).
"but your failure to mention now something on which you later rely in court may be used against you in evidence" ...
This is a difference between the US and UK legal systems, in the US, not only may a defendent not be compelled to testify against himself, but this can't be used against him.
The Consititution defines (or, rather, re-uses) a very flexible mechanism for international problems. It's called "treaties". The relevant governments get together and agree to it, and each nation ratifies the result. In the US, ratification requires 2/3 of the Senate.
Yes, the gcc was included in the beta. This doesn't change my criticism. Red Hat (and other major distributors) should discuss plans to include snapshot releases with upstream maintainers, not to give them a veto, but so that any problems caused thereby can be worked out in advance.
Dear Bob,
I admire your company greatly and have had very productive relationships with Red Hat and Cygnus engineers going back many years. I am a member of the GCC steering commitee. I wish you nothing but success.
However, you do have a problem with openness that you are not acknowledging. There is one sense in which your practices do resemble those of Microsoft: your practice of keeping outsiders in the dark about upcoming plans that will affect them. To be specific: your management ordered its employees, including those who were members of the GCC Steering Committee, not to discuss anything about your plans for Red Hat 7.0 with other members of the committee. Advance discussion could have led to improved quality in 7.0, better relations with the outside developers you depend on, better planning by your customers and a whole lot less anger against you.
Joe Buck
Did you file bug reports? Are you sure that your code that 2.7 accepted was good code? (gcc 2.7 and earlier accepted all kinds of crap that is not C++).
Where did you get the idea that 2.95.2 is "the buggiest release of GCC since early days"? Have you ever used it? Did you know that it is the production compiler on Debian 2.2 and they are reasonably happy with it? That it had some of the most thorough testing of any GCC release ever?
I've been an active user of g++ since 1990. For C++, 2.95.2 is the highest quality release ever put out. The problems with 2.95.2 are platform-specific, the Alpha port wasn't great. Don't spread false information.
Richard Henderson ignores the issue of binary compatibility with other distributions, and, I believe, overstates the problems with 2.95.2. The Alpha back end isn't great, but ia32 which most folks use was decent and it was the best C++ front end we ever had. And the kernel developers did a lot of work so that at least the Linux development kernels build ok with 2.95.2 -- but "2.96" can't build Linux (gcc problems building the kernel are often kernel, not gcc, bugs, though sometimes gcc is at fault).
Also, Richard is wrong when he says that their "2.96" is compatible with the forthcoming 3.0 at the source level. It isn't; it still uses libstdc++-v2 (the v3 library is not complete). Streams aren't templates, the standard library is not in the std namespace. It is compatible with 2.95.2 at the source level, not 3.0.
Even so, I could have accepted his arguments much more readily had they been made before the release and not after, and if they had polled customers and software developers about the issue rather than just deciding internally.
Now, I'm grateful for all the hard work the Red Hat/Cygnus folks have put in. But when different (GNU/)Linux distributions can't run each others' binaries, you have exactly the same situation the Linux company chiefs say they won't allow to happen: effective forking of Linux.
The non-Red-Hat members of the steering committee were annoyed mainly because Red Hat did not tell us what they planned to do, and, worse, forbade their employees from telling us. Had we had some input, we could have at least discussed ways of making our lives easier (choosing a version string that makes it clearer that their compiler release was a fork, not a released 2.96, changing the address for bug reports, etc).
The Red Hat folks say that they will do more advance communication next time. I hope so.
You didn't get your ia64 gcc version from the GCC steering committee, as there is no official ia64 release yet. So whatever you have is an early snapshot. Any ia64 gcc you can find will be a highly experimental, buggy piece of software. You might be able to get some help from the folks on the Linux IA-64 project.
You are probably thinking of the hypothetical "memex" device proposed in his article As We May Think that appeared in the Atlantic Monthly in 1945. He did not demonstrate anything, he only described it.
As Courtney Love points out in detail, artists aren't eating under the current system. Artists may well do better giving away MP3s and asking for tips and making money from concert tours than under the current system. As she says:
Virginia, not Maryland, passed UCITA unchanged. I was right the first time.
Guido van Rossum writes: At the same time, Stallman doesn't want to allow any choice of law clauses, because one could stipulate the law of "Unfreedonia" which might reverse the meaning of the GPL. Even though the state of Virginia does no such thing!
Sorry, Guido, Virginia is Unfreedonia. It is the only state that passed UCITA without modification (Maryland passed a highly modified version that struck out some of the more obnoxious provisions). UCITA contains many horrors for free software developers and software users alike. Stallman pointed out many of these problems in this article. Virginia is the worst possible state in the US to specify as the jurisdiction where disputes over licensing will be settled.
I don't know if RMS's warning about UCITA potentially subjecting free software authors to liability (while exempting those who use shrink-wrap licenses) is correct or not, but it is a worry.
If Python is incompatible with the GPL, what it means is that people won't be able to link together Python code and GPLed code. This will be a major pain in the butt, so I hope that it can be fixed.
I don't know why everyone is giving RMS so much crap when it is CNRI that is making a change to a more restrictive license than it used in the past. CNRI created the problem, not RMS; as Guido said The new license was imposed by CNRI on Python 1.6 (the last release done from CNRI's code base).
The best solution will be to find some language that satisfies CNRI's concerns without causing these problems.
Wow. You think that college should be about teaching you Visual Basic?
Someone with a good CS education (note that I said a good CS education, which may not correspond to what is available in your school) can learn the computer language du jour quickly and independently. Someone who goes out of high school to a "Visual Basic in a month" course is useless as soon as VB loses favor.
Unfortunately too many universities these days are confused about this and providing their students nothing but a trade-school exposure to what's currently trendy.
Now that's not to say that it might not be a good idea for some folks to delay college for a while and try working in "the real world" first. Students (especially grad students) who've had more non-academic experience, I think, get more out of their university education because they are more focused.
I think I'll go license-free with any software I make public.
Fine. But if you do, you'll need to do it right. You'll need to say something like "I hereby place this code in the public domain." That will work if you have the right to make such a statement: if you work in the US as a programmer, your employer may have a claim to your code.
If you put out code without any claims at all, then we get the default: it's not legal for anyone to make a copy or a derivative work without explicit permission from you.
No, you'd only suffer the penalty if your brother asked for the source code for your change, and you refused, and you still refused when he went to the copyright owner of the GPL'ed work and asked for enforcement.
A GPL'ed work is just as copyrighted as any commercial application. Refusing to comply with the license is a serious matter, and if you do it there is a price to pay.
KDE developers who took GPL-licensed code whose copyright belonged to the FSF, and linked it to Qt, and distributed the result violated the GPL. The GPL itself specifies a penalty for this action: the person doing it forfeits all rights to copy and modify the program at all. That means that if RMS really wanted to be an asshole, he could shut down Mandrakesoft (for putting out a KDE distribution when they knew full well about this), by enforcing this clause against them (they wouldn't be able to distribute vital parts of the GNU/Linux system).
What RMS is saying is that he is waiving this penalty in the interests of ending this thing.
So when you ask "Who are you? God?" the answer is no, he is the copyright owner whose license has been violated.
That's one titanium fuel tank for each satellite. Look out below!