No, the argument is whether copyright infringement is "stealing" or not. It is not whether it is worse or not, though of course it is implied that "stealing" is worse.
Stealing the PhotoShop CD is 100% guaranteed to cost somebody some money (probably the store that purchased the CD from Adobe, they lost all the money they spent for it and also lose the potential profit from selling it).
Downloading the illegal copy of PhotoShop *may* mean you won't buy it, lets say it is 98% chance that it causes you to not buy a copy you would have (which is of course about 10,000 times too high of a percentage, but I am trying to humor you). In this case there is a 98% chance that you have deprived Adobe of the money the store would have given them and also you deprived the store of the profit. Thus by definition this is only 98% as bad.
I'm sorry, but it is impossible to make the damage equal no matter what you do.
Actually I'm not sure if this is legal, though many people here think it is.
The realistic problem is that any such service is way to easy to abuse so that you can get copies of stuff you don't own.
But even from a legal point of view, that rip is not of *your* copy of the music, but somebody else's. It may be a different mix or master disk or you could even claim the arrangement of scratches (or CD errors) is different and in some way it is not a copy of yours. If you don't disallow this, it gets difficult to disallow the ability to download other band's versions of some song you own. I think this may be an acceptable position to take to say that even this is wrong, though I bet I'm in the minority here.
Of course downloading the MP3 is wrong. The complaint here is that people keep calling it "stealing" when in fact you state right there that it is "violating the distribution clauses of copyright law".
Those clauses are not called the "stealing" clauses of copyright law" for very good reasons!
Your second highlighted example of "trade secrets" is not applicable. It is a *secret*, which is certainly not true of a piece of music on a CD.
I also believe your first highlighted example implies the ideas were secret (ie not yet published in the first person's book) but it is closer.
However I agree with the majority of posters here that most people think of "stealing" as depriving somebody of something, and that all uses of "stealing" of music imply that the existence of the copy stole some potential future sales of it. However it is well established that depriving somebody of future sales is not theft, it is the normal functioning of a free market.
If copying was really theft in most people's minds, there would be no need for copyright law, as there are much stronger laws covering theft. But there is a very good reason why copyright law exists: copying is not theft.
No actually I seriously respect his ability to get this thing to work at all. He also made it portable between NT and Linux (unfortunately it would not port to Win2K so we have to use the Linux version, but he was quite familiar with the abilities of both systems and the Linux version actually is slightly more reliable).
But this program convinced me that there is a mindset that says "more threads is better" and that this mindset is wrong. It is producing bloated slow libraries with locks around every single function (like putc() in the pthreads standard, thus killing the speed of the basic K&R design!). It also seems to be used 90% of the time for programming convienence so that state can be kept in local variables, something that could be solved by cooperative multitasking inside the program with some library support, rather than using real parallel multiprocessor threads.
You are talking about mulththreading the calculations along with a SINGLE thread that does the GUI, which can make sense. However it seems the original poster kept saying "multihtreaded GUI" which implies to me some scheme like having each widget have it's own thread. This serves no purpose except MicroSoft uses it so that COM objects can be closed-source.
I have no idea what you mean by "journal" or "log" based and would like an explanation.
I am working from the assumption that threads (as opposed to processes) are taking advantage of shared memory. It seems to me that if I have a big calculation that depends on some data structure that the GUI can modify, I have to stop the calculation before I can modify the structure, and I have to inform the parallel thread that the structure has changed (in my case I decided to tell it to restart the calculation from the start, which I was calling "killing the thread" although in fact I really set a flag that makes the threads throw an exception, they then go to code that waits for the GUI to unlock them so that they can start the calculation over again, I am not really creating & destroying threads).
Notice that in my case the threads are doing a calculation that can take several minutes, although they produce some results immediatly (a portion of an image) so the user can tell if they want to twiddle the controls some more.
It is possible that I am confused because you are considering calculations that are done in a fraction of a second, such as parallel updating of a complex OpenGL scene. In such cases it may make sense for the GUI to wait for the previous calculation to finish before updating the structures. This should produce good results as long as it is trivial to exclude the majority of GUI events as not modifying the data structures.
Other possibility is that you are assumming it is inexpensive to build a new data structure while keeping the old one in memory, destroying it only after the new one is built and the threads running the old one have either exited or are killed. This may be true but is certainly not in my case, where a huge savings is had by the reuse of cached information in the previous data structure.
Although I don't know what "journal" vs "log" are but they both sound like communication pipes. Unix has had pipes since 1972 so I don't think they are a recent innovation and in fact all possible uses for them have long been explored. Basically if you are avoiding use of shared memory then you are not using threads.
What I meant is the programs I have seen lock a piece of critical data in such a way that it is impossible for any two threads to be unlocked at any time. The code typically was like this:
Actually what drives down the cost is not that they have to give their customers the source code, but that they have to give those customers the right to redistribute the source code. Since some may give it away for free this limits the possible price.
It is also interesting that, contrary to popular belief, it does not force the price to zero. The fact that people are actually complaining that Lindows is not free is proof that you can sell GPL software for money. If the GPL made everything free than those people would have no complait as they would all organize and buy one copy and post the source on the net, all of which is allowed. The truth is that (whether Lindows itself is good or bad) there is value in finding it all packaged in one place, easy to locate on the net, bundled with things that are not GPL such as icons, and made by a trusted source.
I would agree with the rest of the responders here that you have no idea what you are talking about.
A correct multithreaded program is HARD!!!!! Anybody who thinks otherwise is an idiot. I have seen the results. All the systems I have seen are either broken or have so many locks in them that they may as well be single-threaded. Most Windows programmers use multithreading so that they can keep more state in local variables, which may be an ok goal but has nothing to do with speed. One of biggest buggiest programs here is a multh-threaded monstrosity written by a Windows program where there are 50 threads, ALL WAITING ON THE SAME SOCKET, and it crashes sparodically in the rare cases when two threads actually become alive at the same time. Every single rewrite to reduce the number of threads has greatly improved performance and reliability.
I have no idea why you think GUI should be multi-threaded. GUI has no reason to be fast, computers are MUCH faster than humans, at least at drawing junk on the screen. In fact the best way to do it is pseudo-multithreading, such as the method windows uses (gasp! Fact alert: it is NOT multithreaded, only one "DispatchMessage" is running at a time!).
I think perhaps you mean that the GUI should be running in a parallel thread with the calculations and there you have a point, however a lot of the problems are solved by deferred redraw, which the X toolkits do quite well (and in fact Windows is broken because it produes WM_PAINT events without knowing if the program has more processing to do).
Now if there are intense calculations I grant that parallel threads are necessary, and I am working on such a program, but I must warn you that it is extremely difficult: the GUI cannot modify ANY structure being used by the parallel thread, instead it must kill the threads, wait for them to stop, modify the structure, and start them again. If in fact nothing changed you need to restart so the partially-completed answer from last time can be reused, this means you must write all the code you would for a single-threaded appliation, it does NOT save you anything. If you restart the complete parallel calculation you will get an unresponsive program if that parallel calculation takes more than a second or so. You could instead do a fancy test to see if your modifications will change the data before you kill the threads and commit them, but this often requires you to calculate the modifications twice, and the overhead of this may well kill the advantage of the parallel thread, and at least in my example this was far worse than reusing all the single-threaded restart code.
More importantly, the GPL grants you additional rights that you do not normally have. It does not try to remove rights, which is what most EULA's do. So, even though there is nothing forcing you to agree to the GPL, you have no incentive not to agree with it. This makes enforcing it unnecessary and therefore any decisions about EULA's cannot possibly affect it.
NeXT (I programmed these things in the 1980's) certainly supported drawing using PostScript paths, but all "icons" were tiff files. In fact they added a special tag to tiff to represent their 2-bit gray screen.
Until recently vector-based icons were way too slow. Except for the Irix ones, which were neceessarily quite simple. This simplicity did add to their appeal I think, though they never really put some good graphics designers on it.
KDE and Gnome and OS/X all render the vectors into pixmaps and then blast the pixmaps on the screen. OS/X certainly supports pixmaps and all the icons that appear to be airbrushed are bitmaps. They scale quickly and nicely because they have them carefully rendered at several resolutions and use mipmapping (the same technique your fancy graphics card uses for textures when it is in it's highest-quality mode) to scale.
Ignoring the drawing speed vector icons are much more efficient and take far less memory. In fact the earliest icons could be considered vector-based, they were drawn on vector screens by machines where 8K of memory was expensive.
I suspect not offering service at all to Linux is worse than refusing tech support, so I can't understand this argument.
I realize there are other very legitimate reasons for not offering the Linux version (ie it takes work to implement it) but this tech-support excuse does not make sense. There are plenty of compainies that do exactly what I suggest and the Linux crowds are not after them, in fact they often praise them for offering anything at all!
You will not be able to get the DRM encryption added to your recording without signing a contract with a major record label. So this is absolutely no help for the independent band at all.
In fact if systems start coming out that *only* play DRM stuff (because non-DRM stuff is obviously pirated), this is a trememdous blow to independent artists. They will not be able to distribute music, even for free.
It is not possible to make X11 look like Aqua without changing the X11 applications themselves. This is because they draw at a level where the system cannot tell if a button or slider or whatever is being drawn. This is actually a good thing, but it does make it impossible to make such modifications. It may be possible to modify Qt or another toolkit, but since you would have to relink with that you might as well link with a Qt ported to OS/X native anyway.
I believe Apple insisting that their GUI be a closed box is a good thing. There is documented interfaces, and the fact that the system design lets somebody reverse-engineer the undocumented interfaces does not mean that people should be allowed to use them. If they did this then Apple could never change the implementation because they would be forced to be compatable with stuff they never designed as a public interface.
Of course somebody should check that the Apple apps are not using the undocumented interfaces (I suspect they are not). If they are they can be acused of doing what MicroSoft was doing.
Say "we don't provide technical support for Linux" and hang up. Problem solved.
Somehow most of the broadband and DSL providers manage to connect to Linux without having anybody in tech support able to answer questions, so this is NOT a reason.
Nothing in any license prevents you from profiting from your own code. For instance it is common to put stuff out under the GPL and make in-house modifications that are not released and are sold for a profit.
So your last point is no problem, it is possible under any license, even public domain.
There certainly are lots of examples of "not for profit" licenses, even though RMS does not like them.
You seem to think the GPL can force somebody to reveal their source code. It can't. What it can do is exactly what you state as the alternative, it can force somebody to *not* distribute their program at all.
It is true that in *most* cases where the GPL has been tried, the guilty party has released their source code. This is probably because it was considered the nicest thing to do. However I am fairly certain there are cases where a party has pulled a product based on GPL code from the market rather than release the source code, such as some Linux drivers.
It would be nice if somebody here came up with some examples, but the fact is that you are arguing a position that is well known to be false. The GPL cannot force you to reveal anything, it is simply a license that allows you under certain rules to ignore copyright law.
I would agree except for the Unicode. I think UTF-8 should be used everywhere, as it is upwardly-compatable with 8-bit Ascii, and this avoids the need for any legacy interfaces, and makes it pretty obvious how to store the filenames on older systems.
It may also be a good idea to allow float and double values in system interfaces whereever they make sense, such as time intervals.
Nothing changes the fact that I don't think people have any right to trade music they don't own the rights to. Nothing changes the fact that I read and post on Slashdot. Therefore the assumption that all Slashdot people want to steal music is false.
I worked with even earlier versions of Windows that were sent to developers, including the tiled ones (ie 1 and 2). I remember the Reversi game well, but I can't remember if the Solitaire game was also included.
Actually the earliest versions of Windows had "Othello" (or "Reversi") as a sample game. That of course required intelligence on the user's part, and MicroSoft apparently changed their target audience with later versions:-)
WIthout making any claims about what is better or worse, your history is somewhat backwards.
"Contextual menus" were certainly first, the Xerox Parc and the Lisp Machine used these. Often these were the *only* thing you could do with the mouse. They also had the incredible stupid UI design that once you popped-up a menu you had to choose some item, leading the user to have to pick the least-destructive action when they accidentally popped it up.
Less certainly, but I think per-window menus were next. Take a look at older XViews or early X interfaces. At that time only *some* programs had menus, so it made perfect sense to put them on the windows, rather than reserve a piece of expensive screen space for a menu that was not always used. Also point-to-type was commonly used and it is impossible to use that with a shared menubar.
I never saw shared menu area until the Lisa appeared. The original Mac, though later than the Lisa, did not count because it was single-tasking (the whole screen switched when you changed apps, so it's hard to claim the menu bar is special). The "switcher" versions of Mac where you could still see other windows is probably the first version seen by many people.
Okay. I believe that taking some material that somebody has a copyright on and making a copy of it and giving or selling it to somebody else is a violation of copyright law and should be prosecuted. I also believe that 95% of the reason for P2P is to violate copyright law, despite stupid assertions otherwise here. All legal uses of P2P could be done with a normal central server, it is pretty obvious that the only advantage of P2P is that the source is hard to locate and it is difficult for a central authority to shut down, which only serves the purpose of doing something illegal.
Now here is a quote from your article: "Please someone intelligently defend the right to trade music you don't own the rights to." This is cut & pasted from your posting.
You may pretend you are saying "I would like to see an intelligent defense of this unusual opinion".
But from your wording, I think you are saying "everybody here on SlashDot thinks it should be ok to steal music, even though there is no intelligent defense for it, I will prove there is no intelligent defense by cleverly asking for one, knowing I won't get any.".
Slashdot Mirror
Stealing the PhotoShop CD is 100% guaranteed to cost somebody some money (probably the store that purchased the CD from Adobe, they lost all the money they spent for it and also lose the potential profit from selling it).
Downloading the illegal copy of PhotoShop *may* mean you won't buy it, lets say it is 98% chance that it causes you to not buy a copy you would have (which is of course about 10,000 times too high of a percentage, but I am trying to humor you). In this case there is a 98% chance that you have deprived Adobe of the money the store would have given them and also you deprived the store of the profit. Thus by definition this is only 98% as bad.
I'm sorry, but it is impossible to make the damage equal no matter what you do.
The realistic problem is that any such service is way to easy to abuse so that you can get copies of stuff you don't own.
But even from a legal point of view, that rip is not of *your* copy of the music, but somebody else's. It may be a different mix or master disk or you could even claim the arrangement of scratches (or CD errors) is different and in some way it is not a copy of yours. If you don't disallow this, it gets difficult to disallow the ability to download other band's versions of some song you own. I think this may be an acceptable position to take to say that even this is wrong, though I bet I'm in the minority here.
Those clauses are not called the "stealing" clauses of copyright law" for very good reasons!
I also believe your first highlighted example implies the ideas were secret (ie not yet published in the first person's book) but it is closer.
However I agree with the majority of posters here that most people think of "stealing" as depriving somebody of something, and that all uses of "stealing" of music imply that the existence of the copy stole some potential future sales of it. However it is well established that depriving somebody of future sales is not theft, it is the normal functioning of a free market.
If copying was really theft in most people's minds, there would be no need for copyright law, as there are much stronger laws covering theft. But there is a very good reason why copyright law exists: copying is not theft.
But this program convinced me that there is a mindset that says "more threads is better" and that this mindset is wrong. It is producing bloated slow libraries with locks around every single function (like putc() in the pthreads standard, thus killing the speed of the basic K&R design!). It also seems to be used 90% of the time for programming convienence so that state can be kept in local variables, something that could be solved by cooperative multitasking inside the program with some library support, rather than using real parallel multiprocessor threads.
I have no idea what you mean by "journal" or "log" based and would like an explanation.
I am working from the assumption that threads (as opposed to processes) are taking advantage of shared memory. It seems to me that if I have a big calculation that depends on some data structure that the GUI can modify, I have to stop the calculation before I can modify the structure, and I have to inform the parallel thread that the structure has changed (in my case I decided to tell it to restart the calculation from the start, which I was calling "killing the thread" although in fact I really set a flag that makes the threads throw an exception, they then go to code that waits for the GUI to unlock them so that they can start the calculation over again, I am not really creating & destroying threads).
Notice that in my case the threads are doing a calculation that can take several minutes, although they produce some results immediatly (a portion of an image) so the user can tell if they want to twiddle the controls some more.
It is possible that I am confused because you are considering calculations that are done in a fraction of a second, such as parallel updating of a complex OpenGL scene. In such cases it may make sense for the GUI to wait for the previous calculation to finish before updating the structures. This should produce good results as long as it is trivial to exclude the majority of GUI events as not modifying the data structures.
Other possibility is that you are assumming it is inexpensive to build a new data structure while keeping the old one in memory, destroying it only after the new one is built and the threads running the old one have either exited or are killed. This may be true but is certainly not in my case, where a huge savings is had by the reuse of cached information in the previous data structure.
Although I don't know what "journal" vs "log" are but they both sound like communication pipes. Unix has had pipes since 1972 so I don't think they are a recent innovation and in fact all possible uses for them have long been explored. Basically if you are avoiding use of shared memory then you are not using threads.
What I meant is the programs I have seen lock a piece of critical data in such a way that it is impossible for any two threads to be unlocked at any time. The code typically was like this:
b sp; wait_for_next_message();
for (;;) {
lock(big_lock_shared_by_everybody);
figure_out_what_to_do();
lock(small_lock_around_my_work);
do_about_95%_of_the_work();
unlock(big_lock_shared_by_everybody);
do_about_5%_of_the_work();
unlock(small_lock_around_my_work);
do_a_bit_more_that_should_be_locked_anyway();
&n
}
It is also interesting that, contrary to popular belief, it does not force the price to zero. The fact that people are actually complaining that Lindows is not free is proof that you can sell GPL software for money. If the GPL made everything free than those people would have no complait as they would all organize and buy one copy and post the source on the net, all of which is allowed. The truth is that (whether Lindows itself is good or bad) there is value in finding it all packaged in one place, easy to locate on the net, bundled with things that are not GPL such as icons, and made by a trusted source.
A correct multithreaded program is HARD!!!!! Anybody who thinks otherwise is an idiot. I have seen the results. All the systems I have seen are either broken or have so many locks in them that they may as well be single-threaded. Most Windows programmers use multithreading so that they can keep more state in local variables, which may be an ok goal but has nothing to do with speed. One of biggest buggiest programs here is a multh-threaded monstrosity written by a Windows program where there are 50 threads, ALL WAITING ON THE SAME SOCKET, and it crashes sparodically in the rare cases when two threads actually become alive at the same time. Every single rewrite to reduce the number of threads has greatly improved performance and reliability.
I have no idea why you think GUI should be multi-threaded. GUI has no reason to be fast, computers are MUCH faster than humans, at least at drawing junk on the screen. In fact the best way to do it is pseudo-multithreading, such as the method windows uses (gasp! Fact alert: it is NOT multithreaded, only one "DispatchMessage" is running at a time!).
I think perhaps you mean that the GUI should be running in a parallel thread with the calculations and there you have a point, however a lot of the problems are solved by deferred redraw, which the X toolkits do quite well (and in fact Windows is broken because it produes WM_PAINT events without knowing if the program has more processing to do).
Now if there are intense calculations I grant that parallel threads are necessary, and I am working on such a program, but I must warn you that it is extremely difficult: the GUI cannot modify ANY structure being used by the parallel thread, instead it must kill the threads, wait for them to stop, modify the structure, and start them again. If in fact nothing changed you need to restart so the partially-completed answer from last time can be reused, this means you must write all the code you would for a single-threaded appliation, it does NOT save you anything. If you restart the complete parallel calculation you will get an unresponsive program if that parallel calculation takes more than a second or so. You could instead do a fancy test to see if your modifications will change the data before you kill the threads and commit them, but this often requires you to calculate the modifications twice, and the overhead of this may well kill the advantage of the parallel thread, and at least in my example this was far worse than reusing all the single-threaded restart code.
More importantly, the GPL grants you additional rights that you do not normally have. It does not try to remove rights, which is what most EULA's do. So, even though there is nothing forcing you to agree to the GPL, you have no incentive not to agree with it. This makes enforcing it unnecessary and therefore any decisions about EULA's cannot possibly affect it.
Until recently vector-based icons were way too slow. Except for the Irix ones, which were neceessarily quite simple. This simplicity did add to their appeal I think, though they never really put some good graphics designers on it.
KDE and Gnome and OS/X all render the vectors into pixmaps and then blast the pixmaps on the screen. OS/X certainly supports pixmaps and all the icons that appear to be airbrushed are bitmaps. They scale quickly and nicely because they have them carefully rendered at several resolutions and use mipmapping (the same technique your fancy graphics card uses for textures when it is in it's highest-quality mode) to scale.
Ignoring the drawing speed vector icons are much more efficient and take far less memory. In fact the earliest icons could be considered vector-based, they were drawn on vector screens by machines where 8K of memory was expensive.
I realize there are other very legitimate reasons for not offering the Linux version (ie it takes work to implement it) but this tech-support excuse does not make sense. There are plenty of compainies that do exactly what I suggest and the Linux crowds are not after them, in fact they often praise them for offering anything at all!
In fact if systems start coming out that *only* play DRM stuff (because non-DRM stuff is obviously pirated), this is a trememdous blow to independent artists. They will not be able to distribute music, even for free.
Better start learning about selling insurance.
I believe Apple insisting that their GUI be a closed box is a good thing. There is documented interfaces, and the fact that the system design lets somebody reverse-engineer the undocumented interfaces does not mean that people should be allowed to use them. If they did this then Apple could never change the implementation because they would be forced to be compatable with stuff they never designed as a public interface.
Of course somebody should check that the Apple apps are not using the undocumented interfaces (I suspect they are not). If they are they can be acused of doing what MicroSoft was doing.
The dish contains a transmitter able to reach a sattellite in orbit? Does the FCC know about this?
Somehow most of the broadband and DSL providers manage to connect to Linux without having anybody in tech support able to answer questions, so this is NOT a reason.
Sorry I'm probably confusing which message I am replying to. I may have been replying to the person you were replying to.
So your last point is no problem, it is possible under any license, even public domain.
There certainly are lots of examples of "not for profit" licenses, even though RMS does not like them.
It is true that in *most* cases where the GPL has been tried, the guilty party has released their source code. This is probably because it was considered the nicest thing to do. However I am fairly certain there are cases where a party has pulled a product based on GPL code from the market rather than release the source code, such as some Linux drivers.
It would be nice if somebody here came up with some examples, but the fact is that you are arguing a position that is well known to be false. The GPL cannot force you to reveal anything, it is simply a license that allows you under certain rules to ignore copyright law.
It may also be a good idea to allow float and double values in system interfaces whereever they make sense, such as time intervals.
Nothing changes the fact that I don't think people have any right to trade music they don't own the rights to. Nothing changes the fact that I read and post on Slashdot. Therefore the assumption that all Slashdot people want to steal music is false.
I worked with even earlier versions of Windows that were sent to developers, including the tiled ones (ie 1 and 2). I remember the Reversi game well, but I can't remember if the Solitaire game was also included.
Actually the earliest versions of Windows had "Othello" (or "Reversi") as a sample game. That of course required intelligence on the user's part, and MicroSoft apparently changed their target audience with later versions :-)
"Contextual menus" were certainly first, the Xerox Parc and the Lisp Machine used these. Often these were the *only* thing you could do with the mouse. They also had the incredible stupid UI design that once you popped-up a menu you had to choose some item, leading the user to have to pick the least-destructive action when they accidentally popped it up.
Less certainly, but I think per-window menus were next. Take a look at older XViews or early X interfaces. At that time only *some* programs had menus, so it made perfect sense to put them on the windows, rather than reserve a piece of expensive screen space for a menu that was not always used. Also point-to-type was commonly used and it is impossible to use that with a shared menubar.
I never saw shared menu area until the Lisa appeared. The original Mac, though later than the Lisa, did not count because it was single-tasking (the whole screen switched when you changed apps, so it's hard to claim the menu bar is special). The "switcher" versions of Mac where you could still see other windows is probably the first version seen by many people.
Now here is a quote from your article: "Please someone intelligently defend the right to trade music you don't own the rights to." This is cut & pasted from your posting.
You may pretend you are saying "I would like to see an intelligent defense of this unusual opinion".
But from your wording, I think you are saying "everybody here on SlashDot thinks it should be ok to steal music, even though there is no intelligent defense for it, I will prove there is no intelligent defense by cleverly asking for one, knowing I won't get any.".