I sent the following to info@fsf.org on January 1, and have not received a
reply. Since it is a legal question, perhaps Professor Moglen would answer
it here. Some context:
I'm writing because I cannot understand some parts of the "FSF's
Position on Proposed W3 Consortium 'Royalty-Free' Patent Policy", at
http://www.gnu.org/philosophy/w3c-patent.html .
First, it is quite clear that you believe that software exercising
patents with "field-of-use" licenses cannot be distributed under the
GPL. However, it is not clear whether you believe that such
software could be distributed as free software at all. Paragraph
two seems to say that it could not, but it also appears to conflate
GPLed software with free software, so I am not sure this is what the
author meant. Paragraph three equivocates by saying "licensing
under other free software licenses does not imply free", without
saying "licensing under other free software licenses implies not
free".
The impact of the proposed policy on the free software community
obviously depends greatly on whether it could prevent us from
implementing some standards at all, or only under the GPL. Which is
it? (Since most of the document focuses on the GPL, I assume it is
the latter. But it should be stated explicitly, and the hints to
the contrary should be cleaned up.)
Second, who exactly would be prevented from distributing software
exercising such patents under the GPL? Those in jurisdictions in
which the patent applies, or everyone?
Third, why exactly are "field-of-use" patents incompatible with the
GPL? The addendum intended to clarify this matter does not succeed.
Step 4 in its example says,
C's patent license prohibits folks from taking his URL parsing
code and putting it into, say, a search engine.
But C's patent equally prohibits folks from taking a (hypothetical)
GPLed search engine and adding URL parsing code. So by that
argument, nobody can distribute a GPLed search engine, either. What
really is the criterion that prevents distribution under the GPL?
Is it that the author "knows" that others will be "tempted" to
modify the software such that it no longer meets the "field-of-use"
restriction? Is it that the author has accepted the patent license
himself?
And how does this differ from the situation of distributing GPLed
software that cannot be used in some jurisdictions? If I distribute
cryptographic software under the GPL, it will end up in the hands of
people in repressive countries who are not allowed to use (never
mind redistribute) it. This would seem to imply that such software
cannot be distributed under the GPL.
I hope you can answer these questions and update the text on your
web site.
but I see several a month where scandisk reports bad sectors, but if you back up the data and low level format it (read: write zeroes, I'm not going to go into an explanation of why you can't do a real low level format on an IDE drive) no errors are found and when the drive is repartitioned/formatted, scandisk is happy as a clam.
What happens here is actually really simple. When the drive notices a dead or dying block, it can use one of its "reserved" blocks instead, and enter the substitution into a table somewhere. Except in one case: When asked to read from a dead block, it can't just return bogus data: it has to admit that there was an error. When asked to write to a dead block, on the other hand, it can do the remapping, write to the reserved block, and nobody will ever know the difference.
It's rather counterintuitive until you think it through (or better yet, get a bad block and try it!). My intuition was that writing is "harder" on a flaky disk than reading, when in fact it's much easier for the disk to cope with a problem writing. Similarly, a problem reading is much less likely to signal a dying disk than a problem writing. A problem reading just means that there is one bad block somewhere on the disk; a problem writing probably means that all of the reserved blocks are used up (having been mapped to other bad blocks), so there's nowhere left to write.
Ok, what about that comment is "oddly prescient"? Does the submitter not
understand what "prescient" means; does he not understand the comment; or
(the most generous interpretation I can find) is he merely noting that Joy
foresaw--not anything that has passed in reality--but further science-fiction
doom-saying?
The GPL does not require the ability to redistributed "arbitrarily" derived works. That would imply that any derived work can be redistributed. But it can't. Specifically, if the derived work includes patent incumberences, then it can't be distributed.
That's exactly what I'm saying. But the original poster--and, more importantly, the FSF--seem to look at it the other way. That is, if some recipient might not be able to exercise all his GPL rights, you can't distribute under the GPL at all.
I can't come up with a consistent reading of section 7 that makes any sense. Some have said it's only about ensuring that recipients can redistribute. But that would be strange, because the GPL considers the freedom to redistribute, without the freedom to distribute derivative works, insufficient. Besides, that's not what the FSF argues in the link I gave.
So my conclusion is that the example in section 7 is simply bogus and should be ignored. You don't have to worry about what laws, licenses, and contracts bind the recipients in order to distribute under the GPL.
Okay, so it's possible to misinterpret the language in the GPL to make a
logical contradiction. That doesn't make it any less a misinterpretation,
and since the *intent* of the words which are there are spelled out very
clearly
Ok, as I said to someone else, I basically agree--except that the FSF seems
to say otherwise in their position on the
proposed W3C patent policy. So I think that the FSF is pushing the
contractory viewpoint. Specifically, they are saying that modifications
other people may make (that step outside the "field-of-use" license) are
your problem.
It seems pretty clear to me that your obligations in section 7 are toward
certifying the unlimited redistributability of code *you distribute*.
I can't see why you say that. The only part that is specific to
redistribution is the "for example". Section 7 as a whole seems aimed at
ensuring that recipients have all the rights granted by the GPL,
which includes redistribution but also distribution of derived works. Why
do you think it applies only to redistribution?
Since the GPL is a redistribution license and not a contract, there
really isn't anything at all *legally* to stop SCO from exercising any
patents they might have.
As I said to someone else, I think that SCO's past distribution of Linux
implied a perpetual license to the patent. But IANAL.
if I squint and read the passage over repeatedly, I think I understand what you're getting at
I appreciate your effort.:-)
You're reading this as saying that I must take responsibility for all those who might receive the application
Exactly--or rather, that section 7 claims you must take this responsibility. Which is absurd. So I conclude that "section 7 doesn't fly".
Read in the context of the first sentence, the more likely interpretation of the example is: if the court tells me I'm allowed to give away the software, but I have to impose additional conditions on people who don't receive the software directly from me (those who receive the software "indirectly") then I'm not allowed to distribute the software at all.
This is utterly sensible. It just doesn't seem to agree with the "for example". Maybe I'm misreading the "for example", but it seems pretty unambiguous to me. Anyway, I would be happy to agree with you and ignore the example as non-normative, except...
The real context for my criticism is the FSF's claims regarding the proposed W3C patent policy. Their position seems clearly to assume the "strong" interpretation of the example. (I have emailed the FSF about this and gotten no reply.)
This issue doesn't have much bearing on the SCO story (which I probably should have stated up front). At least, not for Americans, who wouldn't be able to distribute Linux without a patent license from SCO, plain and simple. Though the strong reading of section 7 would imply that even those outside the jurisdiction of the patent could not distribute under the GPL.
Not necessarily true. IF SCO is doing the rumored patent attack, then they lose their GPL distribution rights. That's all.
You may possibly be right. But I believe a court would find that SCO's past distribution of Linux implied a (perpetual) license to their patents. So we can go on distributing Linux royalty-free under that license.
If a court ruled otherwise, the situation would be as you say.
While the GPL in general requires that the code can be arbitrarily modified, that's not the language of this particular clause. You're reading something in that just isn't there. This clause simply says "royalty free".
First of all, the quoted clause was a "for example". So it is clearly an instance of a more general principle. If you read the whole paragraph, it is clear that the general principle is that all recipients must be able to exercise all of the rights granted by the GPL. If you don't agree, tell me what is the general principle of which the "for example" is an instance. The logic is fuzzy here, but that is the only way I can read it. For reference, here is the paragraph:
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
Second,
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
So it doesn't make any sense for section 7 to apply to only some of the rights (ie, the right to redistribute) granted by the GPL.
Since the only part of section 7 that refers specifically to redistribution is a "for example", I can only include that the intent of the whole section is that it apply to all rights granted by the GPL. This of course includes distribution of derived works.
Sorry (sort of) to turn this into a GPL thread, but I have a major beef with
section 7.
For example, if a patent license would not permit
royalty-free redistribution of the Program by all those who receive copies
directly or indirectly through you, then the only way you could satisfy both
it and this License would be to refrain entirely from distribution of the
Program.
But the GPL requires not only the freedom to redistribute, but to distribute
arbitrary derived works. So really, the above should read "... would not
permit royalty-free distribution of arbitrary derived works". But this is
clearly nonsense: If I added one-click shopping to GNU ls, I would not have
a license to distribute the result. So by section 7, nobody can distribute
GNU ls under the GPL.
There are many other scenarios in which the claims of section 7 are rendered
absurd. Consider the impact on those outside of the jurisdiction in which
the patent applies; the hypothetical rogue nation that outlaws GPLed
software; the employee whose contract prohibits him from contributing to
certain free software projects. The requirement that "all those who receive
copies directly or indirectly" be able to exercise their GPL rights is
ludicrously onerous.
Regarding the parent's main point: I certainly believe that SCO itself is
prohibited from distributing GPLed software on which it has patents, unless
they also give everyone a free, perpetual license to the patent for GPLed
software. Otherwise, they would not really be giving others the freedoms
that they say (via the GPL) they are giving. Since they have distributed
Linux, that alone is enough to thwart the rumored patent attack.
I was at an informal dinner of 40 or so MIT professors a couple weeks ago.
(My landlord caters the event, and I help him out sometimes because I'm
interested in the restaurant business.) The theme of discussion was the
difficulty foreign students are now having getting visas to come to MIT.
In the company of only their peers and an eavesdropping busboy, the group
was candid and unguarded. Almost everyone had a story of a student who had
been hindered by the stricter immegration rules. One expressed doubt that
MIT could "be MIT" under these circumstances. Jerry Sussman--co-author of
"the only good book on computer programming" (quote from a Slashdot favorite
I won't name) and all-around brilliant and creative guy--said he's "been
depressed for the last year". Man, that made me want to cry.
This convinced me that the problem is real,
that it is hampering the advancement of learning--and that it could even
lead to the unseating of the US as the center of the learned world.
A much more plausible "demonstration of loyalty" would be that they make clearcase work better under Linux. Their very cool multi-version filesystem now requires binary kernel modules that only work with certain kernel versions, and are a bit flaky even then (so is the windows version, though the solaris version is stable). I use clearcase every day, but I do without mvfs on my laptop, because it's just not worth the grief. IBM will want clearcase to work smoothly with Linux, and I this pretty much requires that the kernel parts be free software.
They could also bring the disastrous unix GUI to parity with windows.
This is where so many people get it wrong. Making software is not analogous to making buildings. Making software is analogous to designing buildings. (You'll notice that the Design Patterns movement is based on a technique for architects, not builders.)
Exactly. The things that build software are called compilers and interpreters and CPU's. Everything above that level is design.
When you realize this, you appreciate that the software design is a whole other problem than building design.
Or, is 300 pages plenty, provided the information is in there?
Not only is a big book not necessarily better; it is almost invariably worse. For simple reasons: Writing well is difficult. It takes a lot of work for an author--or a team of two or three working closely--to produce 200 quality pages. 1000 quality pages would be a monumental effort that, frankly, nobody's going to put into a book on Visual Basic. Further, concision is a mark of good writing, so when you see a big book, you should wonder, "why were they not able to get this into 200 pages?". Not to mention that a big book takes longer to read, is harder to find things in, and is less convenient to use and carry.
For most technical books, the only ways to get to 1000 pages are to write sloppily, add filler, or employ many authors working independently. The last tends to produce an incoherent whole, and make each author care less about his contribution.
The main exceptions are books with a justifiably large reference section (large because there is truly a lot of valuable material to reference, which is uncommon), and, to some extent, books that have been through several editions, whose authors have put new effort into each edition.
While I appreciate all the work that freeswan has done for us, I am much more confident for the long term in work done by the core Linux networking hackers. The freeswan guys seem much more concerned with making it work (in typical situations) than making it right, with the result that the implementation is horribly klugy.
Two examples are the need for a "nexthop" parameter, when the kernel already has this information in its routing tables; and the need to turn off route filtering. Both make it clear that freeswan is not properly integrated (and if you look at the freeswan docs, you'll see that this general problem been on the "to fix" list for a long time).
The point of Trusted Computing is that, for example, the stock
broker's computer can tell
that it is really talking to the client's computer,
that it is talking to a secure application, not a trojan emulating the protocol,
that the application is running on the operating system it thinks it is running on,
that the computer was booted in secure mode,
that when the user is asked for the password, the user is actually physically present.
There is no way to tell those things without hardware assistance.
This is accurate. However, it is a strange definition of "secure
application". Essentially, you claim that my security requires that only
software approved by the stock broker may talk to the stock broker's server
on my behalf. This is backwards: if it's my security
we're talking about, it's me who ultimately should approve. This
criterion does not require a "trusted" computer.
You could argue that most people are best off trusting only software
approved by the broker. Even if this is true, it does not require "trusted"
computing: I can simply delegate approval to my broker.
The project is going to be written mostly in Python....
I've been meaning to swap some books in Safari and check out the Learning Python... I guess I finally have some reason....
but why is there no code available?
When you learn Python, you'll find that it's high-level, dynamic nature allow you to accomplish a great deal in only a few lines of code. So no code in Python probably contains more functionality than no code in C.
You'll also find that whitespace is an important part of Python syntax. So look closer--that "no code" could contain a lot of significant whitespace.
Re:five years of lost discussions
on
Slashdot Turns 5
·
· Score: 2
Try a google search on your ID or sig.
It's a start, but just that. Google appears to index only full discussions, not individual posts (not sure why, but I've never seen a google hit go to an individual post). So keywords match against all posts (maybe google will prefer hits near your ID on the page...). And you can't filter by all the criteria google groups gives you. A date range is especially useful. What would really rock is to search by author, story keywords, and comment keywords. You know: what was that post I made last year about device drivers, in a story about Linux?
five years of lost discussions
on
Slashdot Turns 5
·
· Score: 5, Interesting
Remember how excited we got about google restoring old usenet archives? It's ironic, then, that old slashdot threads are all but lost. You can find and browse them only with some trouble, and searching is almost hopeless. (Have you ever wanted to find an old post of yours? How successful were you?)
Early slashdot is just as valuable as early usenet, and I think we need to find a way to make it accessible. Isn't there some NNTP gateway code somewhere? Could slashdot export month-old stories for google groups to pick up? I bet the google guys would even help develop a new protocol if necessary.
Most valuable of all would be to establish a mechanism that other web discussion boards could use, and encourage them to make their archives available. Imagine the power of all your favorite weblogs searchable through one interface. This would be a boon for users and net historians alike.
And in the future, we'll fight wars by running simulators and sending the appropriate number of people into a death chamber.
An much as we all like "cyberspace", meatspace has some useful properties as well, which allows us to do some things in reality that we can't easily do on the Internet. This plan attempts to mimic the real world in an entirely superficial--and therefore useless--way. I expect it's possible to duplicate something like the dynamic of a live protest on-line, but it will take much more infrastructure than this.
a hard effort to lessen the amount of thingies stuck in the preferences panel
The options don't all have to go into the standard preferences panel (at least not at first). The mozilla developers resist even adding the hooks in the code. At very least, they should add the hooks, so that integrators can tweak them, and outside developers can experiment with ways to control them. But more productive, IMO, would be for the mozilla developers to tackle the problem of exposing customizability to the end-user in friendlier ways. They can't duck this issue forever.
There's definitely a philophy in some folks that "less is more", pick one way and live with it.
This philosophy seems to dominate the discussions I've heard, at least on the side of the core developers. One hears this in GNOME circles as well. It's been taken too far and now hinders usability.
Actually, the keyboard could have been much more useful, like in Opera.
What you wrote is what I really wanted to say. I was just worried that I would get hordes of replies along the lines of, "You want to make single-letter shortcuts?! What terrible usability! Think of the beginners!". Somehow, this justifies taking over the entire keyboard for one shortcut.
A while ago, I posted a wish for vim-style keyboard bindings. Man, would that make my browsing fly!
Regarding the direction of wheel movement when resizing text in Mozilla, I think it's more intuitive that way. It feels more like I'm 'pulling' the text towards me.
I can see that, actually. You might also think of it as a "zoom" operation, so scrolling down makes the eye go down and the text get bigger (never mind that it affects only the text, so it's not truly zoom). But it's hard for me to believe that many people would find this intuitive. Even when I think "zoom", I have to model it consciously in my head before I can decide which way to scroll. Moreover, the feature is called "change text size" (or something like that--not running mozilla ATM), which clearly implies that up should increase the size.
So while I believe you, I think there is a much stronger case for "up means bigger" as the default. I also think it should be customizable, but the mozilla people have decided that software, the most malleable stuff we can create, should not be adaptable to the user.
It's about time that the keyboard became useful during browsing! I see no
reason why I shouldn't be able to navigate with the keyboard in a browser as
easily as I can in a text editor. Hopefully (I haven't tried it yet), this
is a step in that direction.
However, I'm slightly concerned about the description
of this feature. I gather this appeared in IE, and I fear that mozilla is
more concerned with "parity" than with the most usable implementation. (Do
you realize that when using the mouse wheel to change text size, going up
makes the text smaller? Copied from IE. Won't fix. Bug 146491)
It appears to start searching as soon as you type a letter. This rules out
all other possible uses for the letter characters. All of the most
accessible keys on the keyboard "used up", just to avoid having to hit a
command key to start searching in links. Even though you already have to
hit a command key ("/") to search in the full text. If we want more
keyboard functions, only punctuation keys (or key combinations) are
available. For example, to seach for "foo" I can type "/foo", but to get
the next hit, I have to do Ctrl-G, instead of something convenient like "n".
This seems shortsighted.
Well, I'll have to try it before I can be sure of my criticism, but from
what I understand, this feature could become much more powerful if the
implementors design it well, instead of merely copying IE.
I'm writing because I cannot understand some parts of the "FSF's Position on Proposed W3 Consortium 'Royalty-Free' Patent Policy", at http://www.gnu.org/philosophy/w3c-patent.html .
First, it is quite clear that you believe that software exercising patents with "field-of-use" licenses cannot be distributed under the GPL. However, it is not clear whether you believe that such software could be distributed as free software at all. Paragraph two seems to say that it could not, but it also appears to conflate GPLed software with free software, so I am not sure this is what the author meant. Paragraph three equivocates by saying "licensing under other free software licenses does not imply free", without saying "licensing under other free software licenses implies not free".
The impact of the proposed policy on the free software community obviously depends greatly on whether it could prevent us from implementing some standards at all, or only under the GPL. Which is it? (Since most of the document focuses on the GPL, I assume it is the latter. But it should be stated explicitly, and the hints to the contrary should be cleaned up.)
Second, who exactly would be prevented from distributing software exercising such patents under the GPL? Those in jurisdictions in which the patent applies, or everyone?
Third, why exactly are "field-of-use" patents incompatible with the GPL? The addendum intended to clarify this matter does not succeed. Step 4 in its example says,
But C's patent equally prohibits folks from taking a (hypothetical) GPLed search engine and adding URL parsing code. So by that argument, nobody can distribute a GPLed search engine, either. What really is the criterion that prevents distribution under the GPL? Is it that the author "knows" that others will be "tempted" to modify the software such that it no longer meets the "field-of-use" restriction? Is it that the author has accepted the patent license himself?And how does this differ from the situation of distributing GPLed software that cannot be used in some jurisdictions? If I distribute cryptographic software under the GPL, it will end up in the hands of people in repressive countries who are not allowed to use (never mind redistribute) it. This would seem to imply that such software cannot be distributed under the GPL.
I hope you can answer these questions and update the text on your web site.
What happens here is actually really simple. When the drive notices a dead or dying block, it can use one of its "reserved" blocks instead, and enter the substitution into a table somewhere. Except in one case: When asked to read from a dead block, it can't just return bogus data: it has to admit that there was an error. When asked to write to a dead block, on the other hand, it can do the remapping, write to the reserved block, and nobody will ever know the difference.
It's rather counterintuitive until you think it through (or better yet, get a bad block and try it!). My intuition was that writing is "harder" on a flaky disk than reading, when in fact it's much easier for the disk to cope with a problem writing. Similarly, a problem reading is much less likely to signal a dying disk than a problem writing. A problem reading just means that there is one bad block somewhere on the disk; a problem writing probably means that all of the reserved blocks are used up (having been mapped to other bad blocks), so there's nowhere left to write.
Ok, what about that comment is "oddly prescient"? Does the submitter not understand what "prescient" means; does he not understand the comment; or (the most generous interpretation I can find) is he merely noting that Joy foresaw--not anything that has passed in reality--but further science-fiction doom-saying?
That's exactly what I'm saying. But the original poster--and, more importantly, the FSF--seem to look at it the other way. That is, if some recipient might not be able to exercise all his GPL rights, you can't distribute under the GPL at all.
I can't come up with a consistent reading of section 7 that makes any sense. Some have said it's only about ensuring that recipients can redistribute. But that would be strange, because the GPL considers the freedom to redistribute, without the freedom to distribute derivative works, insufficient. Besides, that's not what the FSF argues in the link I gave.
So my conclusion is that the example in section 7 is simply bogus and should be ignored. You don't have to worry about what laws, licenses, and contracts bind the recipients in order to distribute under the GPL.
Ok, as I said to someone else, I basically agree--except that the FSF seems to say otherwise in their position on the proposed W3C patent policy. So I think that the FSF is pushing the contractory viewpoint. Specifically, they are saying that modifications other people may make (that step outside the "field-of-use" license) are your problem.
It seems pretty clear to me that your obligations in section 7 are toward certifying the unlimited redistributability of code *you distribute*.
I can't see why you say that. The only part that is specific to redistribution is the "for example". Section 7 as a whole seems aimed at ensuring that recipients have all the rights granted by the GPL, which includes redistribution but also distribution of derived works. Why do you think it applies only to redistribution?
Since the GPL is a redistribution license and not a contract, there really isn't anything at all *legally* to stop SCO from exercising any patents they might have.
As I said to someone else, I think that SCO's past distribution of Linux implied a perpetual license to the patent. But IANAL.
I appreciate your effort. :-)
You're reading this as saying that I must take responsibility for all those who might receive the application
Exactly--or rather, that section 7 claims you must take this responsibility. Which is absurd. So I conclude that "section 7 doesn't fly".
Read in the context of the first sentence, the more likely interpretation of the example is: if the court tells me I'm allowed to give away the software, but I have to impose additional conditions on people who don't receive the software directly from me (those who receive the software "indirectly") then I'm not allowed to distribute the software at all.
This is utterly sensible. It just doesn't seem to agree with the "for example". Maybe I'm misreading the "for example", but it seems pretty unambiguous to me. Anyway, I would be happy to agree with you and ignore the example as non-normative, except ...
The real context for my criticism is the FSF's claims regarding the proposed W3C patent policy. Their position seems clearly to assume the "strong" interpretation of the example. (I have emailed the FSF about this and gotten no reply.)
This issue doesn't have much bearing on the SCO story (which I probably should have stated up front). At least, not for Americans, who wouldn't be able to distribute Linux without a patent license from SCO, plain and simple. Though the strong reading of section 7 would imply that even those outside the jurisdiction of the patent could not distribute under the GPL.
You may possibly be right. But I believe a court would find that SCO's past distribution of Linux implied a (perpetual) license to their patents. So we can go on distributing Linux royalty-free under that license.
If a court ruled otherwise, the situation would be as you say.
First of all, the quoted clause was a "for example". So it is clearly an instance of a more general principle. If you read the whole paragraph, it is clear that the general principle is that all recipients must be able to exercise all of the rights granted by the GPL. If you don't agree, tell me what is the general principle of which the "for example" is an instance. The logic is fuzzy here, but that is the only way I can read it. For reference, here is the paragraph:
Second,
So it doesn't make any sense for section 7 to apply to only some of the rights (ie, the right to redistribute) granted by the GPL.Since the only part of section 7 that refers specifically to redistribution is a "for example", I can only include that the intent of the whole section is that it apply to all rights granted by the GPL. This of course includes distribution of derived works.
But the GPL requires not only the freedom to redistribute, but to distribute arbitrary derived works. So really, the above should read "... would not permit royalty-free distribution of arbitrary derived works". But this is clearly nonsense: If I added one-click shopping to GNU ls, I would not have a license to distribute the result. So by section 7, nobody can distribute GNU ls under the GPL.
There are many other scenarios in which the claims of section 7 are rendered absurd. Consider the impact on those outside of the jurisdiction in which the patent applies; the hypothetical rogue nation that outlaws GPLed software; the employee whose contract prohibits him from contributing to certain free software projects. The requirement that "all those who receive copies directly or indirectly" be able to exercise their GPL rights is ludicrously onerous.
Regarding the parent's main point: I certainly believe that SCO itself is prohibited from distributing GPLed software on which it has patents, unless they also give everyone a free, perpetual license to the patent for GPLed software. Otherwise, they would not really be giving others the freedoms that they say (via the GPL) they are giving. Since they have distributed Linux, that alone is enough to thwart the rumored patent attack.
You're saying your company can't manage a project for crap, so the H1B program needs reform?
In the company of only their peers and an eavesdropping busboy, the group was candid and unguarded. Almost everyone had a story of a student who had been hindered by the stricter immegration rules. One expressed doubt that MIT could "be MIT" under these circumstances. Jerry Sussman--co-author of "the only good book on computer programming" (quote from a Slashdot favorite I won't name) and all-around brilliant and creative guy--said he's "been depressed for the last year". Man, that made me want to cry.
This convinced me that the problem is real, that it is hampering the advancement of learning--and that it could even lead to the unseating of the US as the center of the learned world.
They could also bring the disastrous unix GUI to parity with windows.
Exactly. The things that build software are called compilers and interpreters and CPU's. Everything above that level is design.
When you realize this, you appreciate that the software design is a whole other problem than building design.
Not only is a big book not necessarily better; it is almost invariably worse. For simple reasons: Writing well is difficult. It takes a lot of work for an author--or a team of two or three working closely--to produce 200 quality pages. 1000 quality pages would be a monumental effort that, frankly, nobody's going to put into a book on Visual Basic. Further, concision is a mark of good writing, so when you see a big book, you should wonder, "why were they not able to get this into 200 pages?". Not to mention that a big book takes longer to read, is harder to find things in, and is less convenient to use and carry.
For most technical books, the only ways to get to 1000 pages are to write sloppily, add filler, or employ many authors working independently. The last tends to produce an incoherent whole, and make each author care less about his contribution.
The main exceptions are books with a justifiably large reference section (large because there is truly a lot of valuable material to reference, which is uncommon), and, to some extent, books that have been through several editions, whose authors have put new effort into each edition.
Two examples are the need for a "nexthop" parameter, when the kernel already has this information in its routing tables; and the need to turn off route filtering. Both make it clear that freeswan is not properly integrated (and if you look at the freeswan docs, you'll see that this general problem been on the "to fix" list for a long time).
There is no way to tell those things without hardware assistance.
This is accurate. However, it is a strange definition of "secure application". Essentially, you claim that my security requires that only software approved by the stock broker may talk to the stock broker's server on my behalf. This is backwards: if it's my security we're talking about, it's me who ultimately should approve. This criterion does not require a "trusted" computer.
You could argue that most people are best off trusting only software approved by the broker. Even if this is true, it does not require "trusted" computing: I can simply delegate approval to my broker.
I've been meaning to swap some books in Safari and check out the Learning Python... I guess I finally have some reason....
but why is there no code available?
When you learn Python, you'll find that it's high-level, dynamic nature allow you to accomplish a great deal in only a few lines of code. So no code in Python probably contains more functionality than no code in C.
You'll also find that whitespace is an important part of Python syntax. So look closer--that "no code" could contain a lot of significant whitespace.
It's a start, but just that. Google appears to index only full discussions, not individual posts (not sure why, but I've never seen a google hit go to an individual post). So keywords match against all posts (maybe google will prefer hits near your ID on the page...). And you can't filter by all the criteria google groups gives you. A date range is especially useful. What would really rock is to search by author, story keywords, and comment keywords. You know: what was that post I made last year about device drivers, in a story about Linux?
Early slashdot is just as valuable as early usenet, and I think we need to find a way to make it accessible. Isn't there some NNTP gateway code somewhere? Could slashdot export month-old stories for google groups to pick up? I bet the google guys would even help develop a new protocol if necessary.
Most valuable of all would be to establish a mechanism that other web discussion boards could use, and encourage them to make their archives available. Imagine the power of all your favorite weblogs searchable through one interface. This would be a boon for users and net historians alike.
An much as we all like "cyberspace", meatspace has some useful properties as well, which allows us to do some things in reality that we can't easily do on the Internet. This plan attempts to mimic the real world in an entirely superficial--and therefore useless--way. I expect it's possible to duplicate something like the dynamic of a live protest on-line, but it will take much more infrastructure than this.
The options don't all have to go into the standard preferences panel (at least not at first). The mozilla developers resist even adding the hooks in the code. At very least, they should add the hooks, so that integrators can tweak them, and outside developers can experiment with ways to control them. But more productive, IMO, would be for the mozilla developers to tackle the problem of exposing customizability to the end-user in friendlier ways. They can't duck this issue forever.
There's definitely a philophy in some folks that "less is more", pick one way and live with it.
This philosophy seems to dominate the discussions I've heard, at least on the side of the core developers. One hears this in GNOME circles as well. It's been taken too far and now hinders usability.
What you wrote is what I really wanted to say. I was just worried that I would get hordes of replies along the lines of, "You want to make single-letter shortcuts?! What terrible usability! Think of the beginners!". Somehow, this justifies taking over the entire keyboard for one shortcut.
A while ago, I posted a wish for vim-style keyboard bindings. Man, would that make my browsing fly!
I can see that, actually. You might also think of it as a "zoom" operation, so scrolling down makes the eye go down and the text get bigger (never mind that it affects only the text, so it's not truly zoom). But it's hard for me to believe that many people would find this intuitive. Even when I think "zoom", I have to model it consciously in my head before I can decide which way to scroll. Moreover, the feature is called "change text size" (or something like that--not running mozilla ATM), which clearly implies that up should increase the size.
So while I believe you, I think there is a much stronger case for "up means bigger" as the default. I also think it should be customizable, but the mozilla people have decided that software, the most malleable stuff we can create, should not be adaptable to the user.
However, I'm slightly concerned about the description of this feature. I gather this appeared in IE, and I fear that mozilla is more concerned with "parity" than with the most usable implementation. (Do you realize that when using the mouse wheel to change text size, going up makes the text smaller? Copied from IE. Won't fix. Bug 146491)
It appears to start searching as soon as you type a letter. This rules out all other possible uses for the letter characters. All of the most accessible keys on the keyboard "used up", just to avoid having to hit a command key to start searching in links. Even though you already have to hit a command key ("/") to search in the full text. If we want more keyboard functions, only punctuation keys (or key combinations) are available. For example, to seach for "foo" I can type "/foo", but to get the next hit, I have to do Ctrl-G, instead of something convenient like "n". This seems shortsighted.
Well, I'll have to try it before I can be sure of my criticism, but from what I understand, this feature could become much more powerful if the implementors design it well, instead of merely copying IE.
Given how strenuously they emphasize that it's "free as in freedom", I don't think you can justify this accusation.
As for the examples you gave, "libre" is not English, and "GNU/free" is not a word. Both pretty significant disadvantages.