Let me preface this with the fact that I am not a Briton (I'm American, though of British ancestry), and that I was born after Britain went decimal. That said, I don't think it's as hard as you're making it out to be. Though the U.S. has used decimal currency from its inception, we still use "English" measurements (which are the same as Imperial for distance, area, and weight, but slightly different for liquid and dry capacity) over here, and we do just fine with them (even the more obscure one like rods, which are still used by surveyors, etc.).
A £10 bill divided four ways is £2½ under any system. The way I was taught to divide such units, instead of turning pounds into pence at the outset, you would figure out the integral part (the pounds), and then turn the fractional part only into smaller units: first shillings, then pence if it didn't go evenly into shillings. In this case, since £½ = 10s, there is never any need to translate into pence at all. If dividing three ways, however, the old system is easier, since three-and-a-third pounds can only be approximated in decimal to £3.33 (one of the three having to pay the remaining 1p in addition); while previously three-and-a-third pounds were £3/6s/8d exactly. For six ways, the old system yields one-and-two-thirds pounds, or £1/13/4, whereas approximating to £1.66 leaves a whole 4p to be accounted for (1.66 * 6 = 9.96).
The advantage of the old system, then, was that even division was much easier, since 240 is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 40, 48, 60, 80, and 120; instead of only 2, 4, 5, 10, 20, 25, and 50 (as 100 is). This means that is actual use, division is more often easier rather than more difficult under the old system. It's not the necessity of using fractions that is the problem in the new system (that's the case in any system) it's the inability to divide exactly by three, six, eight, or twelve - very common divisors to encounter. The old system had the advantage of being divisible by those as well as by five and ten.
It's the same way with distances. When I do carpentry work, for instance, I use feet, inches, and binary subdivisions of inches. In actual use, I find this far easier than the metric system, because (for various reasons) dividing by five or ten isn't nearly as common as dividing by three or six.
I'd also like the window management protocol on X11 to provide some features that are missing, that would *also* allow for applications to provide functionality that their users actually need without having to override the window manager. Why does the idea of adding features that would benefit users produce so much pushback?
As long as it is possible for the WM to ignore the app (e.g., in cases where the user has set specific settings for that app in the WM configurations), then I don't see any reason why window managers shouldn't be able to support that.
Yes, I do. I've been using slightly different language, but wasn't trying to dispute the core of your point. It's a matter of semantics, so I won't argue it further.
The fact that the default UI on the Mac isn't based on X11 has nothing to do with whether it's a desktop UNIX system or not.
When did I say that it did? Of course MacOS is a desktop Unix system. However, it happens to ship with a GUI that lacks the functionality (or at least the flexibility) of another GUI that is also available for Unix.
A VMS system running X11 isn't a VMS system with a UNIX user interface, it's not a combination of VMS and UNIX, it's a VMS system with an X11-based user interface.
Of course. I wasn't trying to say anything else. Nothing in the world could make a VMS system into a Unix system.
[Mac is] the most successful desktop UNIX. It may repay you to seriously think about why that is (and, no, it's not just marketing).
I am more than content to have it stay that way. I want X11 (not just support for X11 apps) on my desktop. For those who don't, there's MacOS. X11 is not a superior choice on the desktops of neophytes, or even those who simply don't enjoy (or have the time for) tinkering. Those of us who do enjoy tinkering may find X11 superior to MacOS for our needs. Which is why it get irritating when certain app's refuse to obey the WM configurations that we have carefully set.
The X11 user interface is not a "UNIX" user interface. It's a portable multi-platform user-interface that's popular on UNIX.
Now who's being silly? X is a UI designed for Unix and VMS, that makes it a Unix UI. Is is a part of Unix? Of course not. I didn't say it was a first-party UI. X, NeWS, NeXTstep, and the Mac GUI are all Unix interfaces in that they can be used as interfaces to Unix. That's the same as saying that they are all (coincidently third-party) interfaces that run on Unix (among other systems). I certainly wasn't trying to argue that the command line isn't the native UI for Unix.
BTW, I use the command line quite a bit, but I also like to have graphics support (without relying on the fundamentally broken svgalib*), and I happen to enjoy the tinkering that X allows and the MacOS GUI doesn't.
You might as well argue that HTTP and HTML are "UNIX" interfaces....
I would say that HTTP can be considered a Unix interface, since it can be used to interface with a Unix machine. The same for any communications protocol that Unix supports. For that matter, it's also a Windows interface and a VMS interface.
...even extremely divergent shells don't differ as much as X11 window managers do. The fundamental breakthroughs (and they were breakthroughs) that UNIX introduced at the command line level are shared by all by the most arcane shells.
As long as we're both splitting hairs:) I'll point out that the comparison is not apt because window managers aren't an interface at all. Windows managers are essentially a helper app that runs on top of X so that the user doesn't have to manage windows manually. Furthermore, the fact that the shells are similar in several fundamentals just makes them several very similar, but still distinct UI's.
You start up "Terminal.app" and it's done. Seriously. X11 IS NOT UNIX The UNIX user interface is the command line.
Yes, but if I want a more-flexible GUI, such as X11, instead of the MacOS GUI, then things get substantially more complex. The Unix CLI is one Unix UI*, X is another, the Mac GUI is a third.
Unfortunately, Trolltech is increasingly replacing the UNIX API in Qt with a higher level abstraction to divorce Qt apps from the UNIX OS. Even the option of running Qt-based apps headless is going to vanish.
Which will probably mean that I won't install Qt-based app's anymore. The only one I have used any great amount is Opera, anyway. I'm already pretty picky about not installing widget-dependent app's unless I really need them. There's actually still pretty good choice out there, thankfully, if I don't mind using a less popular app.
* Technically, the Unix CLI is several UI's, given the choice of shells.
It's irrelevant how you perceive how the UCB and *BSD projects have conducted themselves over N years. They are free to allow more liberal usage of their code licensed. Just because a project who uses a BSD license has a liberal policy that might not be as controlling as a legal interpretation of the license terms doesn't change the legal reading of the BSD license terms.
No, it's quite relevant. It's not about enforcement policy, it's about what the most common legal interpretation of the license is. These entities have lawyers in their employ, and their interpretation is critical to knowing what the license means, especially since UCB wrote the license. If your interpretation is correct, why haven't they at least told the *BSD projects to stop amending the copyright on files derived from original *BSD code? Lax enforcement can lead to loss of rights, as AT&T learned at the hands of UCB/BSDi, years ago. The *BSD projects aren't interpreting the license one way and enforcing it another, either. They wouldn't have amended the copyright unless they had legal opinions in favour. "Retain" can mean multiple things, as most any lawyer will say. I say again: the consistent, legal interpretation, for over twenty years, has been that "retain" simply means "don't remove." The fact is that you are virtually alone in your interpretation of the BSD license.
At any rate, your language with regard to the FSF (as much as I partly agree with you), continued arguing of points not in dispute (e.g., the matter of non-derivative works), continued refusal to admit that the meaning of "retain" is, at the very least, vague, and continued diatribes against the GPL when you've made the BSDL into virtually the same exact thing, are making you come off like a troll at this point. This is why I dumped debian for FreeBSD: to get away from the constant license zealotry, which was at the point of holding up the release cycle.
The license says you can't change the license, including preventing you from changing it's license terms.
No, it says you must "retain" the license terms and the "above" copyright. You have no more right to amend the copyright than you have to add to the license terms. As you yourself said, further up thread, under U.S. copyright law the ownership of derivative works is dependent on the license the original code was issued under. If the BSD license does not allow amending the copyright - and if it does not allow adding to the license terms, then this must be the case (because the same word "retain" governs both) - then the author of the original work holds sole claim to the derivative work. You can't have it both ways.
You still refuse to address the fact that UCB and the *BSD projects have conducted themselves for over 20 years in a way which is at odds with your reading of the license. Unless you can show me where they take your position on that issue, I will consider my position secure.
Again I say that you read more into the license than is there. You can "retain this list of conditions" and add another one to it. As long as those conditions are still there, then "this list" is still there. "This list" is no different from saying "these conditions" - it's not in exclusive language, and had that been the intent this would be a very badly written license.
You've deemphasized the part about "the above copyright notice," but it's essential to understanding the meaning of the license. You can't argue that "retain" applies in an exclusive manner (prohibiting additions) to the license terms, but an inclusive manner (permitting additions) to the copyright. Either it means you are permitted to add attributions and terms, or are prohibited from adding either. Don't tell me that "this list" is somehow more restrictive than "the above...notice." If it is clear then, from over two decades of use, that the provision in regard to the copyright notice is inclusive, then it must logically also be inclusive with regard to the list of conditions.
Furthermore, you ignore my main point: that, in more than two decades of use, no one from either UCB or the *BSD projects has maintained this reading you propose. I say again, that if this were what the license terms meant by "retain," then it applies just as much to "the above copyright notice," as it does to "this list of conditions." In which case, the *BSD projects have themselves violated the license. Claims like that would put BSD right back into the legal Limbo it was in in 1992. Since I don't see UCB claiming that (thank Heaven), then I am going to continue believing that your interpretation is different from UCB's.
And that is the kicker, because if your reading is correct, then the only entity with any standing to bring a claim with regard to the lion share of BSDL software is UCB, because they will have retained copyright to not only the code up through 4.4BSD, but anything and everything derived from that code.
[Microsoft, et all] don't have to publish the original code they used or versions that have their modifications in it. They are free to do what they do with it.
But they do distribute said code, even if it is under NDA. The license says "distribute" not "publish." Furthermore, following your line of logic, the BSDL should apply to their entire work, too, because they still have to provide the copyright notice, license terms, and disclaimer of warranty in the documentation. The license certainly doesn't say that they can add additional terms there, either.
I think we're not in agreement on what "retain" means. Since the license says only "retain," and not "retain exactly," I tend to believe that it merely means "don't remove." You are maintaining that "retain" means "don't add anything either." If it actually said "retain exactly" I might be inclined to agree with you.
Obviously, the author has the right to determine who may make a derivative work. I don't dispute that. The author of BSD-licensed code allows anyone to make a derivative work, provided that: if they distribute the code, they "retain" the copyright notice, license terms, and disclaimer of warranty that were on the original; and if they distribute binaries, they provide the same notice, terms, and disclaimer with the documentation. It's what these thing apply to that we disagree on. The consensus opinion, and the clear intent of the people at UCB who wrote the license in the first place, has been that these things, when appearing in the derivative work, apply only to those parts which belong to the original work, and not to the derivative work as a whole. You appear to be claiming that the BSD license (and by logical extension, BTW, the original author's copyright*) continues to apply to the derivative work as a whole, which would make it a viral license.
Show me a case where one of the CSRG people has agreed with your reading. Remember, the intent of the license issuer is usually taken into account, as well as the letter of the license. Nothing I have seen has ever indicated that UCB had any intention to retain ownership over derivative works, or to force derivative works to be distributed under the BSD license. If this had been their intent, it would have come up in the AT&T case (it would have made the University's counterclaims much stronger), but the only thing that came up there was AT&T removing the UCB copyright, etc. Furthermore, if your reading is correct, it is not only the license terms which cannot be changed, but the copyright notice, in which case the *BSD projects have also violated the license by adding their own names to that of the Regents of the University of California, Berkeley in the copyright notices.
As I said before, I strongly suspect that before we saw lawsuits over this get very far, we would see UCB re-write the license to rectify the situation (just as they did when the advertising clause became an issue). Most BSD users do not want to see a war with the FSF, especially if it means becoming just like them.
* That the copyright may do this anyway in some jurisdictions (e.g., Germany), I do not dispute. That it does so as a consequence of the word "retain" in the BSDL, I do dispute. In fact, I strongly suspect that the license would have been written differently, so as to explicitly disclaim ownership over derivative works, had the lawyers at UCB been thinking about non-U.S. jurisdictions.
I wasn't meaning to confuse X11 with Unix. However, I would not necessarily agree that MacOS isn't dumbed down, since it seems to make it difficult for the user to get around the limitations of the user-friendly UI. It's a far cry from MacOS 9 and earlier, but it still apparently lacks some of the flexibility of X11 (or so I hear from people I know who actually use Macs regularly).
As you say, free Unix is "stuck" with X11. I'm not certain, though, that what you say are flaws need to be considered as such. If a different window manager would fix said "flaws" then they are not flaws in X, but in the available window managers. A "standard" WM is something I'd rather avoid, though. The best part of X is that there is choice in window managers. Non-technical users can use one thing, while those of us who prefer a challenge can use something different. A "standard" WM almost has to be dumbed down, to accommodate non-technical users. As far as I am concerned, I don't have a problem with apps giving hints to the WM as long as there is a way for the user to override those hints in the WM configurations (not in the app settings).
Personally, I'm sick of software that requires X11, even if you only want to install the command line version, so the irony is thick enough to slice.
Agreed. That sort of thing is inexcusable. At the very least, X-support should be a pre-compilation option, and binary distributions should be available in both flavours. Of course, my other pet peeve is toolkit-dependent apps (of which the GIMP is one of many). I'm not saying there shouldn't be a GTK frontend, for those who want it, but I really wish there were an Xt one as well. I don't use GNOME or KDE because of their bloat, and don't really think I should need GTK and/or Qt support.
Quite right. I'm not sure what I was thinking before (other than that I was tired). I concede the point. If someone wants to call German copyright viral (assuming the prior characterization of its nature is correct), then, I won't object any more.
I suppose this is why some of the die-hard-FSF fanatics (including RMS) have gotten irritated when people have released GPL'd code and haven't assigned the copyright to said code to the FSF (as in the case of XEmacs or Linux).
[Sorry for the double-post. I accidentally posted in HTML on reflex after writing the other one, and previewing it, in plain text because I was lazy. I never do this, but it would be absolutely Hellish to read that way, so here it is again.]
Wouldn't that preclude including BSD code in proprietary software just as much as including it in GPL software? If so, then that reading of the license is certainly not the understanding of the people who issued it in the first place. If that were the case, why hasn't UCB sued the pants off of Microsoft, Sun, or Apple? Don't tell me they don't redistribute in source form, either, because they do, albeit under a NDA. Besides, binary distributions have to present all these things in the "documentation or other materials" supplied by the vendor. The consistent understanding of the BSD license for two decades has been that derivative works could be licensed under different terms from the original code, so long as the copyright notice, license terms, and disclaimer of warranty pertaining to the original code were retained as well.
You are reading things into the license that aren't there. The fact that you must "retain" the license terms does not preclude you from adding new ones - pertaining only to the derivative work, as long as you can actually assert copyright over the derivative work. No where does the BSDL say that modified code must be distributed under "these exact license terms and no others," only the GPL does that. It says the license terms must be "retained," which simply means that you must not remove them, in acknowledgment of the rights of the author of the original code. If your interpretation of the license were correct, I would expect the majority of *BSD users to be clamoring to their respective projects and to UCB for the license to be changed to conform to what the intent was, rather than take the path of the FSF, and I expect it would happen, too.
If we start insisting that people who write derivative works based on the BSDL have to license their code as BSDL as well, then we become no better than the GNU crowd. In fact, we become worse by decrying their viral license while not being able to decide whether ours is or isn't. We become hypocrites and fence-sitters. The beauty of the BSDL is that it doesn't shackle the author of a derivative work. German and French copyright law may, but since I am neither a French nor a German citizen, there's not much I can do about that. If we loathe the GPL so much, then we have to preserve everything about the BSDL which makes it unlike the GPL. Otherwise, we are cutting off our nose to spite our face.
This isn't what the argument in this case is about, anyway. According to the mail logs that were posted, the argument here is, as I said before, about A) people asserting copyright over non-derivative works, B) the fact that, in this case, the ownership of derivative works would belong to the original author anyway, C) based on A & B, people altering asserting copyright over, and altering the license to, code which they didn't own, D) removing the original copyright notice, license terms, and disclaimer of warranty. I have yet to see Theo say anything in those logs which would indicate that, had this been a derivative work based on original code written in the U.S., that the authors of the derivative work couldn't have wrapped the whole thing in GPL, assuming they had retained the copyright notice, license terms, and disclaimer of warranty belonging to the original code.
Wouldn't that preclude including BSD code in proprietary software just as much as including it in GPL software? If so, then that reading of the license is certainly not the understanding of the people who issued it in the first place. If that were the case, why hasn't UCB sued the pants off of Microsoft, Sun, or Apple? Don't tell me they don't redistribute in source form, either, because they do, albeit under a NDA. Besides, binary distributions have to present all these things in the "documentation or other materials" supplied by the vendor. The consistent understanding of the BSD license for two decades has been that derivative works could be licensed under different terms from the original code, so long as the copyright notice, license terms, and disclaimer of warranty pertaining to the original code were retained as well.
You are reading things into the license that aren't there. The fact that you must "retain" the license terms does not preclude you from adding new ones - pertaining only to the derivative work, as long as you can actually assert copyright over the derivative work. No where does the BSDL say that modified code must be distributed under "these exact license terms and no others," only the GPL does that. It says the license terms must be "retained," which simply means that you must not remove them, in acknowledgment of the rights of the author of the original code. If your interpretation of the license were correct, I would expect the majority of *BSD users to be clamoring to their respective projects and to UCB for the license to be changed to conform to what the intent was, rather than take the path of the FSF, and I expect it would happen, too.
If we start insisting that people who write derivative works based on the BSDL have to license their code as BSDL as well, then we become no better than the GNU crowd. In fact, we become worse by decrying their viral license while not being able to decide whether ours is or isn't. We become hypocrites and fence-sitters. The beauty of the BSDL is that it doesn't shackle the author of a derivative work. German and French copyright law may, but since I am neither a French nor a German citizen, there's not much I can do about that. If we loathe the GPL so much, then we have to preserve everything about the BSDL which makes it unlike the GPL. Otherwise, we are cutting off our nose to spite our face.
This isn't what the argument in this case is about, anyway. According to the mail logs that were posted, the argument here is, as I said before, about A) people asserting copyright over non-derivative works, B) the fact that, in this case, the ownership of derivative works would belong to the original author anyway, C) based on A & B, people altering asserting copyright over, and altering the license to, code which they didn't own, D) removing the original copyright notice, license terms, and disclaimer of warranty. I have yet to see Theo say anything in those logs which would indicate that, had this been a derivative work based on original code written in the U.S., that the authors of the derivative work couldn't have wrapped the whole thing in GPL, assuming they had retained the copyright notice, license terms, and disclaimer of warranty belonging to the original code.
Yes, BSD code can be incorporated into a GPL program (Theo wasn't saying it can't be, BTW), but only if A) there are enough changes to qualify as a derivative work and B) the original program wasn't copyrighted in a country (like France or Germany) which grants ownership to derivative works to the author of the original program (in theory, a derivative work can still be licensed GPL then, but only if the original author decides to do so). You can't relicense code you don't own the copyright to, which some people don't seem to understand.
I don't disagree (and yes, I did read the whole thread). You are very right in pointing out that it is German law, not the BSDL which is at least partly at issue here, and I wasn't trying to dispute that. I just wouldn't use the term "viral" for copyright itself. The term viral was first applied to the GPL because of the very "rapacious terms" you mention, which makes it different even from German and French copyright.
There is nothing is German or French copyright law which would prevent the original author from issuing derivative work under a different license than the original, whereas the GPL does just that. It's this assimilation of code that made people call it the "General Public Virus" in the first place.
I think you're spot on about dual licensing. I have often thought that the whole mess might have been avoided if they'd just left the "advertising clause" in (though it had its own problems). At least then, dual licensing would have been impossible, because the 4-clause BSDL is incompatible with the GPL (according to the FSF).
The GPL is never going to abandon its viral nature, because its proponents really believe that they are on a moral crusade. Software has a right to be free, they say. Those of us who think that's a tad silly, and who care more about granting rights to people than to inanimate code, really need to do a good job of promoting the BSD model in the future. It is far more commercially viable, especially with what the FSF is trying to do with GPL v3, and I fear that OSS may suffer if we don't make it clear, especially to the IBM's and HP's of the world and their clients, that this man (RMS) in no way represents us all.
Re:In the name of the user, make the user shave ya
on
The GIMP UI Redesign
·
· Score: 1
Why? The user is not a computer expert. The user is a graphic artist....it's a real hangup, and it has to be accommodated for free UNIX to succeed on the desktop.
If the user isn't willing to develop the level of competence that Unix requires, then the user should probably not be using Unix. I'm not sure if I want Unix to be a success on the desktop if it means we have to dumb the system down.
And yet in X11 THE APPLICATION REQUESTS IT, NOT THE USER. Look up overrideRedirect.
I didn't say the application can't request it (I also wasn't speaking specifically of unmanaged windows, but focus/layering behavior in general), I said that the ideal is for the user to be able to set behavior for individual app in the WM configurations that the app's requests won't override. Ideally, the app shouldn't care what how its window behaves or what it looks like.
Finding a couple years from now that the open source app you're looking at on freshmeat only runs on Windows.
Given that the applications we're talking about were around before the current commercial fad surrounding Linux, I seriously doubt that will happen. Besides, given how sick I am of seeing software that only runs on Linux, and either not natively or not at all on BSD (which is inexcusable - if you're going to write Unix code, make it proper, portable Unix code, without tying it to a particular kernel), it will be nothing new. OSS isn't going to kill Windows. If Windows dies it will be because of its own problems, and it will be to MacOS, not anything else.
Re:In the name of the user, make the user shave ya
on
The GIMP UI Redesign
·
· Score: 1
If the user needs different behavior from different apps, then the user needs the app to be able to specify which behavior it needs.
Rather, IMO, if the user needs different behavior from different apps, then the user needs to specify to the window manager which behavior it needs. Having the app do it is backwards.
Not... by editing a text file,
Honestly, I don't understand what people's hangup about editing config files is. Text files are far more flexible than menus, and often easier to understand. Most users are smarter than we give them credit for, and smarter than they give themselves credit for. After the initial shock, most of them would actually become far more proficient if they just had to use text files for a while and stopped letting the system dumb everything down for them.
And if the user needs the application to request specific behavior (such as not having a title bar) then it can request it.
In such a case, the user should request it himself, without having to go through the app. To have the app request it leads to conflicts, and is more complicated for the user to maintain.
They'll stick to Photoshop on their Wintel boxes and Macs.
Where's the harm in that, anyhow? If someone if more comfortable with a Mac than a more flexible form of Unix, then I wouldn't want them to switch. There is no one-size-fits-all OS. There shouldn't be, either. I try to steer people away from Microsoft, because I think there are significant technical reasons for doing so, but I have advised beginning-to-intermediate computer users to buy a Mac before, because that's what MacOS is good at: coddling newbies. Once such a system is more restricting than you want, you can move on to something more challenging, like BSD or Linux. I don't see a problem with Unix (other than MacOS) being considered a system for advanced users, at least as far as the home desktop is concerned.
You are using "viral" in a different sense from the general use when referring to "viral licenses." The GPL is viral, in the sense that all derivative works must be GPL - no matter who is the owner (even the owner of the copyright is bound to GPL any derivatives of his own making). Copyright itself is not implicitly viral in this sense. German copyright law doesn't require the derivative work to be under the same license, and, as you say, under U.S. copyright law, it depends on the license. While German copyright law itself might be considered viral in a similar way to the GPL, it is only so with respect to ownership, not licensing: there is nothing to stop the owner from licensing the derivative work differently than the original. It would be better to say copyright is "persistent."
The argument in this specific case shouldn't be about any supposed viral nature, anyhow. The Linux developers:
assumed that they could claim ownership of a derivative work, when in this case they may not be able to.
attempted to assert as derivative, works which probably don't qualify as such. Together with the foregoing, this led to asserting copyright when they probably didn't have a right to do so.
attempted to remove the copyright notice and BSD license from portions of their presumed derivative work, which is a violation of the license terms regardless of whether the work was derivative or not.
Ultimately, then, this isn't about relicensing at all. No one involved is contending that, were the work sufficient to be considered derivative, that the derivative work (taken as a whole) couldn't be GPL (the original author's rights under German law aside). They are arguing whether the derivative work being GPL permits the removal of the BSD license/copyright notices from the code. Furthermore, they are arguing over what constitutes a derivative work, and who owns said work.
If the app can't specify what it needs through the window manager, there's not much of an alternative.
It's not supposed to be about what the app needs, but what the user needs. That's the precise problem I'm talking about: assuming that all people want the same settings for the app. The WM should do what the user tells it to, not what the application programmer thinks is best for the user. A user has to options here: just specify a one-size-fits-all default (however flawed), or specify a default and specify specific behaviors for specific apps as one sees fit. Obviously, beginners will lack the proficiency to do the latter, but should adepts suffer just for the sake of novices?
Especially in this case where I doubt very much that there's a way for the user to select "child windows are hidden unless a member of this group of windows has focus" in any window manager.
AFAIK, if by "select," you mean "select from a menu," then no. Menus limit flexibility for all but the simplest programs, and window managers are no different - it's a fact of life. However, the better window managers have configuration files that can be edited by hand either instead of or in addition to menus. I may be wrong (as I do not pretend to be especially adept as yet, and this specific behavior is not one I'd thought of using), but I'm reasonably sure that this behavior can be achieved in most such window managers.
This is not a flaw unique to X11, by the way. There are analogues to this problem in every window system. And in every window system applications hack workarounds.
It's not a flaw in X at all: any flaw is in the specific window manager. X supplies "mechanism, not policy." X does not care about window placement. The tools for window placement are there, but it's up to WM as to how to use them. If a specific window manager doesn't supply sane options, then it isn't well-desinged. The solution to that is to use a better WM, not to have the app break the rules by specifying things it has no business specifying. Suggestions are fine, but a user's settings (as specified in the WM configurations) are supposed to be paramount. A user ought to be able to maintain a single set of configurations applicable to all applications (employing specific rules if neccessary), without worrying about certain apps not listening.
I think the general solution, for the more user-friendly window managers, is to have a few sane choices for the user, one of which is to give such special treatment to all child windows, whether the application needs it or not. More configurable (but more difficult to configure) window managers let the user specify the behavior for specific applications, as well as a universal default. Can the app specify without ignoring the user's choices? I'm not sure. The idea is that the app isn't supposed to care - it's supposed to be user-configurable.
Because, at its core, it's the continuation of the guestbook phenomenon of the '90s. Most geeks now realize how unnecessary and silly those were - enough so that ESR lists them as a characteristic feature of HTML HELL. A lot of geeks have considered blogs, or at least the typical examples thereof, to be no better. Besides which, geeks don't need MySpace: we can write our own webpages (in flawlessly valid HTML at that). The point of social networking sites is to make easy for non-geeks a subset of the same communications media that geeks are already adept at. That's fine, for what it's worth, but I have to laugh when 13 year-olds tell me they know more about computers than I do just because they have a MySpace and I don't. Social geeks with e-mail, a well-designed webpage, and AIM/ICQ; posting on USENET; and practically living in IRC, don't really need MySpace. For somewhat less social ones, like myself, e-mail, AIM/ICQ, occasional posts to USENET (as well as/. and other sites), and casual IRC use is plenty (I do keep meaning to put a new webpage up - I had one in college). Either way, maintaining a MySpace or Facebook page would not only be superfluous, but a distraction.
A program, however, needs to maintain window layering and focus in an organized fashion in certain circumstances... such as in the case of child dialogs, particularly blocking child dialogs. If there is no way in the X11 window manager API to say that certain windows need to maintain a layering or focus relationship then the application has to be able to step in....In X11, this is all too often handled by various ad-hoc rules in the application, which leads to conflicts with window managers, which leads to comments like the one above.
Properly designed window managers not only know the difference between a parent window and a child window, they also allow the user to set both default and special behaviors for focus and layering, according to their own preferences. Any WM that doesn't isn't worthy of the name. The problem, then, is apparently that too many people are using inadequate window managers, or don't know how to configure their window manger properly, and instead of treating it as a window management problem, the application programmers write the afore-mentioned ad hoc rules. This is an understandable, but improper solution. In other cases, though, it seems to be a matter of the programmer thinking he knows better than the user what the program should look like. This is bad design.
Honestly, I wonder what percentage of the people who complain about the GIMP GUI are Windows users? Certainly, the lion share of the suggestions here seem to be from people who are not familiar with the role of the window manager under X. As you say, not only do applications not have to make those decisions under X, but they are actually not supposed to. Applications like XMMS, which usurp the authority of the window manager, are loathed by a number of users because they don't play nice with some of the most flexible window managers (fvwm, for instance). The X philosophy understands that different people have different preferences about the UI, and assigning the whole matter to the window manager is supposed to make it easy for the user to have things be uniform, but customizable. X11 may have its flaws, but it is still infinitely superior to Windows. My greatest fear is that this whole process will end up sacrificing some of the flexibility under X just to make the Windows users happy.
Though, also the GUI does have its flaws.. Who wants to have to bring the windows to the front by choosing them one at a time by alt-tab? Why not do it like mac does it - you just select the program and all its windows jump up.
Focus behavior is (or is supposed to be) handled by the window manager, not the individual program. In Windows, giving the focus to a window doesn't bring all the windows belonging to that program forward. As far as I know, there's nothing you can do about that - Windows doesn't give you a choice. Under X, any good window manager should give you options as to focus behavior.
Slashdot Mirror
Let me preface this with the fact that I am not a Briton (I'm American, though of British ancestry), and that I was born after Britain went decimal. That said, I don't think it's as hard as you're making it out to be. Though the U.S. has used decimal currency from its inception, we still use "English" measurements (which are the same as Imperial for distance, area, and weight, but slightly different for liquid and dry capacity) over here, and we do just fine with them (even the more obscure one like rods, which are still used by surveyors, etc.).
A £10 bill divided four ways is £2½ under any system. The way I was taught to divide such units, instead of turning pounds into pence at the outset, you would figure out the integral part (the pounds), and then turn the fractional part only into smaller units: first shillings, then pence if it didn't go evenly into shillings. In this case, since £½ = 10s, there is never any need to translate into pence at all. If dividing three ways, however, the old system is easier, since three-and-a-third pounds can only be approximated in decimal to £3.33 (one of the three having to pay the remaining 1p in addition); while previously three-and-a-third pounds were £3/6s/8d exactly. For six ways, the old system yields one-and-two-thirds pounds, or £1/13/4, whereas approximating to £1.66 leaves a whole 4p to be accounted for (1.66 * 6 = 9.96).
The advantage of the old system, then, was that even division was much easier, since 240 is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 40, 48, 60, 80, and 120; instead of only 2, 4, 5, 10, 20, 25, and 50 (as 100 is). This means that is actual use, division is more often easier rather than more difficult under the old system. It's not the necessity of using fractions that is the problem in the new system (that's the case in any system) it's the inability to divide exactly by three, six, eight, or twelve - very common divisors to encounter. The old system had the advantage of being divisible by those as well as by five and ten.
It's the same way with distances. When I do carpentry work, for instance, I use feet, inches, and binary subdivisions of inches. In actual use, I find this far easier than the metric system, because (for various reasons) dividing by five or ten isn't nearly as common as dividing by three or six.
As long as it is possible for the WM to ignore the app (e.g., in cases where the user has set specific settings for that app in the WM configurations), then I don't see any reason why window managers shouldn't be able to support that.
Yes, I do. I've been using slightly different language, but wasn't trying to dispute the core of your point. It's a matter of semantics, so I won't argue it further.
When did I say that it did? Of course MacOS is a desktop Unix system. However, it happens to ship with a GUI that lacks the functionality (or at least the flexibility) of another GUI that is also available for Unix.
Of course. I wasn't trying to say anything else. Nothing in the world could make a VMS system into a Unix system.
I am more than content to have it stay that way. I want X11 (not just support for X11 apps) on my desktop. For those who don't, there's MacOS. X11 is not a superior choice on the desktops of neophytes, or even those who simply don't enjoy (or have the time for) tinkering. Those of us who do enjoy tinkering may find X11 superior to MacOS for our needs. Which is why it get irritating when certain app's refuse to obey the WM configurations that we have carefully set.
Now who's being silly? X is a UI designed for Unix and VMS, that makes it a Unix UI. Is is a part of Unix? Of course not. I didn't say it was a first-party UI. X, NeWS, NeXTstep, and the Mac GUI are all Unix interfaces in that they can be used as interfaces to Unix. That's the same as saying that they are all (coincidently third-party) interfaces that run on Unix (among other systems). I certainly wasn't trying to argue that the command line isn't the native UI for Unix.
BTW, I use the command line quite a bit, but I also like to have graphics support (without relying on the fundamentally broken svgalib*), and I happen to enjoy the tinkering that X allows and the MacOS GUI doesn't.
I would say that HTTP can be considered a Unix interface, since it can be used to interface with a Unix machine. The same for any communications protocol that Unix supports. For that matter, it's also a Windows interface and a VMS interface.
As long as we're both splitting hairs :) I'll point out that the comparison is not apt because window managers aren't an interface at all. Windows managers are essentially a helper app that runs on top of X so that the user doesn't have to manage windows manually. Furthermore, the fact that the shells are similar in several fundamentals just makes them several very similar, but still distinct UI's.
* Two words: setuid root.
Yes, but if I want a more-flexible GUI, such as X11, instead of the MacOS GUI, then things get substantially more complex. The Unix CLI is one Unix UI*, X is another, the Mac GUI is a third.
Which will probably mean that I won't install Qt-based app's anymore. The only one I have used any great amount is Opera, anyway. I'm already pretty picky about not installing widget-dependent app's unless I really need them. There's actually still pretty good choice out there, thankfully, if I don't mind using a less popular app.
* Technically, the Unix CLI is several UI's, given the choice of shells.
No, it's quite relevant. It's not about enforcement policy, it's about what the most common legal interpretation of the license is. These entities have lawyers in their employ, and their interpretation is critical to knowing what the license means, especially since UCB wrote the license. If your interpretation is correct, why haven't they at least told the *BSD projects to stop amending the copyright on files derived from original *BSD code? Lax enforcement can lead to loss of rights, as AT&T learned at the hands of UCB/BSDi, years ago. The *BSD projects aren't interpreting the license one way and enforcing it another, either. They wouldn't have amended the copyright unless they had legal opinions in favour. "Retain" can mean multiple things, as most any lawyer will say. I say again: the consistent, legal interpretation, for over twenty years, has been that "retain" simply means "don't remove." The fact is that you are virtually alone in your interpretation of the BSD license.
At any rate, your language with regard to the FSF (as much as I partly agree with you), continued arguing of points not in dispute (e.g., the matter of non-derivative works), continued refusal to admit that the meaning of "retain" is, at the very least, vague, and continued diatribes against the GPL when you've made the BSDL into virtually the same exact thing, are making you come off like a troll at this point. This is why I dumped debian for FreeBSD: to get away from the constant license zealotry, which was at the point of holding up the release cycle.
No, it says you must "retain" the license terms and the "above" copyright. You have no more right to amend the copyright than you have to add to the license terms. As you yourself said, further up thread, under U.S. copyright law the ownership of derivative works is dependent on the license the original code was issued under. If the BSD license does not allow amending the copyright - and if it does not allow adding to the license terms, then this must be the case (because the same word "retain" governs both) - then the author of the original work holds sole claim to the derivative work. You can't have it both ways.
You still refuse to address the fact that UCB and the *BSD projects have conducted themselves for over 20 years in a way which is at odds with your reading of the license. Unless you can show me where they take your position on that issue, I will consider my position secure.
Again I say that you read more into the license than is there. You can "retain this list of conditions" and add another one to it. As long as those conditions are still there, then "this list" is still there. "This list" is no different from saying "these conditions" - it's not in exclusive language, and had that been the intent this would be a very badly written license.
You've deemphasized the part about "the above copyright notice," but it's essential to understanding the meaning of the license. You can't argue that "retain" applies in an exclusive manner (prohibiting additions) to the license terms, but an inclusive manner (permitting additions) to the copyright. Either it means you are permitted to add attributions and terms, or are prohibited from adding either. Don't tell me that "this list" is somehow more restrictive than "the above...notice." If it is clear then, from over two decades of use, that the provision in regard to the copyright notice is inclusive, then it must logically also be inclusive with regard to the list of conditions.
Furthermore, you ignore my main point: that, in more than two decades of use, no one from either UCB or the *BSD projects has maintained this reading you propose. I say again, that if this were what the license terms meant by "retain," then it applies just as much to "the above copyright notice," as it does to "this list of conditions." In which case, the *BSD projects have themselves violated the license. Claims like that would put BSD right back into the legal Limbo it was in in 1992. Since I don't see UCB claiming that (thank Heaven), then I am going to continue believing that your interpretation is different from UCB's.
And that is the kicker, because if your reading is correct, then the only entity with any standing to bring a claim with regard to the lion share of BSDL software is UCB, because they will have retained copyright to not only the code up through 4.4BSD, but anything and everything derived from that code.
But they do distribute said code, even if it is under NDA. The license says "distribute" not "publish." Furthermore, following your line of logic, the BSDL should apply to their entire work, too, because they still have to provide the copyright notice, license terms, and disclaimer of warranty in the documentation. The license certainly doesn't say that they can add additional terms there, either.
I think we're not in agreement on what "retain" means. Since the license says only "retain," and not "retain exactly," I tend to believe that it merely means "don't remove." You are maintaining that "retain" means "don't add anything either." If it actually said "retain exactly" I might be inclined to agree with you.
Obviously, the author has the right to determine who may make a derivative work. I don't dispute that. The author of BSD-licensed code allows anyone to make a derivative work, provided that: if they distribute the code, they "retain" the copyright notice, license terms, and disclaimer of warranty that were on the original; and if they distribute binaries, they provide the same notice, terms, and disclaimer with the documentation. It's what these thing apply to that we disagree on. The consensus opinion, and the clear intent of the people at UCB who wrote the license in the first place, has been that these things, when appearing in the derivative work, apply only to those parts which belong to the original work, and not to the derivative work as a whole. You appear to be claiming that the BSD license (and by logical extension, BTW, the original author's copyright*) continues to apply to the derivative work as a whole, which would make it a viral license.
Show me a case where one of the CSRG people has agreed with your reading. Remember, the intent of the license issuer is usually taken into account, as well as the letter of the license. Nothing I have seen has ever indicated that UCB had any intention to retain ownership over derivative works, or to force derivative works to be distributed under the BSD license. If this had been their intent, it would have come up in the AT&T case (it would have made the University's counterclaims much stronger), but the only thing that came up there was AT&T removing the UCB copyright, etc. Furthermore, if your reading is correct, it is not only the license terms which cannot be changed, but the copyright notice, in which case the *BSD projects have also violated the license by adding their own names to that of the Regents of the University of California, Berkeley in the copyright notices.
As I said before, I strongly suspect that before we saw lawsuits over this get very far, we would see UCB re-write the license to rectify the situation (just as they did when the advertising clause became an issue). Most BSD users do not want to see a war with the FSF, especially if it means becoming just like them.
* That the copyright may do this anyway in some jurisdictions (e.g., Germany), I do not dispute. That it does so as a consequence of the word "retain" in the BSDL, I do dispute. In fact, I strongly suspect that the license would have been written differently, so as to explicitly disclaim ownership over derivative works, had the lawyers at UCB been thinking about non-U.S. jurisdictions.
I wasn't meaning to confuse X11 with Unix. However, I would not necessarily agree that MacOS isn't dumbed down, since it seems to make it difficult for the user to get around the limitations of the user-friendly UI. It's a far cry from MacOS 9 and earlier, but it still apparently lacks some of the flexibility of X11 (or so I hear from people I know who actually use Macs regularly).
As you say, free Unix is "stuck" with X11. I'm not certain, though, that what you say are flaws need to be considered as such. If a different window manager would fix said "flaws" then they are not flaws in X, but in the available window managers. A "standard" WM is something I'd rather avoid, though. The best part of X is that there is choice in window managers. Non-technical users can use one thing, while those of us who prefer a challenge can use something different. A "standard" WM almost has to be dumbed down, to accommodate non-technical users. As far as I am concerned, I don't have a problem with apps giving hints to the WM as long as there is a way for the user to override those hints in the WM configurations (not in the app settings).
Agreed. That sort of thing is inexcusable. At the very least, X-support should be a pre-compilation option, and binary distributions should be available in both flavours. Of course, my other pet peeve is toolkit-dependent apps (of which the GIMP is one of many). I'm not saying there shouldn't be a GTK frontend, for those who want it, but I really wish there were an Xt one as well. I don't use GNOME or KDE because of their bloat, and don't really think I should need GTK and/or Qt support.
Quite right. I'm not sure what I was thinking before (other than that I was tired). I concede the point. If someone wants to call German copyright viral (assuming the prior characterization of its nature is correct), then, I won't object any more.
I suppose this is why some of the die-hard-FSF fanatics (including RMS) have gotten irritated when people have released GPL'd code and haven't assigned the copyright to said code to the FSF (as in the case of XEmacs or Linux).
[Sorry for the double-post. I accidentally posted in HTML on reflex after writing the other one, and previewing it, in plain text because I was lazy. I never do this, but it would be absolutely Hellish to read that way, so here it is again.]
Wouldn't that preclude including BSD code in proprietary software just as much as including it in GPL software? If so, then that reading of the license is certainly not the understanding of the people who issued it in the first place. If that were the case, why hasn't UCB sued the pants off of Microsoft, Sun, or Apple? Don't tell me they don't redistribute in source form, either, because they do, albeit under a NDA. Besides, binary distributions have to present all these things in the "documentation or other materials" supplied by the vendor. The consistent understanding of the BSD license for two decades has been that derivative works could be licensed under different terms from the original code, so long as the copyright notice, license terms, and disclaimer of warranty pertaining to the original code were retained as well.
You are reading things into the license that aren't there. The fact that you must "retain" the license terms does not preclude you from adding new ones - pertaining only to the derivative work, as long as you can actually assert copyright over the derivative work. No where does the BSDL say that modified code must be distributed under "these exact license terms and no others," only the GPL does that. It says the license terms must be "retained," which simply means that you must not remove them, in acknowledgment of the rights of the author of the original code. If your interpretation of the license were correct, I would expect the majority of *BSD users to be clamoring to their respective projects and to UCB for the license to be changed to conform to what the intent was, rather than take the path of the FSF, and I expect it would happen, too.
If we start insisting that people who write derivative works based on the BSDL have to license their code as BSDL as well, then we become no better than the GNU crowd. In fact, we become worse by decrying their viral license while not being able to decide whether ours is or isn't. We become hypocrites and fence-sitters. The beauty of the BSDL is that it doesn't shackle the author of a derivative work. German and French copyright law may, but since I am neither a French nor a German citizen, there's not much I can do about that. If we loathe the GPL so much, then we have to preserve everything about the BSDL which makes it unlike the GPL. Otherwise, we are cutting off our nose to spite our face.
This isn't what the argument in this case is about, anyway. According to the mail logs that were posted, the argument here is, as I said before, about A) people asserting copyright over non-derivative works, B) the fact that, in this case, the ownership of derivative works would belong to the original author anyway, C) based on A & B, people altering asserting copyright over, and altering the license to, code which they didn't own, D) removing the original copyright notice, license terms, and disclaimer of warranty. I have yet to see Theo say anything in those logs which would indicate that, had this been a derivative work based on original code written in the U.S., that the authors of the derivative work couldn't have wrapped the whole thing in GPL, assuming they had retained the copyright notice, license terms, and disclaimer of warranty belonging to the original code.
Wouldn't that preclude including BSD code in proprietary software just as much as including it in GPL software? If so, then that reading of the license is certainly not the understanding of the people who issued it in the first place. If that were the case, why hasn't UCB sued the pants off of Microsoft, Sun, or Apple? Don't tell me they don't redistribute in source form, either, because they do, albeit under a NDA. Besides, binary distributions have to present all these things in the "documentation or other materials" supplied by the vendor. The consistent understanding of the BSD license for two decades has been that derivative works could be licensed under different terms from the original code, so long as the copyright notice, license terms, and disclaimer of warranty pertaining to the original code were retained as well. You are reading things into the license that aren't there. The fact that you must "retain" the license terms does not preclude you from adding new ones - pertaining only to the derivative work, as long as you can actually assert copyright over the derivative work. No where does the BSDL say that modified code must be distributed under "these exact license terms and no others," only the GPL does that. It says the license terms must be "retained," which simply means that you must not remove them, in acknowledgment of the rights of the author of the original code. If your interpretation of the license were correct, I would expect the majority of *BSD users to be clamoring to their respective projects and to UCB for the license to be changed to conform to what the intent was, rather than take the path of the FSF, and I expect it would happen, too. If we start insisting that people who write derivative works based on the BSDL have to license their code as BSDL as well, then we become no better than the GNU crowd. In fact, we become worse by decrying their viral license while not being able to decide whether ours is or isn't. We become hypocrites and fence-sitters. The beauty of the BSDL is that it doesn't shackle the author of a derivative work. German and French copyright law may, but since I am neither a French nor a German citizen, there's not much I can do about that. If we loathe the GPL so much, then we have to preserve everything about the BSDL which makes it unlike the GPL. Otherwise, we are cutting off our nose to spite our face. This isn't what the argument in this case is about, anyway. According to the mail logs that were posted, the argument here is, as I said before, about A) people asserting copyright over non-derivative works, B) the fact that, in this case, the ownership of derivative works would belong to the original author anyway, C) based on A & B, people altering asserting copyright over, and altering the license to, code which they didn't own, D) removing the original copyright notice, license terms, and disclaimer of warranty. I have yet to see Theo say anything in those logs which would indicate that, had this been a derivative work based on original code written in the U.S., that the authors of the derivative work couldn't have wrapped the whole thing in GPL, assuming they had retained the copyright notice, license terms, and disclaimer of warranty belonging to the original code.
Nitpick: a binary distribution still has to present the copyright notice, license, and disclaimer of warranty in the documentation supplied, if any.
Yes, BSD code can be incorporated into a GPL program (Theo wasn't saying it can't be, BTW), but only if A) there are enough changes to qualify as a derivative work and B) the original program wasn't copyrighted in a country (like France or Germany) which grants ownership to derivative works to the author of the original program (in theory, a derivative work can still be licensed GPL then, but only if the original author decides to do so). You can't relicense code you don't own the copyright to, which some people don't seem to understand.
I don't disagree (and yes, I did read the whole thread). You are very right in pointing out that it is German law, not the BSDL which is at least partly at issue here, and I wasn't trying to dispute that. I just wouldn't use the term "viral" for copyright itself. The term viral was first applied to the GPL because of the very "rapacious terms" you mention, which makes it different even from German and French copyright.
There is nothing is German or French copyright law which would prevent the original author from issuing derivative work under a different license than the original, whereas the GPL does just that. It's this assimilation of code that made people call it the "General Public Virus" in the first place.
I think you're spot on about dual licensing. I have often thought that the whole mess might have been avoided if they'd just left the "advertising clause" in (though it had its own problems). At least then, dual licensing would have been impossible, because the 4-clause BSDL is incompatible with the GPL (according to the FSF).
The GPL is never going to abandon its viral nature, because its proponents really believe that they are on a moral crusade. Software has a right to be free, they say. Those of us who think that's a tad silly, and who care more about granting rights to people than to inanimate code, really need to do a good job of promoting the BSD model in the future. It is far more commercially viable, especially with what the FSF is trying to do with GPL v3, and I fear that OSS may suffer if we don't make it clear, especially to the IBM's and HP's of the world and their clients, that this man (RMS) in no way represents us all.
If the user isn't willing to develop the level of competence that Unix requires, then the user should probably not be using Unix. I'm not sure if I want Unix to be a success on the desktop if it means we have to dumb the system down.
I didn't say the application can't request it (I also wasn't speaking specifically of unmanaged windows, but focus/layering behavior in general), I said that the ideal is for the user to be able to set behavior for individual app in the WM configurations that the app's requests won't override. Ideally, the app shouldn't care what how its window behaves or what it looks like.
Given that the applications we're talking about were around before the current commercial fad surrounding Linux, I seriously doubt that will happen. Besides, given how sick I am of seeing software that only runs on Linux, and either not natively or not at all on BSD (which is inexcusable - if you're going to write Unix code, make it proper, portable Unix code, without tying it to a particular kernel), it will be nothing new. OSS isn't going to kill Windows. If Windows dies it will be because of its own problems, and it will be to MacOS, not anything else.
Rather, IMO, if the user needs different behavior from different apps, then the user needs to specify to the window manager which behavior it needs. Having the app do it is backwards.
Honestly, I don't understand what people's hangup about editing config files is. Text files are far more flexible than menus, and often easier to understand. Most users are smarter than we give them credit for, and smarter than they give themselves credit for. After the initial shock, most of them would actually become far more proficient if they just had to use text files for a while and stopped letting the system dumb everything down for them.
In such a case, the user should request it himself, without having to go through the app. To have the app request it leads to conflicts, and is more complicated for the user to maintain.
Where's the harm in that, anyhow? If someone if more comfortable with a Mac than a more flexible form of Unix, then I wouldn't want them to switch. There is no one-size-fits-all OS. There shouldn't be, either. I try to steer people away from Microsoft, because I think there are significant technical reasons for doing so, but I have advised beginning-to-intermediate computer users to buy a Mac before, because that's what MacOS is good at: coddling newbies. Once such a system is more restricting than you want, you can move on to something more challenging, like BSD or Linux. I don't see a problem with Unix (other than MacOS) being considered a system for advanced users, at least as far as the home desktop is concerned.
You are using "viral" in a different sense from the general use when referring to "viral licenses." The GPL is viral, in the sense that all derivative works must be GPL - no matter who is the owner (even the owner of the copyright is bound to GPL any derivatives of his own making). Copyright itself is not implicitly viral in this sense. German copyright law doesn't require the derivative work to be under the same license, and, as you say, under U.S. copyright law, it depends on the license. While German copyright law itself might be considered viral in a similar way to the GPL, it is only so with respect to ownership, not licensing: there is nothing to stop the owner from licensing the derivative work differently than the original. It would be better to say copyright is "persistent."
The argument in this specific case shouldn't be about any supposed viral nature, anyhow. The Linux developers:
- assumed that they could claim ownership of a derivative work, when in this case they may not be able to.
- attempted to assert as derivative, works which probably don't qualify as such. Together with the foregoing, this led to asserting copyright when they probably didn't have a right to do so.
- attempted to remove the copyright notice and BSD license from portions of their presumed derivative work, which is a violation of the license terms regardless of whether the work was derivative or not.
Ultimately, then, this isn't about relicensing at all. No one involved is contending that, were the work sufficient to be considered derivative, that the derivative work (taken as a whole) couldn't be GPL (the original author's rights under German law aside). They are arguing whether the derivative work being GPL permits the removal of the BSD license/copyright notices from the code. Furthermore, they are arguing over what constitutes a derivative work, and who owns said work.It's not supposed to be about what the app needs, but what the user needs. That's the precise problem I'm talking about: assuming that all people want the same settings for the app. The WM should do what the user tells it to, not what the application programmer thinks is best for the user. A user has to options here: just specify a one-size-fits-all default (however flawed), or specify a default and specify specific behaviors for specific apps as one sees fit. Obviously, beginners will lack the proficiency to do the latter, but should adepts suffer just for the sake of novices?
AFAIK, if by "select," you mean "select from a menu," then no. Menus limit flexibility for all but the simplest programs, and window managers are no different - it's a fact of life. However, the better window managers have configuration files that can be edited by hand either instead of or in addition to menus. I may be wrong (as I do not pretend to be especially adept as yet, and this specific behavior is not one I'd thought of using), but I'm reasonably sure that this behavior can be achieved in most such window managers.
It's not a flaw in X at all: any flaw is in the specific window manager. X supplies "mechanism, not policy." X does not care about window placement. The tools for window placement are there, but it's up to WM as to how to use them. If a specific window manager doesn't supply sane options, then it isn't well-desinged. The solution to that is to use a better WM, not to have the app break the rules by specifying things it has no business specifying. Suggestions are fine, but a user's settings (as specified in the WM configurations) are supposed to be paramount. A user ought to be able to maintain a single set of configurations applicable to all applications (employing specific rules if neccessary), without worrying about certain apps not listening.
I think the general solution, for the more user-friendly window managers, is to have a few sane choices for the user, one of which is to give such special treatment to all child windows, whether the application needs it or not. More configurable (but more difficult to configure) window managers let the user specify the behavior for specific applications, as well as a universal default. Can the app specify without ignoring the user's choices? I'm not sure. The idea is that the app isn't supposed to care - it's supposed to be user-configurable.
Because, at its core, it's the continuation of the guestbook phenomenon of the '90s. Most geeks now realize how unnecessary and silly those were - enough so that ESR lists them as a characteristic feature of HTML HELL. A lot of geeks have considered blogs, or at least the typical examples thereof, to be no better. Besides which, geeks don't need MySpace: we can write our own webpages (in flawlessly valid HTML at that). The point of social networking sites is to make easy for non-geeks a subset of the same communications media that geeks are already adept at. That's fine, for what it's worth, but I have to laugh when 13 year-olds tell me they know more about computers than I do just because they have a MySpace and I don't. Social geeks with e-mail, a well-designed webpage, and AIM/ICQ; posting on USENET; and practically living in IRC, don't really need MySpace. For somewhat less social ones, like myself, e-mail, AIM/ICQ, occasional posts to USENET (as well as /. and other sites), and casual IRC use is plenty (I do keep meaning to put a new webpage up - I had one in college). Either way, maintaining a MySpace or Facebook page would not only be superfluous, but a distraction.
Properly designed window managers not only know the difference between a parent window and a child window, they also allow the user to set both default and special behaviors for focus and layering, according to their own preferences. Any WM that doesn't isn't worthy of the name. The problem, then, is apparently that too many people are using inadequate window managers, or don't know how to configure their window manger properly, and instead of treating it as a window management problem, the application programmers write the afore-mentioned ad hoc rules. This is an understandable, but improper solution. In other cases, though, it seems to be a matter of the programmer thinking he knows better than the user what the program should look like. This is bad design.
Honestly, I wonder what percentage of the people who complain about the GIMP GUI are Windows users? Certainly, the lion share of the suggestions here seem to be from people who are not familiar with the role of the window manager under X. As you say, not only do applications not have to make those decisions under X, but they are actually not supposed to. Applications like XMMS, which usurp the authority of the window manager, are loathed by a number of users because they don't play nice with some of the most flexible window managers (fvwm, for instance). The X philosophy understands that different people have different preferences about the UI, and assigning the whole matter to the window manager is supposed to make it easy for the user to have things be uniform, but customizable. X11 may have its flaws, but it is still infinitely superior to Windows. My greatest fear is that this whole process will end up sacrificing some of the flexibility under X just to make the Windows users happy.
Focus behavior is (or is supposed to be) handled by the window manager, not the individual program. In Windows, giving the focus to a window doesn't bring all the windows belonging to that program forward. As far as I know, there's nothing you can do about that - Windows doesn't give you a choice. Under X, any good window manager should give you options as to focus behavior.