Both of your complaints are about your editor/text manipulator,
not about Python.
I have to disagree with you here. With most programming languages,
indentation is documentation, the sort that can be automatically
generated from the rest of the source code. In Python, it's part of
the syntax. That's a pretty significant language design decision.
The two exceptions are when you're starting a block (in which
case detecting the : at the end of the line gives an unambiguous sign)
or ending a block (in which case you have to backspace once, hardly a
special challenge).
XEmacs has no trouble detecting the start of a block (as far as I
can see). The only ambiguity is at the end of a block, which is the
thing I was complaining about. When I do C programming in XEmacs,
hitting TAB will immediately correctly indent the current line.
If it doesn't, it's because I've screwed up somewhere.
XEmacs Python mode is almost as good, but I still have to
manually change the indentation at the end of a block. This is a
pain. It's not, as you point out, a huge pain, but it bugs me
a bit. It also means I need to do more than hit TAB a bunch of times
when I'm reorganizing my code to, say, move a block of text into a
loop.
But really, I'm just nit-picking here. If I wanted to complain about
Python, there are other things I could whinge about.
The whitespace and backslashes are not in addition to something
else that unambiguously describes the structure. They are instead of
the stuff that other languages use (curly braces and semicolons).
Fair enough. We shouldn't automatically dismiss Python's
significant whitespace. Instead, we should discuss it on its own
merits.
So here are two things that suck about Python's significant
whitespace:
Many text-manipulation tools don't respect whitespace well
enough. They replace tabs with spaces or vice versa or they alter the
indentation. A co-worker of mine once told me about how he had to
spend several hours fixing a Python program that had gotten loaded
into Notepad and saved again. Had it been C, he'd have only needed to
run it through 'indent'. Yeah, I know, Notepad sucks, but still!
This is just an accident waiting to happen.
Text editors can't auto-indent Python code correctly. When
I edit C code, emacs simply counts the number of "{" and "}" characters and
indents correctly whenever I hit the tab key. It can't do that with
Python code because there's no unambiguous way for it to figure out
what is correct at this line. The best it can do is guess based on
the previous line, which means I periodically have to correct for it.
Which is a pain.
That being said, the intent of this feature--making it so
that all programs have a consistent format--is a good one. I just
don't think that the benefits outweigh the drawbacks.
I also don't
think that it's enough of a problem to justify not using Python when
it's the right tool for the job.
(Hmmm. What if a language forbade sequences of whitespace?
Then, you would do the indenting and unindenting in the editor and
every program would have Your Favourite Indentation Style.)
Isn't Unix what powers OS-X? I'm no specialist of the Mac word, but it
seems to me that if something works on Unix, it has a fair chance of
working under OS-X/Mac too, no?
Er, yes and no. By which I mean, they could but it would suck.
Yes, the OS-X kernel implements the standard BSD system calls so for
our purposes, it's a Unix. However, that's not really a big deal.
Unix has around a hundred system calls, no more, and it's pretty easy
to implement that API under other operating systems, including
Windows. That's what CygWin does.
The real problem is that FrameMaker is a GUI-based application, which
means it spends most of its life talking to a windowing system.
Windowing system APIs are vastly more complicated and completely
different between platforms. So while console-mode Unix programs are
one compile-and-link away from running under MacOS-X, GUI-based
programs will typically need to have their front-ends rewritten.
(One of the big selling points for Qt, BTW, is that it provides a
common GUI API on all of the platforms it supports so you can
just recompile a Qt program under MacOS-X.)
And, just to make things even more complicated, remember that
FrameMaker predates GTk and Qt. Before those came along, there were
several competing widget libraries for X11 and the most popular of
them all, Motif, was proprietary. So the Unix version of FrameMaker (probably) uses some ancient, moldy
windowing API that has more in common with Win16 than with any of the
OS-X APIs. Which means, in answer to your question, no.
But wait! It turns out that there are multiple X11
servers available for MacOS-X, including one from Apple. Assuming
Adobe has the source for their widget library (and I don't see why
not), they'd just need to recompile everything for MacOS-X (plus clean
up whatever platform dependencies there are--probably not a big job)
and they'd have FrameMaker for MacOS-X with X11. So in answer to your
question, yes!
But the resulting program would have the look and feel of the Solaris
version--80's-era GUI and the usability of your typical
Unix app. Also, there are conceptual differences between the way X
and the Mac do cut-and-past and probably a lot of other things as
well. The resulting program would work on the Mac but it wouldn't
really be a Mac program. It'd be this hideous, misshapen hulk
that doesn't know where it belongs, and it'd have Adobe's logo all
over it. In other words, it would suck too much to be marketable.
From a technical point of view though, the Right Thing to do is to
rewrite the entire GUI code to use a cross-platform GUI library like
Qt and then build each platform's version from the same source tree.
Adobe doesn't look like they're going to do that, so if you're looking
for a business idea, writing a cross-platform competitor to FrameMaker
might be a way to make a decent living without moving to India.
This sort of thing is exactly what I'd expect from freedom-hating closed-source advocates. No doubt, some SCO fan went and did this in retaliation for the Linux developers' attempts to preserve their intellectual property rights.
There is a dark side of the commercial software community and now we are beginning to see it emerge.
When email gets fixed (through authenticated access), the worms and virii will need to find a new way to spread.
Feh! All you need to do to fix email is to, at the ISP level, go through every incoming message and strip out every executable attachment, be it a.EXE file, HTML with scripting or a Word document with embedded scripts. That would do it then and there with almost no loss of functionality.
But you know it won't happen, because Uncle Joe will get annoyed when he can't click-and-run the self-extracting e-card someone sent him and then he'll switch to some ISP that doesn't offer this particular service, never knowing what he's opening himself up to.
I once told a friend to stop using Outlook Express because it's a virus-launching platform. He wouldn't because he couldn't find another free mailer that was as nice as it. Security is one of those invisible things that nobody notices. It's really hard to get ordinary people to take it seriously.
This sounds like a hoax to me. PJ continues to post articles to Groklaw so I don't think she's the former editor. I also haven't heard anything about this venture from there, nor has she been particularly enthusiastic for OSS indemnification in the past.
I could be wrong, but for the moment, I'll hold off taking them seriously.
Why do they even bother buying the rights to something they couldn't really care less about, artistically?
Because that way, they could make serious money by attaching a generator to Isaac Asimov's coffin and selling the electricity.
Ba-dum dum!
But seriously, there are two reasons:
Running a story through the Hollywood machine of writers, producers, directors and marketers is sort of like putting a pig through a sausage machine.
It's cheaper to buy the rights to a book (or story, or play) than to get sued for infringement afterward. So if, for example, you wanted to make a robot action movie that mentioned the Three Laws of Robotics, you may as well up the budget by 0.0001% and buy the movie rights.
It's very rare for a movie to resemble its source material even a little bit. After all, writers are cheap and directors are expensive. Guess who gets to say how the story goes.
(Not that I'm bitter or anything--I just read the occasional Harlan Ellison essay on the subject.)
I gave up and resorted to buying CDs, ripping them, then burning
them.
Personally, I like having the disks around. If nothing
else, they're useful as a zero-effort backup or if I want to switch
audio formats. (If space is a consideration, you could invest in a
vertical CD rack like I did or, alternately, put the disks and inserts
into a binder and throw away the jewel cases.)
I haven't run into many DRM'd CDs that I care about yet so I don't
know how that will affect my life. However, CDDA-XTractor had no
trouble ripping the one I bought, although I couldn't find a way to
make cdparanoia rip it correctly.
The only real problem with buying CDs is if defeating the DRM is
illegal under laws like the DMCA. Canada doesn't (yet) have such a
law but I don't know what Germany is like. Of course, you could just
do it anyway, based on the assumption that you'll probably never get
busted for it.
$45 ($60 CDN) is about what I'd be willing to pay for a copy of Windows XP. The last version of Windows I bought was Windows 3.1 back in 1993 and I got rid of my DOS partition in 1996 (when I switched to a spiffy new Pentium PC). It's been just Linux since then and for the most part, I have no complaints.
But I have a few bargain-bin games that won't run under WineX and there are a few other Windows-only apps out there that I'd like to play with so it would be handy to have a copy of Windows around. Also, there are a couple of programs I'd like to take a shot at porting to Windows. CDN $60 is about what that's worth to me.
A retail version of XP Home is $CDN 300 and XP Office goes for CDN $500, though, so I won't be giving MS any of my money. But if I'm buying a new computer anyway and I can get Windows at the OEM rate with it, then sure, why not?
So just now, I went to Yahoo and did a couple of searches. The top three or so links were clearly marked as "sponsor links" and were followed by the actual (relevant) results, also clearly marked. In other words, they're doing the same thing that Google does with AdWords, namely using the search criteria to serve up relevant ads. The ads are kept separate from the real content so that they don't reduce the actual quality of their service.
(One of my test searches was for Squeak, the free Smalltalk system. The real results were all relevant but one fo the ads went,
Squeaks on eBay. Find squeaks items at low prices.
Notice that nowhere in any of the articles is it mentioned just how much money EV1 paid for their site license?
I'm guessing it was peanuts. SCO probably made them a really, really good offer, one that cost less than it would have cost them to get the company lawyer to laugh at their cease-and-desist letter, let alone fight a lawsuit.
This way, SCO could announce that a respectable company had bought a license from them, the implication being that somebody was taking them seriously.
I can't really blame EV1 for doing it. They have some 20,000 Linux boxes and if SCO were to win, they'd be in serious trouble. Paying them off for a few bucks is, granted, giving in to extortion, but it's cheap insurance against disaster.
Designing a useable interface is difficult and the skills required
for it are dramatically different from those needed to
implement the back-end software. The CUPS wizard that ESR described
was designed by programmers. Microsoft's equivalent was designed by
usability experts.
The thing is, most people think of software development as just
writing code. It's not. Writing a useful program requires first
understanding the problem and its possible solutions. It
requires experts in the problem domain. That's why all of the really
successful OSS projects have been things like programming languages,
libraries, development tools and operating systems--those are all are
things that programmers are already experts in.
It's possible that a naive-user friendly Linux is beyond the
abilities of the open-source community. Maybe there are no good
usability experts willing to volunteer their time on some of these
projects. In that case, somebody is going to have to pay for the
work. So far, some of the distributions have already done just that
and I keep having less trouble with Mandrake on each new release, so
there's hope. Maybe in the future, different Linux distributions will
be compatible but completely different in look and feel, each
targeted toward a different market segment. That wouldn't be so bad.
However, if the OSS community wants to solve this problem in an
open-source way, we need to take it more seriously than just telling
the programmers to smarten up. Linux is infrastructure, written by
infrastructure experts. The configuration tools need to be designed
by usuability experts and implemented separately from the things they
are configuring.
We need, in other words, a collection of UI geeks, a group of
people who know how to deal with non-technical users and by
programmers who will listen to them. This is the group
that will write the control panels and configuration wizards and spend
their time and energy making them better and more usable.
The CUPS team (to pick one) isn't going to do that and shouldn't
have to. Their job is to understand printing. Usability is a
different problem entirely.
It seems quite clear that Mandrake Linux intended to rip off Mandrake the Magician's look and name.
As it happens, there was also a stage magician named Leon Mandrake who may or may not have been the basis for the cartoon character. (Some sources say yes, others say they came up with the name independantly. However, he and one of the original Mandrake cartoonists were friends.)
Do a hex dump of an.o file, for example. cpp does the including and pipes the result to the code generator, which binarifies it unrecognizably.
And if you disassemble the results and look at the debug table, you can see exactly which parts of the code came from the included header files.
ONLY the FSF has ever interpreted library linking this way; that's what I mean by "viral"
How the FSF interprets it is irrelevant. The law says that if you take my code and modify it, the result is a derived work and anyone who wants to copy it needs both our permissions to do so. That's the only reason the FSF can enforce their interpretation. Linking and including both produce derived works because they both combine your code with someone elses' and those copyrights are all valid. Just because most of the time the library writers give blanket permission to copy binaries, it doesn't mean you always have the right to do it.
As Dawes says in one of his posts, their copyright ends at their API boundary.
He may think so, but it's not true.
To put it simply:
The law gives them part of the copyrights to binaries that use the xlibs and headers, whether or not they don't want them.
The new license doesn't say "we don't want those rights."
Therefore, we have to assume they do.
If they really want their reach to end at the API boundary, they should have said that in the license.
If you're distributing binary, then the header files are nowhere to
be found (they're not merged; they've been eaten).
Not true. The semantics of the C 'include' directive are
basically "copy-and-paste the contents of this file into the sources
at this space" and the resulting code goes into the object file. A
binary produced using a header file is a derived work of that
header, even if the original source code is not, and so the XFree86
team has a partial copyright on it as a contributor.
And if you're distributing a statically-linked binary, the
executable file is a merging (by means of a linker) of the object code
produced from your source and the object code produced from their
source and once again, they have a partial copyright on that source.
(And yes, the same is true of the Borland and Lattice headers and
libraries. Only, because you've paid them money, they granted you the
right to distribute their share in the resulting executable under your
terms, more or less.)
The GPL is viral only because it is specifically written to
be. More normal licenses -- such as this one -- are not.
Actually, copyright is intrinsically viral when it comes to
derivative works. For example, the copyright to this Slashdot post
partially belongs to you because it contains text you wrote. If I
sold the movie rights to it, I'd have to cut you in on the deal.
In the same way, the XFree86 team is considered one of the
copyright holders of your application binary if you link it against
their libraries or include their headers. You may be able to plead fair use if they try to sue
you, but nonetheless, they are the some of the authors of that
executable. They own a share of that copyright and the license says
what you can do with it.
Note that I said "can do", not "can't do". The license only tells
you what are allowed to do, not what you're not allowed to do.
Everything not permitted is forbidden (within the bounds of copyright
law, anyway).
The license doesn't say anything about linking to applications as
being different from merging. Therefore, we must assume that they
consider that to fall into the category of "merging". Therefore, the
conditions apply.
(Of course, your original source code remains untouched, so the
license isn't "viral" the way the GPL is. You could compile and link
it against a different implementation of X and distribute it under
whatever terms that may impose. However, the new XFree86 license very
much does restrict what you can do with your executable.)
Permission is hereby granted... to deal in the Software without
restriction, including without limitation the rights to use, copy,
modify, merge... copies of the Software... subject to
the following conditions:...
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution, and in the same place and form
as other copyright, license and disclaimer information.
3. The end-user documentation included with the redistribution,
if any, must include the following acknowledgment:...
(Elided text marked--see the original for the missing bits.)
The problem is that "merging" clause.
If your program includes any of the X include files, you've now merged it with those files, which are released under that license. This is also the case if you've statically linked to any of the libraries and probably also if you're dynamically linking to shared libraries. (You might be able to make a "fair use" case for that, but the headers will get you regardless.)
If we were talking about just the server, the above wouldn't be a problem. However, major parts of XFree86 need to be merged with other programs to be useful so, whether that was their intent or not, the license as it stands is viral.
I think what's going on here is that there's some confusion about what's a derived work.
The new license applies to XFree86 and anything based on it. This sounds fair until you realize that if you write a program that just uses XFree86, you are, technically speaking, combining your code with theirs by linking to the xlibs and including the header files. This means you need to credit them. For Mandrake to use XFree86 4.0, they'd have to go through the documentation for every app and library that uses the xlibs and add the attribution.
It violates the GPL because it adds extra restrictions on what may be done with GPL'd code. The GPL allows you to distribute a GPL'd program without the XFree86 attribution but the new XFree86 license doesn't.
My take on this is that it's unintentional. I suspect that someone didn't think through the implications and that in a couple of days, the XFree86 team will amend the license to say that just connecting to the server or linking against the xlibs doesn't constitute a derived work. At least, that's my hope. Otherwise, it could take years for a new de-facto X implementation to emerge.
They make themselves look like police officers but they never
identify themselves as police and don't wear uniforms. This way, they
can claim that they aren't impersonating police officers, which is
illegal.
They threatened the vendor and took his "contraband" but they turned
it into an out-of-court legal settlement by getting him to sign the
appropriate documents. This way, it's technically not vigilantism,
even though that's the intent.
I have no doubt they've hired the best people available to keep them
just barely on the legal side of the line. Convincing a jury that
this is criminal activity will be a hard sell, and proving that the
RIAA's upper management ordered the illegal actions will be even
harder. Still, it would restore my faith in humanity to see the
RIAA's leadership doing hard time for this.
Is it just me or is Darl going through the "How to Annoy the OSS Community" checklist?
He's already repeated every bit of MS LinuxFUD out there and publically supported the RIAA lawsuits so really, it was time for a DMCA takedown. Wake me up when he gets to biting the heads of cute baby penguins.
Sending spam is theft, pure and simple. Spammers are using the recipients' money and time for their own ends. It's no different than embezzeling a dollar from every bank account in the country except that the latter at least doesn't render the entire banking system useless.
Slashdot Mirror
Both of your complaints are about your editor/text manipulator, not about Python.
I have to disagree with you here. With most programming languages, indentation is documentation, the sort that can be automatically generated from the rest of the source code. In Python, it's part of the syntax. That's a pretty significant language design decision.
The two exceptions are when you're starting a block (in which case detecting the : at the end of the line gives an unambiguous sign) or ending a block (in which case you have to backspace once, hardly a special challenge).
XEmacs has no trouble detecting the start of a block (as far as I can see). The only ambiguity is at the end of a block, which is the thing I was complaining about. When I do C programming in XEmacs, hitting TAB will immediately correctly indent the current line. If it doesn't, it's because I've screwed up somewhere.
XEmacs Python mode is almost as good, but I still have to manually change the indentation at the end of a block. This is a pain. It's not, as you point out, a huge pain, but it bugs me a bit. It also means I need to do more than hit TAB a bunch of times when I'm reorganizing my code to, say, move a block of text into a loop.
But really, I'm just nit-picking here. If I wanted to complain about Python, there are other things I could whinge about.
The whitespace and backslashes are not in addition to something else that unambiguously describes the structure. They are instead of the stuff that other languages use (curly braces and semicolons).
Fair enough. We shouldn't automatically dismiss Python's significant whitespace. Instead, we should discuss it on its own merits.
So here are two things that suck about Python's significant whitespace:
That being said, the intent of this feature--making it so that all programs have a consistent format--is a good one. I just don't think that the benefits outweigh the drawbacks.
I also don't think that it's enough of a problem to justify not using Python when it's the right tool for the job.
(Hmmm. What if a language forbade sequences of whitespace? Then, you would do the indenting and unindenting in the editor and every program would have Your Favourite Indentation Style.)
Isn't Unix what powers OS-X? I'm no specialist of the Mac word, but it seems to me that if something works on Unix, it has a fair chance of working under OS-X/Mac too, no?
Er, yes and no. By which I mean, they could but it would suck.
Yes, the OS-X kernel implements the standard BSD system calls so for our purposes, it's a Unix. However, that's not really a big deal. Unix has around a hundred system calls, no more, and it's pretty easy to implement that API under other operating systems, including Windows. That's what CygWin does.
The real problem is that FrameMaker is a GUI-based application, which means it spends most of its life talking to a windowing system. Windowing system APIs are vastly more complicated and completely different between platforms. So while console-mode Unix programs are one compile-and-link away from running under MacOS-X, GUI-based programs will typically need to have their front-ends rewritten.
(One of the big selling points for Qt, BTW, is that it provides a common GUI API on all of the platforms it supports so you can just recompile a Qt program under MacOS-X.)
And, just to make things even more complicated, remember that FrameMaker predates GTk and Qt. Before those came along, there were several competing widget libraries for X11 and the most popular of them all, Motif, was proprietary. So the Unix version of FrameMaker (probably) uses some ancient, moldy windowing API that has more in common with Win16 than with any of the OS-X APIs. Which means, in answer to your question, no.
But wait! It turns out that there are multiple X11 servers available for MacOS-X, including one from Apple. Assuming Adobe has the source for their widget library (and I don't see why not), they'd just need to recompile everything for MacOS-X (plus clean up whatever platform dependencies there are--probably not a big job) and they'd have FrameMaker for MacOS-X with X11. So in answer to your question, yes!
But the resulting program would have the look and feel of the Solaris version--80's-era GUI and the usability of your typical Unix app. Also, there are conceptual differences between the way X and the Mac do cut-and-past and probably a lot of other things as well. The resulting program would work on the Mac but it wouldn't really be a Mac program. It'd be this hideous, misshapen hulk that doesn't know where it belongs, and it'd have Adobe's logo all over it. In other words, it would suck too much to be marketable.
From a technical point of view though, the Right Thing to do is to rewrite the entire GUI code to use a cross-platform GUI library like Qt and then build each platform's version from the same source tree. Adobe doesn't look like they're going to do that, so if you're looking for a business idea, writing a cross-platform competitor to FrameMaker might be a way to make a decent living without moving to India.
This sort of thing is exactly what I'd expect from freedom-hating closed-source advocates. No doubt, some SCO fan went and did this in retaliation for the Linux developers' attempts to preserve their intellectual property rights.
There is a dark side of the commercial software community and now we are beginning to see it emerge.
(Warning: this article contains sarcasm.)
When email gets fixed (through authenticated access), the worms and virii will need to find a new way to spread.
Feh! All you need to do to fix email is to, at the ISP level, go through every incoming message and strip out every executable attachment, be it a .EXE file, HTML with scripting or a Word document with embedded scripts. That would do it then and there with almost no loss of functionality.
But you know it won't happen, because Uncle Joe will get annoyed when he can't click-and-run the self-extracting e-card someone sent him and then he'll switch to some ISP that doesn't offer this particular service, never knowing what he's opening himself up to.
I once told a friend to stop using Outlook Express because it's a virus-launching platform. He wouldn't because he couldn't find another free mailer that was as nice as it. Security is one of those invisible things that nobody notices. It's really hard to get ordinary people to take it seriously.
They use GPL'd code from WASTE but haven't released the whole source code! They're in a world of legal hurt now.
This sounds like a hoax to me. PJ continues to post articles to Groklaw so I don't think she's the former editor. I also haven't heard anything about this venture from there, nor has she been particularly enthusiastic for OSS indemnification in the past.
I could be wrong, but for the moment, I'll hold off taking them seriously.
Why do they even bother buying the rights to something they couldn't really care less about, artistically?
Because that way, they could make serious money by attaching a generator to Isaac Asimov's coffin and selling the electricity.
Ba-dum dum!
But seriously, there are two reasons:
It's very rare for a movie to resemble its source material even a little bit. After all, writers are cheap and directors are expensive. Guess who gets to say how the story goes.
(Not that I'm bitter or anything--I just read the occasional Harlan Ellison essay on the subject.)
I gave up and resorted to buying CDs, ripping them, then burning them.
Personally, I like having the disks around. If nothing else, they're useful as a zero-effort backup or if I want to switch audio formats. (If space is a consideration, you could invest in a vertical CD rack like I did or, alternately, put the disks and inserts into a binder and throw away the jewel cases.)
I haven't run into many DRM'd CDs that I care about yet so I don't know how that will affect my life. However, CDDA-XTractor had no trouble ripping the one I bought, although I couldn't find a way to make cdparanoia rip it correctly.
The only real problem with buying CDs is if defeating the DRM is illegal under laws like the DMCA. Canada doesn't (yet) have such a law but I don't know what Germany is like. Of course, you could just do it anyway, based on the assumption that you'll probably never get busted for it.
$45 ($60 CDN) is about what I'd be willing to pay for a copy of Windows XP. The last version of Windows I bought was Windows 3.1 back in 1993 and I got rid of my DOS partition in 1996 (when I switched to a spiffy new Pentium PC). It's been just Linux since then and for the most part, I have no complaints.
But I have a few bargain-bin games that won't run under WineX and there are a few other Windows-only apps out there that I'd like to play with so it would be handy to have a copy of Windows around. Also, there are a couple of programs I'd like to take a shot at porting to Windows. CDN $60 is about what that's worth to me.
A retail version of XP Home is $CDN 300 and XP Office goes for CDN $500, though, so I won't be giving MS any of my money. But if I'm buying a new computer anyway and I can get Windows at the OEM rate with it, then sure, why not?
So just now, I went to Yahoo and did a couple of searches. The top three or so links were clearly marked as "sponsor links" and were followed by the actual (relevant) results, also clearly marked. In other words, they're doing the same thing that Google does with AdWords, namely using the search criteria to serve up relevant ads. The ads are kept separate from the real content so that they don't reduce the actual quality of their service.
(One of my test searches was for Squeak, the free Smalltalk system. The real results were all relevant but one fo the ads went,
Ya gotta love EBay.)
Notice that nowhere in any of the articles is it mentioned just how much money EV1 paid for their site license? I'm guessing it was peanuts. SCO probably made them a really, really good offer, one that cost less than it would have cost them to get the company lawyer to laugh at their cease-and-desist letter, let alone fight a lawsuit.
This way, SCO could announce that a respectable company had bought a license from them, the implication being that somebody was taking them seriously.
I can't really blame EV1 for doing it. They have some 20,000 Linux boxes and if SCO were to win, they'd be in serious trouble. Paying them off for a few bucks is, granted, giving in to extortion, but it's cheap insurance against disaster.
Designing a useable interface is difficult and the skills required for it are dramatically different from those needed to implement the back-end software. The CUPS wizard that ESR described was designed by programmers. Microsoft's equivalent was designed by usability experts.
The thing is, most people think of software development as just writing code. It's not. Writing a useful program requires first understanding the problem and its possible solutions. It requires experts in the problem domain. That's why all of the really successful OSS projects have been things like programming languages, libraries, development tools and operating systems--those are all are things that programmers are already experts in.
It's possible that a naive-user friendly Linux is beyond the abilities of the open-source community. Maybe there are no good usability experts willing to volunteer their time on some of these projects. In that case, somebody is going to have to pay for the work. So far, some of the distributions have already done just that and I keep having less trouble with Mandrake on each new release, so there's hope. Maybe in the future, different Linux distributions will be compatible but completely different in look and feel, each targeted toward a different market segment. That wouldn't be so bad.
However, if the OSS community wants to solve this problem in an open-source way, we need to take it more seriously than just telling the programmers to smarten up. Linux is infrastructure, written by infrastructure experts. The configuration tools need to be designed by usuability experts and implemented separately from the things they are configuring.
We need, in other words, a collection of UI geeks, a group of people who know how to deal with non-technical users and by programmers who will listen to them. This is the group that will write the control panels and configuration wizards and spend their time and energy making them better and more usable.
The CUPS team (to pick one) isn't going to do that and shouldn't have to. Their job is to understand printing. Usability is a different problem entirely.
It seems quite clear that Mandrake Linux intended to rip off Mandrake the Magician's look and name.
As it happens, there was also a stage magician named Leon Mandrake who may or may not have been the basis for the cartoon character. (Some sources say yes, others say they came up with the name independantly. However, he and one of the original Mandrake cartoonists were friends.)
There's a page about him here.
So if nothing else, it means that the association between the word "mandrake" and stage magic goes beyond just the comic strip.
Mine has a built-in web browser, MIME extractor, yEnc support and a display engine optimized for fleshtones.
I call it "The XXX Windowing System".
Do a hex dump of an .o file, for example. cpp does the including and pipes the result to the code generator, which binarifies it unrecognizably.
And if you disassemble the results and look at the debug table, you can see exactly which parts of the code came from the included header files.
ONLY the FSF has ever interpreted library linking this way; that's what I mean by "viral"
How the FSF interprets it is irrelevant. The law says that if you take my code and modify it, the result is a derived work and anyone who wants to copy it needs both our permissions to do so. That's the only reason the FSF can enforce their interpretation. Linking and including both produce derived works because they both combine your code with someone elses' and those copyrights are all valid. Just because most of the time the library writers give blanket permission to copy binaries, it doesn't mean you always have the right to do it.
As Dawes says in one of his posts, their copyright ends at their API boundary.
He may think so, but it's not true.
To put it simply:
If they really want their reach to end at the API boundary, they should have said that in the license.
Not true. The semantics of the C 'include' directive are basically "copy-and-paste the contents of this file into the sources at this space" and the resulting code goes into the object file. A binary produced using a header file is a derived work of that header, even if the original source code is not, and so the XFree86 team has a partial copyright on it as a contributor.
And if you're distributing a statically-linked binary, the executable file is a merging (by means of a linker) of the object code produced from your source and the object code produced from their source and once again, they have a partial copyright on that source.
(And yes, the same is true of the Borland and Lattice headers and libraries. Only, because you've paid them money, they granted you the right to distribute their share in the resulting executable under your terms, more or less.)
The GPL is viral only because it is specifically written to be. More normal licenses -- such as this one -- are not.
Actually, copyright is intrinsically viral when it comes to derivative works. For example, the copyright to this Slashdot post partially belongs to you because it contains text you wrote. If I sold the movie rights to it, I'd have to cut you in on the deal.
In the same way, the XFree86 team is considered one of the copyright holders of your application binary if you link it against their libraries or include their headers. You may be able to plead fair use if they try to sue you, but nonetheless, they are the some of the authors of that executable. They own a share of that copyright and the license says what you can do with it.
Note that I said "can do", not "can't do". The license only tells you what are allowed to do, not what you're not allowed to do. Everything not permitted is forbidden (within the bounds of copyright law, anyway).
The license doesn't say anything about linking to applications as being different from merging. Therefore, we must assume that they consider that to fall into the category of "merging". Therefore, the conditions apply.
(Of course, your original source code remains untouched, so the license isn't "viral" the way the GPL is. You could compile and link it against a different implementation of X and distribute it under whatever terms that may impose. However, the new XFree86 license very much does restrict what you can do with your executable.)
linked work.
Actually, it is. From the new license:
... to deal in the Software without ... copies of the Software ... subject to ...
...
Permission is hereby granted
restriction, including without limitation the rights to use, copy,
modify, merge
the following conditions:
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution, and in the same place and form
as other copyright, license and disclaimer information.
3. The end-user documentation included with the redistribution,
if any, must include the following acknowledgment:
(Elided text marked--see the original for the missing bits.)
The problem is that "merging" clause.
If your program includes any of the X include files, you've now
merged it with those files, which are released under that license.
This is also the case if you've statically linked to any of the
libraries and probably also if you're dynamically linking to shared
libraries. (You might be able to make a "fair use" case for that, but
the headers will get you regardless.)
If we were talking about just the server, the above wouldn't be a
problem. However, major parts of XFree86 need to be merged with other
programs to be useful so, whether that was their intent or not, the
license as it stands is viral.
I think what's going on here is that there's some confusion about what's a derived work.
The new license applies to XFree86 and anything based on it. This sounds fair until you realize that if you write a program that just uses XFree86, you are, technically speaking, combining your code with theirs by linking to the xlibs and including the header files. This means you need to credit them. For Mandrake to use XFree86 4.0, they'd have to go through the documentation for every app and library that uses the xlibs and add the attribution.
It violates the GPL because it adds extra restrictions on what may be done with GPL'd code. The GPL allows you to distribute a GPL'd program without the XFree86 attribution but the new XFree86 license doesn't.
My take on this is that it's unintentional. I suspect that someone didn't think through the implications and that in a couple of days, the XFree86 team will amend the license to say that just connecting to the server or linking against the xlibs doesn't constitute a derived work. At least, that's my hope. Otherwise, it could take years for a new de-facto X implementation to emerge.
So my Linux apps will now seamlessly port to Windows? Great! Nobody will ever need to develop for Win32 again!
in spirit, if not the letter.
They make themselves look like police officers but they never identify themselves as police and don't wear uniforms. This way, they can claim that they aren't impersonating police officers, which is illegal.
They threatened the vendor and took his "contraband" but they turned it into an out-of-court legal settlement by getting him to sign the appropriate documents. This way, it's technically not vigilantism, even though that's the intent.
I have no doubt they've hired the best people available to keep them just barely on the legal side of the line. Convincing a jury that this is criminal activity will be a hard sell, and proving that the RIAA's upper management ordered the illegal actions will be even harder. Still, it would restore my faith in humanity to see the RIAA's leadership doing hard time for this.
Is it just me or is Darl going through the "How to Annoy the OSS Community" checklist?
He's already repeated every bit of MS LinuxFUD out there and publically supported the RIAA lawsuits so really, it was time for a DMCA takedown. Wake me up when he gets to biting the heads of cute baby penguins.
I'm sorry. I didn't know you had it that bad up there.
It's not quite that bad. For example, I still know almost nothing about Hillary Duff.
You forgot:
Sure it is! Do Unto Others.
Pfft. It's even simpler than that:
Thou shalt not steal.
Sending spam is theft, pure and simple. Spammers are using the recipients' money and time for their own ends. It's no different than embezzeling a dollar from every bank account in the country except that the latter at least doesn't render the entire banking system useless.