The application bundles in effect set LD_LIBRARY_PATH to the app directory before executing the program. I know because we do OS/X development and this is how we test the software without putting it into an App bundle.
It will also pick up.dylib files in/usr/lib and anywhere else on the configured shared library path.
An app bundle has an executable file inside it that can be run with the exec() call, exactly like any other Unix executable.
Hallelujah! One of the FUD-masters here finally worded a sentence with the word "compatible" in the correct direction! Will wonders never cease?
Of course, the requirement that the copyright notice remain in the source code (the 2-clause BSD license) is not an additional restriction, as it is part of the GPL as well. So your argument is bogus. But I have to give you points for not reversing things into weird MS-PL world!
I think you misread "cannot" for "can" in my statement. Nice reading comprehension. I have put it in bold so you can see it:
You cannot put MS-PL code into a BSD program. If you could, then you could put it into a GPL program, since you can put BSD code into a GPL program!
I am agreeing with you, the thing described above is NOT allowed.
My argument is with the statement "The MS-PL is compatible with BSD". This implies that the above situation *is* allowed. The correct statement is "The BSD is compatible with the MS-PL", unless you want to revere the normal directional meaning of the word "compatible" for FUD reasons.
Saying "The BSD license is compatible with the MS-PL" is a truthful statement. Of course it is also truthful to say "The BSD license is compatible with the GPL" and "The BSD license is compatible with closed source". That of course points out that the MS-PL is not very special at all, which defeats the original propaganda purpose of wording the sentence very strangely.
The GPL requires all other parts to be compatible with the GPL. This does not magically change them to be GPL, the original code is still under whatever license it was under originally. The FUD-makers like to pretend the GPL has some magical ability to alter the license on existing code.
The MS-PL also requires that code distributed with it be compatible with it's license. If that was not true then you could make the your resulting program be GPL with a licensing exception for the MS-PL part. Microsoft has purposly worded the license so this is impossible.
OS/X does use shared libraries. The filenames end in.dylib. I don't know what the grandparent is thinking. Possibly confused by the application bundles, but the files inside there *are* shared libraries.
First OS/X does use shared libraries. They are just like BSD ones, and thus they are actually *more* different than Windows.dll's than Linux.so files are (in particular a shared library can link to a symbol defined in the executable, this is only possible with a rarely-used option on Linux and impossible in Windows).
Second, you can emulate Unix on Windows, but most software on Windows is not using those calls. On OS/X there is no emulation, all the software uses the same calls that any ported Unix software is using. A pretty huge difference.
He's talking about the Apple office products and other things that come "free" with the system, similar to how Open Office comes for "free" with Linux.
Though I agree that if you buy Microsoft Office for Windows, it is fair to compare to buying the OS/X copy for OS/X, and perhaps to buying it and running it under Wine in Linux. Far too many people think Office is included for free with Windows.
I have no idea what he was trying to say, but it is possible he was saying "OS/X is a pig" and "a GUI is lipstick" and that the GUI would not make OS/X not be a pig. IE he *dislikes* OS/X. That would agree with the normal meaning of that saying.
You are right that if he *likes* OS/X and thinks adding GUI is unnecessary, he is using that saying wrong.
Nothing "becomes" GPL or MS-PL just because it is incorporated into the license. The original code still exists under it's original license. Saying that either one magically changes the code is FUD. In fact the MS-PL and GPL are ABSOLUTELY IDENTICAL in their restrictions.
What both do is purposely disallow linking with code that is incompatible with their restrictions and then distributing the result. GPL code can be linked with BSD and GPL code. MS-PL code can be linked with BSD and MS-PL code.
The MS-PL is missing the "distribution" wording so it may be slightly more restrictive in that it seems to restrict use as well, but as I understand it copyright law pretty much means you can only restrict distribution anyway.
It also tries to allow distribution of "compiled" code without any restrictions, but I suspect this is bogus as it is difficult to say at what point the code is "compiled". I can run the macro expansions on it and claim it is "compiled". I doubt Microsoft is stupid enough to allow that result to be GPL'd, so it is probably best to treat the compiled result as having the same redistribution requirements as the source code.
The original poster said "the MS-PL is compatible with the BSD license". I have no idea what you are saying.
Obviously you cannot change MS-PL code into BSD code. If you could, you could then change it into GPL code. Let's assume MicroSoft's lawyers are not that stupid. I'm going to assume you are not that stupid either, but you do seem to have a mental block that makes it impossible for you to admit that the MS-PL and the GPL are identical in their restrictions.
PS: you might also investigate "exceptions" which is what everybody other than Microsoft does when they want to release source code but not force GPL compliance. But Microsoft purposely ignored these because their #1 priority was to make sure it was GPL-incompatible. Take a look at the FLTK license to see what I do with my code. But you know asshole attitudes like the original posters are what drives people to slap the GPL on their code.
If you take BSD code and combine it with MS-PL, the result is not BSD licensed. This should be pretty obvious, because everybody, including you, know that MS-PL code cannot be combined with GPL code. Since BSD code can, MS-PL is not BSD and not "compatible" with it.
Trying to pretend they are different is propaganda, whether the FSF or an astroturfer does it. Get the facts.
I find it interesting that you accuse the FSF of doing word games by saying "the GPL is compatible with the BSD license" while apparently defending the original poster who literally says "the MS-PL is compatible with the BSD license".
In my opinon the two statements are equally wrong, yet apparently people will only attact the one on the side they disagree with.
You can put BSD code into a GPL program, exactly as you state.
You cannot put MS-PL code into a BSD program. If you could, then you could put it into a GPL program, since you can put BSD code into a GPL program!
The two licenses are IDENTICAL. BSD is compatible with both of them. They are both incompatible with the BSD and with each other.
Pretending that somehow the original BSD code vaporizes and disappears when somebody uses it in a GPL program, but this magical effect does not happen with the MS-PL program is a nice piece of FUD, too.
The BSD is one-way compatible with the GPL, exactly like you say. You can take BSD code and make it GPL.
The BSD is one-way compatible with the MS-PL as well. You can take BSD code and make it MS-PL.
Note that the position of the MS-PL and the GPL are the same in these two statements.
I have *never* heard somebody say "the GPL is compatible with the BSD license" and I doubt you would either. It is backwards from the way most people interpret the one-way nature. But for some reason the poster thought to reverse the standard meaning when talking about the MS-PL. Sounds like carefully calculated FUD.
An accurate statement would be "the BSD is compatible with the MS-PL". Of course the BSD is compatible with the GPL as well, and with virtually every other license out there including proprietary ones, so big deal!
Absolutely agree that you should get a bill saying "you used this many GB" and multiply by the rate and that is what you pay, and that would by far make the most sense.
The service providers don't want this however. Same reason they only sell cable tv as "packages". Lots of people will end up paying a lot less, and those that pay more will have a strong incentive to go somewhere else. Also users will probably figure out that Flash ads are actually costing them 1 cent each (or whatever) and then they are going to be mad and *really* start blocking them.
For those reasons I don't think this is going to happen. I actually feel that a cap (plus the ability to do something on a web page that says "I know my bill will be increased, please turn off the cap now") is the best solution that anybody will actually consider.
It's impossible to be compatible with the BSD license and not be compatible with the GPL, because BSD is compatible with the GPL.
Unless you have some strange backwards definition of compatible, under which you would say "the GPL is compatible with the BSD license" because you can take BSD code and relicense it as GPL. However I think most people consider that statement false, while "the BSD is compatible with the GPL" is the true statement.
The fact is that BSD is compatible with the MS-PL and BSD is compatible with GPL. The BSD is compatible with a *lot* of licenses, including closed-source with a NDA.
The problem with X window resizing is because two different asynchronous programs are drawing parts of the window: the window manager draws the border and the program draws the interior. On Windows, in effect, the system draws the border and then calls a function from the program to draw the interior, so they are always in sync, ie they always draw in the same order and one after another.
This certainly is a problem and X should be fixed (by (HORRORS!) letting programs draw their own window borders). However it is not due to communication speed or latency and thus your argument against it is invalid.
True but for complex programs (of which ours is one example) we cannot use the OSX floating windows. The problem is that they disappear if you go to another application. This is great if they have trivial information in them, but if you put any kind of complicated information in that somebody wants to refer to when using another program, they are useless.
Both Windows and Linux keep child windows on screen when the program is not active (well I suppose some Linux WM could hide them but never saw one do that).
On OSX we instead use some other hints so the windows stay on top but they are not the floating windows that the system wants us to use.
Ignore this line it is here to try to get Slashdot to allow me to submit.
PS: Gimp does not work even in Gnome for me in Ubuntu 8.04, however it does work in 8.10, even if you have multiple images open. Clicking either image raises it and the toolbars, but not the other image. And you only get an entry for each image in the taskbar.
However I think my complaint still stands. I'm sure Gimp and Metacity do this with a whole raft of complex window properties, while my solution is absurdly trivial.
Of course they may have done it "right" with a single window property, which was "don't raise this window when the user clicks on it" but I am quite willing to bet they did not figure this out and have instead made the 100x more complicated solution.
PS: I'm sure somebody will argue with me about this. Please before arguing, get the following fact through your skull: A program can raise it's own window. Any argument that ignores this fact is invalid.
You have valid complaints but you are lacking with solutions. The basic problem is a bug copied from Windows, and your "solutions" are the same workarounds everybody has been forced to use on Windows, and forced to do for so long that nobody seems to even realize that there was another way at one time.
Here is how to fix it for real, but the Gnome and freedesktop and even Windows users refuse to hear me:
Step ONE: STOP RAISING THE WINDOWS WHEN THE USER CLICKS ON THEM!!!!!!
Step TWO: Gimp could then raise it's own windows, including the toolbars, when the painting is clicked on.
Wow, that was hard! But I have been trying to fight this for probably 15 years. It is hopeless, and this crap can be laid right on Microsoft for making their system do this, and a lot of clueless people who just cannot see the easy solution, and so they suggest MDI and "dockable toolbars" and all kinds of other crap in order to work around Microsoft's stupid bugs and Gnome/KDE/everybody's slavish copying of them.
You have it somewhat backwards. Lock-in causes backwards compatibility, not the other way around.
The weird thing is that Microsoft is as much trapped by it's own monopoly as anybody else. They cannot be incompatible, people will just continue using the stuff they already bought, or perhaps they would lose to some competitor using Wine or something and thus being more compatible. The very thing that traps everybody else into being unable to compete with Microsoft also traps themselves into being unable to compete with themselves.
Slashdot Mirror
With that sort of nitpicking, the BSD license is incompatible with *everything*, including the MS-PL.
The GPL does not require a specific disclaimer. The preamble recommends one however.
An OS/X .dylib file is a BSD shared library.
The application bundles in effect set LD_LIBRARY_PATH to the app directory before executing the program. I know because we do OS/X development and this is how we test the software without putting it into an App bundle.
It will also pick up .dylib files in /usr/lib and anywhere else on the configured shared library path.
An app bundle has an executable file inside it that can be run with the exec() call, exactly like any other Unix executable.
Hallelujah! One of the FUD-masters here finally worded a sentence with the word "compatible" in the correct direction! Will wonders never cease?
Of course, the requirement that the copyright notice remain in the source code (the 2-clause BSD license) is not an additional restriction, as it is part of the GPL as well. So your argument is bogus. But I have to give you points for not reversing things into weird MS-PL world!
I think you misread "cannot" for "can" in my statement. Nice reading comprehension. I have put it in bold so you can see it:
You cannot put MS-PL code into a BSD program. If you could, then you could put it into a GPL program, since you can put BSD code into a GPL program!
I am agreeing with you, the thing described above is NOT allowed.
My argument is with the statement "The MS-PL is compatible with BSD". This implies that the above situation *is* allowed. The correct statement is "The BSD is compatible with the MS-PL", unless you want to revere the normal directional meaning of the word "compatible" for FUD reasons.
Saying "The BSD license is compatible with the MS-PL" is a truthful statement. Of course it is also truthful to say "The BSD license is compatible with the GPL" and "The BSD license is compatible with closed source". That of course points out that the MS-PL is not very special at all, which defeats the original propaganda purpose of wording the sentence very strangely.
The GPL requires all other parts to be compatible with the GPL. This does not magically change them to be GPL, the original code is still under whatever license it was under originally. The FUD-makers like to pretend the GPL has some magical ability to alter the license on existing code.
The MS-PL also requires that code distributed with it be compatible with it's license. If that was not true then you could make the your resulting program be GPL with a licensing exception for the MS-PL part. Microsoft has purposly worded the license so this is impossible.
Actually Sun was pushing OpenLook. CDE is mostly based on HP-UX's desktop.
OS/X does use shared libraries. The filenames end in .dylib. I don't know what the grandparent is thinking. Possibly confused by the application bundles, but the files inside there *are* shared libraries.
That sounds wrong to me.
First OS/X does use shared libraries. They are just like BSD ones, and thus they are actually *more* different than Windows .dll's than Linux .so files are (in particular a shared library can link to a symbol defined in the executable, this is only possible with a rarely-used option on Linux and impossible in Windows).
Second, you can emulate Unix on Windows, but most software on Windows is not using those calls. On OS/X there is no emulation, all the software uses the same calls that any ported Unix software is using. A pretty huge difference.
He's talking about the Apple office products and other things that come "free" with the system, similar to how Open Office comes for "free" with Linux.
Though I agree that if you buy Microsoft Office for Windows, it is fair to compare to buying the OS/X copy for OS/X, and perhaps to buying it and running it under Wine in Linux. Far too many people think Office is included for free with Windows.
I have no idea what he was trying to say, but it is possible he was saying "OS/X is a pig" and "a GUI is lipstick" and that the GUI would not make OS/X not be a pig. IE he *dislikes* OS/X. That would agree with the normal meaning of that saying.
You are right that if he *likes* OS/X and thinks adding GUI is unnecessary, he is using that saying wrong.
Nothing "becomes" GPL or MS-PL just because it is incorporated into the license. The original code still exists under it's original license. Saying that either one magically changes the code is FUD. In fact the MS-PL and GPL are ABSOLUTELY IDENTICAL in their restrictions.
What both do is purposely disallow linking with code that is incompatible with their restrictions and then distributing the result. GPL code can be linked with BSD and GPL code. MS-PL code can be linked with BSD and MS-PL code.
The MS-PL is missing the "distribution" wording so it may be slightly more restrictive in that it seems to restrict use as well, but as I understand it copyright law pretty much means you can only restrict distribution anyway.
It also tries to allow distribution of "compiled" code without any restrictions, but I suspect this is bogus as it is difficult to say at what point the code is "compiled". I can run the macro expansions on it and claim it is "compiled". I doubt Microsoft is stupid enough to allow that result to be GPL'd, so it is probably best to treat the compiled result as having the same redistribution requirements as the source code.
The original poster said "the MS-PL is compatible with the BSD license". I have no idea what you are saying.
Obviously you cannot change MS-PL code into BSD code. If you could, you could then change it into GPL code. Let's assume MicroSoft's lawyers are not that stupid. I'm going to assume you are not that stupid either, but you do seem to have a mental block that makes it impossible for you to admit that the MS-PL and the GPL are identical in their restrictions.
PS: you might also investigate "exceptions" which is what everybody other than Microsoft does when they want to release source code but not force GPL compliance. But Microsoft purposely ignored these because their #1 priority was to make sure it was GPL-incompatible. Take a look at the FLTK license to see what I do with my code. But you know asshole attitudes like the original posters are what drives people to slap the GPL on their code.
If you take BSD code and combine it with MS-PL, the result is not BSD licensed. This should be pretty obvious, because everybody, including you, know that MS-PL code cannot be combined with GPL code. Since BSD code can, MS-PL is not BSD and not "compatible" with it.
Trying to pretend they are different is propaganda, whether the FSF or an astroturfer does it. Get the facts.
I find it interesting that you accuse the FSF of doing word games by saying "the GPL is compatible with the BSD license" while apparently defending the original poster who literally says "the MS-PL is compatible with the BSD license".
In my opinon the two statements are equally wrong, yet apparently people will only attact the one on the side they disagree with.
You can put BSD code into a GPL program, exactly as you state.
You cannot put MS-PL code into a BSD program. If you could, then you could put it into a GPL program, since you can put BSD code into a GPL program!
The two licenses are IDENTICAL. BSD is compatible with both of them. They are both incompatible with the BSD and with each other.
Pretending that somehow the original BSD code vaporizes and disappears when somebody uses it in a GPL program, but this magical effect does not happen with the MS-PL program is a nice piece of FUD, too.
I think I'm not explaining this right.
The BSD is one-way compatible with the GPL, exactly like you say. You can take BSD code and make it GPL.
The BSD is one-way compatible with the MS-PL as well. You can take BSD code and make it MS-PL.
Note that the position of the MS-PL and the GPL are the same in these two statements.
I have *never* heard somebody say "the GPL is compatible with the BSD license" and I doubt you would either. It is backwards from the way most people interpret the one-way nature. But for some reason the poster thought to reverse the standard meaning when talking about the MS-PL. Sounds like carefully calculated FUD.
An accurate statement would be "the BSD is compatible with the MS-PL". Of course the BSD is compatible with the GPL as well, and with virtually every other license out there including proprietary ones, so big deal!
Absolutely agree that you should get a bill saying "you used this many GB" and multiply by the rate and that is what you pay, and that would by far make the most sense.
The service providers don't want this however. Same reason they only sell cable tv as "packages". Lots of people will end up paying a lot less, and those that pay more will have a strong incentive to go somewhere else. Also users will probably figure out that Flash ads are actually costing them 1 cent each (or whatever) and then they are going to be mad and *really* start blocking them.
For those reasons I don't think this is going to happen. I actually feel that a cap (plus the ability to do something on a web page that says "I know my bill will be increased, please turn off the cap now") is the best solution that anybody will actually consider.
It's impossible to be compatible with the BSD license and not be compatible with the GPL, because BSD is compatible with the GPL.
Unless you have some strange backwards definition of compatible, under which you would say "the GPL is compatible with the BSD license" because you can take BSD code and relicense it as GPL. However I think most people consider that statement false, while "the BSD is compatible with the GPL" is the true statement.
The fact is that BSD is compatible with the MS-PL and BSD is compatible with GPL. The BSD is compatible with a *lot* of licenses, including closed-source with a NDA.
You are incorrect.
The problem with X window resizing is because two different asynchronous programs are drawing parts of the window: the window manager draws the border and the program draws the interior. On Windows, in effect, the system draws the border and then calls a function from the program to draw the interior, so they are always in sync, ie they always draw in the same order and one after another.
This certainly is a problem and X should be fixed (by (HORRORS!) letting programs draw their own window borders). However it is not due to communication speed or latency and thus your argument against it is invalid.
True but for complex programs (of which ours is one example) we cannot use the OSX floating windows. The problem is that they disappear if you go to another application. This is great if they have trivial information in them, but if you put any kind of complicated information in that somebody wants to refer to when using another program, they are useless.
Both Windows and Linux keep child windows on screen when the program is not active (well I suppose some Linux WM could hide them but never saw one do that).
On OSX we instead use some other hints so the windows stay on top but they are not the floating windows that the system wants us to use.
Ignore this line it is here to try to get Slashdot to allow me to submit.
PS: Gimp does not work even in Gnome for me in Ubuntu 8.04, however it does work in 8.10, even if you have multiple images open. Clicking either image raises it and the toolbars, but not the other image. And you only get an entry for each image in the taskbar.
However I think my complaint still stands. I'm sure Gimp and Metacity do this with a whole raft of complex window properties, while my solution is absurdly trivial.
Of course they may have done it "right" with a single window property, which was "don't raise this window when the user clicks on it" but I am quite willing to bet they did not figure this out and have instead made the 100x more complicated solution.
PS: I'm sure somebody will argue with me about this. Please before arguing, get the following fact through your skull: A program can raise it's own window. Any argument that ignores this fact is invalid.
You have valid complaints but you are lacking with solutions. The basic problem is a bug copied from Windows, and your "solutions" are the same workarounds everybody has been forced to use on Windows, and forced to do for so long that nobody seems to even realize that there was another way at one time.
Here is how to fix it for real, but the Gnome and freedesktop and even Windows users refuse to hear me:
Step ONE: STOP RAISING THE WINDOWS WHEN THE USER CLICKS ON THEM!!!!!!
Step TWO: Gimp could then raise it's own windows, including the toolbars, when the painting is clicked on.
Wow, that was hard! But I have been trying to fight this for probably 15 years. It is hopeless, and this crap can be laid right on Microsoft for making their system do this, and a lot of clueless people who just cannot see the easy solution, and so they suggest MDI and "dockable toolbars" and all kinds of other crap in order to work around Microsoft's stupid bugs and Gnome/KDE/everybody's slavish copying of them.
You have it somewhat backwards. Lock-in causes backwards compatibility, not the other way around.
The weird thing is that Microsoft is as much trapped by it's own monopoly as anybody else. They cannot be incompatible, people will just continue using the stuff they already bought, or perhaps they would lose to some competitor using Wine or something and thus being more compatible. The very thing that traps everybody else into being unable to compete with Microsoft also traps themselves into being unable to compete with themselves.
No, you have to prove there *was* selective pressure.
Because there was no selective pressure.
Is that the best you can do? Boy that was pretty trivially easy.