We are selling closed-source software for Linux, just like you want to. So here are the ACTUAL answers:
1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Yes there is no difference. The set of things that can be closed source is not reduced in GPL3 (all changes are to things that would require you to distribute the source code anyway).
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
You do not want to statically link libc++ or any other standard library. DO NOT DO IT, some things in fact will not work if statically linked because of the dependencies on doing dlload of other parts. If you are really worried, you should distribute your program as an "app dir" that contains your copies of the shared libraries, and use the rpath linker switch so that the program looks in it's own directory for the libraries. The end user is free to remove your copies in order to expose and use the ones installed on their machine.
Personally I have seen zero trouble on modern machines with libc, etc. We have had trouble with libjpeg, freetype, and libtcl, and include those.
For non-standard libraries: well if it *really* is LGPL then you cannot statically link. Instead include it into the app dir as above. However I think you will find that *ALL* non-standard libraries you want to use are either not GPL/LGPL, or have an "exception" added to the license to allow static linking. This is because the authors of those libraries realize that nobody would use them without such an exception.
3. Can I obfuscate my code (e.g. encode it)?
You are not going to be required to distribute source code, so it does not matter. If in fact you had to distribute your source code, such obfuscation is not in compliance with the GPL, because that code is not "in the standard form for working on it".
4. Could I be forced to publish this code by some 3-d party?
NO. Even if you directly violated the GPL, you are only guilty of copyright violation. Copyright violation offenses can get you monetary fines and cease & desist letters. They CANNOT force you to do anything else, in particular they cannot force you to relase any information. An obvioius reason would be if your code is in fact a copyright violation of somebody else, if the GPL "forced" you to release your code, then you could violate anybody's copyright legally by just combining the copyrighted work with GPL.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
The only thing that is at all a problem is the LGPL libraries, and those exist on BSD, so there will be no difference there.
Unless you're so l33t that you invoke all your system calls with inline assembly?
Actually there was a time when read() and write() were usually turned by the compiler into assembler instructions to trap straight to the kernel. "libc" was considered where stdio (fread/fwrite and printf, etc) lived, not where read() and write() did.
It is interesting to see what Microsoft is really scared of. All those slashdot patent stories do not seem to have Microsoft astroturfers, but this one is thick with them. I do believe the patent stuff is probably just to confuse people and they don't really care where it goes, but the threat of having to make their software write a format that others can read is making them go at it big time.
Anyway, although the above astroturfers are not going to listen it is pretty simple.
All those OOXML importers you say "prove it is an open standard" are simply programmers applying their previous work in reverse-engineerning.doc format. Those importers work exactly as well/poorly as the.doc importers do: simple documents and carefully-made large ones work fine, but typical office users will find their text mangled by the import, and thus to them there is no competing product.
Any claim that it is an "open standard" is blatently false. There are commands in it like "work like Word 95", yet the standard does not include the source code to Word 95. Well, you say, just ignore that command, it's a minor detail, right? But that is exactly why those office documents come out mangled. It is in fact exactly the same as.doc format and it is pretty clear that inability to accurately transcribe.doc format is the main reason there is no competition to Word.
You can continue to spew your lies. You will probably win. But this is one of the sickest things I have seen coming out of Microsoft ever and you can bet that you are making enemies that you never had before. Slashdot is a big cesspool of crazy zealots, but when you see Microsoft doing such a blatent, desperate ploy to save their monopoly, and the absolute insane direct lying in their posts here, I start to agree with slashdot.
Okay, here is the top-secret, patent-pending, method to write fast software. This technique was used once upon a time but seems to have been forgotten in the rush to make everything object-oriented. Tests show that this speeds up opening documents and applications many many times:
Though it seems hard to believe, there is some chance that Apple does have a serious mistake. There is an explanation as to why it might be "better under Windows" and it is not good for Apple. A sure way to compare would be to take a screen shot from one system and display it on the other, so that differences in graphics and font rendering do not enter into it.
Apple has had a history of using a gamma correction table, which was always a mistake. I thought they eradicated this in OS/X but perhaps it lives on. Some ill-informed people actually think this makes the image better but it is always a bad idea on current hardware.
The reason is that the hardware interface to the monitor is 8 bits (per channel). If you have an 8-bit-per-channel image, and the gamma correction table is anything other than 1:1, then two or more different 8-bit shades are going to get mapped to the same 8 bit number sent to the monitor, due to the pigeonhole principle. It also means some possible 8-bit outputs are not going to get produced. It is possible the diterhing of the LCD is amplifying this effect. For instance if many of the "pure" values are the missing ones, then there is going to be far more dithering.
Both Windows and Linux just dump the 8 bit images you send to the graphics api to the screen buffer with no change. Though this sounds more primitive, it turns out it is the right thing to do. Color correction and profiling has to be done by software, not by hardware and drivers.
They are there for compatability with some Japanese and Chinese character sets, which contained most of the ascii characters in both "half" and "full width" forms. The full-width ones were twice as wide to match the square characters, which was useful for lining up columns.
This is all pointless now with proportionally-spaced fonts (and multiple fonts, you could easily select the "wide" font to print those characters instead). However Unicode had as a design requirement that translating from any common encoding to unicode and back again would be the identity transform. Thus if any character set existed with two ways of representing the same character, then there had to be two ways to represent it in Unicode. Therefore the full-width characters. This is also why Unicode has hundreds of random accented characters even though the combining characters would allow all of them to be represented easily with only a few dozen characters.
Unfortunatly Microsoft has completely fucked it up, and the "A" suffix functions are useless, too. What they do is use a "code page" to translate the bytes into that nasty utf16 and thus it will not pass utf8 through. Filenames on NTFS are actually stored in utf16, which means a nightmare of future compatability. There is a third interface (the "multibyte" one) that could save us, but Microsoft oh-so-conviently left out any way for a program to force the multibyte encoding to UTF8.
Microsoft is not the only one at fault. Sun and all the other Unix vendors were convinced that UTF16 (well UCS2 then) was the solution to I18N, and if they had not been wiped out by Microsoft it would have been established sooner, UTF8 would not have been seen, and we would be far worse than we are now.
The whole thing is very sad. The insistence that all the characters be the same size is really due to political correctness but you would be amazed at what illogical and insane things otherwise-intelligent people will say to defend it. (Hint for the clueless: text is make of words and many other things besides characters. Also Unicode has combining characters and invisible characters. And damn Microsoft still thinks a line break is two characters. This variable size is NOT a problem. Think before you say something silly!)
Don't be daft. There is no list at all. Making up the numbers serves just as good a purpose as actually trying to do a patent search. Making up numbers costs about 1 cent while the patent search would occupy a lot of people for a long time and cost millions, so it is pretty obvious what method Microsoft used to get their desired result as cheaply as possible.
If you switch to DSL only service on Verizon (which I did because it cut $40 off the phone bill) you don't get 911. This despite the fact that the line is still connected, and the terms of service say "you don't get 911 except in Vermont" which I assumme means it is quite techinically possible but only Vermont has forced them to. You can call 911 on a "disconnected" phone with no service however.
Really crappy that they can get away with this. Fortunatly there is a disconnected phone line going into the house so I might hook that up so 911 calls are possible.
I like how you ignored the fact that AT&T was not allowed to market computers or software due to government regulations. This is the real reason that all those computer innovations came from AT&T, the fact that they were allowed to freely distribute the results.
Besides, there are probably about 10 times more PhD's working on open-source software than are employed by all the research departments of every single software company in the world.
You can't look at patents or you are liable for triple damages. Linux code already works around well-publicized patents (Apple's truetype hinting, Microsoft's filter for LCD antialiasing) because those were so publicised that the authors of the software knew about them. If the author actively searched they would know about others and could be sued plenty if they did not add a work around.
In you FAT case (which is really FAT32, FAT is not patented) you can "pull support", and just display the "MICROS~1" type names, or some more intelligent interpretation of them. Check your camera next time and you will see that it only uses 8.3 filenames since they are also afraid of violating this patent.
Seeing as you don't know what any of the 235 patents are, you are posting FUD"
The fact that Microsoft refuses to identify any one of those 235 patents or what piece of Linux is infinging one of them is the FUD.
You can't say "due to the fact that Microsoft is not releasing any details in order to create FUD, anything YOU say is FUD". That's like a five year old saying "I am rubber, you are glue, anything you say bounces off me and sticks to you". Very very childish.
We put "submit a bug" in as a menu item and it talks to Bugzilla (by sending email). The user never sees the bugzilla web pages.
However I also think the bugzilla pages are pretty ugly and sparse. Can't they get rid of about 3/4 of those fields so you don't have to scroll to see the text of the bug?
No, I know you are not going to listen to reason, but I will try anyway.
You can make all the derivative works from GPL code you want. You cannot *distribute* them without also putting it under the GPL and including the source code. Without the GPL, normal copyright means you cannot distribute them AT ALL. Therefore the GPL is a license to do more than you normally could do. (there are also claims that normal copyright also prevents you from making your own derivative work even without distribution, but I personally find this doubful, but if true it is another license that the GPL grants you).
Many would probably argue that a company that uses (ie: "distributes") GPL-derived software internally in binary form, should also provide the source code to any employee that requests it
This has been stated as a false Microsoftian piece of FUD by the FSF itself. Employees are under contract to companies that can restrict their rights much more than normal. Redistributing the software is just as disallowed as selling the company loaner car.
Slashdot Mirror
You know you can keep using that LGPL version, right? Or are you just dense?
We are selling closed-source software for Linux, just like you want to. So here are the ACTUAL answers:
1. Can I do it with Linux today (GPL2) and tomorrow (GPL3)?
Yes there is no difference. The set of things that can be closed source is not reduced in GPL3 (all changes are to things that would require you to distribute the source code anyway).
2. Can I statically link the code with Linux libraries? (My own experience shows that dynamic linking is too much to bear.)
You do not want to statically link libc++ or any other standard library. DO NOT DO IT, some things in fact will not work if statically linked because of the dependencies on doing dlload of other parts. If you are really worried, you should distribute your program as an "app dir" that contains your copies of the shared libraries, and use the rpath linker switch so that the program looks in it's own directory for the libraries. The end user is free to remove your copies in order to expose and use the ones installed on their machine.
Personally I have seen zero trouble on modern machines with libc, etc. We have had trouble with libjpeg, freetype, and libtcl, and include those.
For non-standard libraries: well if it *really* is LGPL then you cannot statically link. Instead include it into the app dir as above. However I think you will find that *ALL* non-standard libraries you want to use are either not GPL/LGPL, or have an "exception" added to the license to allow static linking. This is because the authors of those libraries realize that nobody would use them without such an exception.
3. Can I obfuscate my code (e.g. encode it)?
You are not going to be required to distribute source code, so it does not matter. If in fact you had to distribute your source code, such obfuscation is not in compliance with the GPL, because that code is not "in the standard form for working on it".
4. Could I be forced to publish this code by some 3-d party?
NO. Even if you directly violated the GPL, you are only guilty of copyright violation. Copyright violation offenses can get you monetary fines and cease & desist letters. They CANNOT force you to do anything else, in particular they cannot force you to relase any information. An obvioius reason would be if your code is in fact a copyright violation of somebody else, if the GPL "forced" you to release your code, then you could violate anybody's copyright legally by just combining the copyrighted work with GPL.
5. Am I correct that programming in and selling BSD-based boxes won't raise any of the above problems?
The only thing that is at all a problem is the LGPL libraries, and those exist on BSD, so there will be no difference there.
You didn't think it worked because the output was off the top of your screen, silly. Just scroll back to find it.
Moviefone / 777Film /etc.
Unless you're so l33t that you invoke all your system calls with inline assembly?
Actually there was a time when read() and write() were usually turned by the compiler into assembler instructions to trap straight to the kernel. "libc" was considered where stdio (fread/fwrite and printf, etc) lived, not where read() and write() did.
It is interesting to see what Microsoft is really scared of. All those slashdot patent stories do not seem to have Microsoft astroturfers, but this one is thick with them. I do believe the patent stuff is probably just to confuse people and they don't really care where it goes, but the threat of having to make their software write a format that others can read is making them go at it big time.
.doc format. Those importers work exactly as well/poorly as the .doc importers do: simple documents and carefully-made large ones work fine, but typical office users will find their text mangled by the import, and thus to them there is no competing product.
.doc format and it is pretty clear that inability to accurately transcribe .doc format is the main reason there is no competition to Word.
Anyway, although the above astroturfers are not going to listen it is pretty simple.
All those OOXML importers you say "prove it is an open standard" are simply programmers applying their previous work in reverse-engineerning
Any claim that it is an "open standard" is blatently false. There are commands in it like "work like Word 95", yet the standard does not include the source code to Word 95. Well, you say, just ignore that command, it's a minor detail, right? But that is exactly why those office documents come out mangled. It is in fact exactly the same as
You can continue to spew your lies. You will probably win. But this is one of the sickest things I have seen coming out of Microsoft ever and you can bet that you are making enemies that you never had before. Slashdot is a big cesspool of crazy zealots, but when you see Microsoft doing such a blatent, desperate ploy to save their monopoly, and the absolute insane direct lying in their posts here, I start to agree with slashdot.
How to make slow software:
main() {
init_foo();
init_bar();
init_baz();
init_zoo_system();
call_lots_of_other_inits();
init_a_few_other_things();
init_foo_a_second_time_by_accident();
read_200_conf_files_and_init_some_more();
finally_do_something();
}
Okay, here is the top-secret, patent-pending, method to write fast software. This technique was used once upon a time but seems to have been forgotten in the rush to make everything object-oriented. Tests show that this speeds up opening documents and applications many many times:
main() {
do_something();
}
foo() {
static bool beenhere = false;
if (!beenhere) {
beenhere = true;
init_foo();
}
do_foo();
}
Using words like "street cred" to describe things like businesses *is* geeky!
Though it seems hard to believe, there is some chance that Apple does have a serious mistake. There is an explanation as to why it might be "better under Windows" and it is not good for Apple. A sure way to compare would be to take a screen shot from one system and display it on the other, so that differences in graphics and font rendering do not enter into it.
Apple has had a history of using a gamma correction table, which was always a mistake. I thought they eradicated this in OS/X but perhaps it lives on. Some ill-informed people actually think this makes the image better but it is always a bad idea on current hardware.
The reason is that the hardware interface to the monitor is 8 bits (per channel). If you have an 8-bit-per-channel image, and the gamma correction table is anything other than 1:1, then two or more different 8-bit shades are going to get mapped to the same 8 bit number sent to the monitor, due to the pigeonhole principle. It also means some possible 8-bit outputs are not going to get produced. It is possible the diterhing of the LCD is amplifying this effect. For instance if many of the "pure" values are the missing ones, then there is going to be far more dithering.
Both Windows and Linux just dump the 8 bit images you send to the graphics api to the screen buffer with no change. Though this sounds more primitive, it turns out it is the right thing to do. Color correction and profiling has to be done by software, not by hardware and drivers.
They are there for compatability with some Japanese and Chinese character sets, which contained most of the ascii characters in both "half" and "full width" forms. The full-width ones were twice as wide to match the square characters, which was useful for lining up columns.
This is all pointless now with proportionally-spaced fonts (and multiple fonts, you could easily select the "wide" font to print those characters instead). However Unicode had as a design requirement that translating from any common encoding to unicode and back again would be the identity transform. Thus if any character set existed with two ways of representing the same character, then there had to be two ways to represent it in Unicode. Therefore the full-width characters. This is also why Unicode has hundreds of random accented characters even though the combining characters would allow all of them to be represented easily with only a few dozen characters.
Unfortunatly Microsoft has completely fucked it up, and the "A" suffix functions are useless, too. What they do is use a "code page" to translate the bytes into that nasty utf16 and thus it will not pass utf8 through. Filenames on NTFS are actually stored in utf16, which means a nightmare of future compatability. There is a third interface (the "multibyte" one) that could save us, but Microsoft oh-so-conviently left out any way for a program to force the multibyte encoding to UTF8.
Microsoft is not the only one at fault. Sun and all the other Unix vendors were convinced that UTF16 (well UCS2 then) was the solution to I18N, and if they had not been wiped out by Microsoft it would have been established sooner, UTF8 would not have been seen, and we would be far worse than we are now.
The whole thing is very sad. The insistence that all the characters be the same size is really due to political correctness but you would be amazed at what illogical and insane things otherwise-intelligent people will say to defend it. (Hint for the clueless: text is make of words and many other things besides characters. Also Unicode has combining characters and invisible characters. And damn Microsoft still thinks a line break is two characters. This variable size is NOT a problem. Think before you say something silly!)
Don't be daft. There is no list at all. Making up the numbers serves just as good a purpose as actually trying to do a patent search. Making up numbers costs about 1 cent while the patent search would occupy a lot of people for a long time and cost millions, so it is pretty obvious what method Microsoft used to get their desired result as cheaply as possible.
If you switch to DSL only service on Verizon (which I did because it cut $40 off the phone bill) you don't get 911. This despite the fact that the line is still connected, and the terms of service say "you don't get 911 except in Vermont" which I assumme means it is quite techinically possible but only Vermont has forced them to. You can call 911 on a "disconnected" phone with no service however.
Really crappy that they can get away with this. Fortunatly there is a disconnected phone line going into the house so I might hook that up so 911 calls are possible.
I like how you ignored the fact that AT&T was not allowed to market computers or software due to government regulations. This is the real reason that all those computer innovations came from AT&T, the fact that they were allowed to freely distribute the results.
Besides, there are probably about 10 times more PhD's working on open-source software than are employed by all the research departments of every single software company in the world.
You can't look at patents or you are liable for triple damages. Linux code already works around well-publicized patents (Apple's truetype hinting, Microsoft's filter for LCD antialiasing) because those were so publicised that the authors of the software knew about them. If the author actively searched they would know about others and could be sued plenty if they did not add a work around.
In you FAT case (which is really FAT32, FAT is not patented) you can "pull support", and just display the "MICROS~1" type names, or some more intelligent interpretation of them. Check your camera next time and you will see that it only uses 8.3 filenames since they are also afraid of violating this patent.
Okay, smart ass. Find me ONE Slashdot article where Microsoft is accused of violating a patent that does not say what the patent is. I'm waiting.
Seeing as you don't know what any of the 235 patents are, you are posting FUD"
The fact that Microsoft refuses to identify any one of those 235 patents or what piece of Linux is infinging one of them is the FUD.
You can't say "due to the fact that Microsoft is not releasing any details in order to create FUD, anything YOU say is FUD". That's like a five year old saying "I am rubber, you are glue, anything you say bounces off me and sticks to you". Very very childish.
We put "submit a bug" in as a menu item and it talks to Bugzilla (by sending email). The user never sees the bugzilla web pages.
However I also think the bugzilla pages are pretty ugly and sparse. Can't they get rid of about 3/4 of those fields so you don't have to scroll to see the text of the bug?
Yes, autodesk is that stupid.
Thank you for that clarification! This does explain a lot.
No, I know you are not going to listen to reason, but I will try anyway.
You can make all the derivative works from GPL code you want. You cannot *distribute* them without also putting it under the GPL and including the source code. Without the GPL, normal copyright means you cannot distribute them AT ALL. Therefore the GPL is a license to do more than you normally could do. (there are also claims that normal copyright also prevents you from making your own derivative work even without distribution, but I personally find this doubful, but if true it is another license that the GPL grants you).
Many would probably argue that a company that uses (ie: "distributes") GPL-derived software internally in binary form, should also provide the source code to any employee that requests it
This has been stated as a false Microsoftian piece of FUD by the FSF itself. Employees are under contract to companies that can restrict their rights much more than normal. Redistributing the software is just as disallowed as selling the company loaner car.
Tell me again, which operating system uses two characters for the newline, which was necessary for Teletypes?
Hint: it starts with 'w'.
No more RTFM! No more 'did you submit a bug report???' No more this bug/problem is not our fault since we don't control such and such library we use.
If you don't think support for commercial software does this, you are seriously ignorant or out of touch with reality.
A copy of AutoCAD from 1995 still had an 8.3 filename limitation? Microsoft added long filename support at least 8 years earlier than that.
Can you explain this? Is autodesk that stupid?
When was the last time that you used the "UNIX programming environment" in your web browser?
Look at the top line. Notice the '/' characters in the URL?