The old school of thought in that the actual source code that a program is written using is not released to the public. Instead, just the binary, or the program executable itself, is released to the general public. This also applies to hardware devices such as modems and video cards. They have some programming inside of them of which is usually a closed source system. Linux is designed under the opposite system of open source.

I will make one argument towards the necessity of closed source software.

I own a company and we have developed a large, very complicated scientific analysis software (approximately 100,000 lines). This software, in the most general sense, predicts the radar cross section of objects such as tanks and aircraft. This software blends many electromagnetic and computer graphics techniques together. This software has been painstakingly engineered over many years, and the code executed tens of thousands of times to verify that the algorithms have been implemented properly and that its results are to be trusted. Our customers depend on us for this software to operate correctly, and that the outputs are consistent and reproducable. A customer may invest millions of dollars in developing prototype hardware based on the outputs of this software.

Now, say we give the source code of this software to the end user, who may or may not have a background in electromagnetics or computer graphics. This person now decides to alter the code in a subtle way. However small this change may me, something VERY SIGNIFICANT has occurred. A person, who is not the developer, has altered the program. The outputs can no longer be trusted. Think about that for a minute.

I have a great amount of respect for Richard M. Stallman and the Free Software Foundation. We have used the GNU development tools such as gcc and gdb extensively in the development of this product. But we cannot give the source code of our software to the end-user. If they were to used a modified executable that produced erroneous results, this might lead to a failed project, and then the customer might have reason to sue us (even though this is prohibited by the end-user agreement). This could call the reputation of the software and of our company into question. This is why we cannot allow them to modify how the executable operates in any way. The software must remain in a known and controlled state at all times. It must remain closed source. Sorry, Richard.

RMS says that I should not have the freedom to retain the source code to myself. Well, I believe there are circumstances that open source software is good, and times that it isn't. Many software projects benefit greatly from the inputs of many people (linux). Conversely, some would be harmed greatly by it (the software we develop). A happy medium must be found, and I do not believe that it lies in RMS' totally open-source camp or with the malignant likes of our favorite friends at Microsoft.

Some followups to lj's very good arguments. I would first state that I operate from the standpoint of engineering analysis software. Implementing algorithms that perform complicated numerical operations is not trivial, and should be done only by persons qualified to do it. For example, I am not qualified to work on the XFree86 window system. I am unqualified. I would not trust any modifications I made to it. I place my trust in the person(s) that have worked long and hard on it to make those changes.

I wholeheartedly agree that allowing end-users to have the source code is, at least on paper, a good idea. Providing a license that allows the user to examine the source code and recompile it to prove to their own satisfaction that it works correctly is a good idea. I would push for this type of developer-user interaction in a perfect world. Unfortunately, not every end-user groks the subject matter, or the programming language the tool is coded in, as well as the developers do. Looking back on my statements about XFree86, I do not have the slightest idea how it works, and I have no place trying to modify it. I would go as far to say, in industry, perhaps 5% of the users possess the required skills to significantly change and successfully recompile a commercial software application without breaking it. Open-source advocates are in the minority when it comes to the population; your average john doe simply is not a software god that can leap right in and be on the same page as the developer.

Consider the 2.4.15 kernel. This was blessed and released the the community at large last year. Shortly thereafter it was discovered that if you used this kernel, and allowed the system to shut down normally, it would corrupt your hard disk. Now, consider a commercial application, if the end-user changed the application slightly and recompiled it, and it ate his hard disk. The company whose hard disk has been eaten is going to be really pissed off. Who is going to be held responsible? The developer of course! (End-user license agreements are simply part of a legal defense, the end-user may still sue).

So we come back to the issue of trust. Most end-users simply do not have the necessary skills to examine source code and determine, in their own minds, that it is written correctly. Modification by unqualified persons of any part of the source code throws the legitimacy of any recompilation into doubt. This doubt cannot be allowed to flourish in a field where the integrity of the software is the cornerstone of the analysis. In a perfect world, where everyone is a code expert, this wouldn't be an issue, but that's not how it works in the real world.

A program is closed source if the source code the program was built from is not made available. This is not necessarily the opposite of 'open source', as the term 'open source' is nowadays synonymous with 'Free Software', and usually implies the additional right to freely redistribute the program. A program can be 'closed source', while being freely redistributable - such a program is often called Freeware, or public domain. A program can also provide access to the source without necessarily being freely redistributable, usable, or modifiable (the original meaning of the term 'open source').

It is often argued that closed source software is somehow 'more correct', as the user is prevented from modifying it. This argument is bunk, however, as releasing software as closed source prevents the user from performing their own validation, but does not prevent the user from modifying the program.

A program can prevent redistribution or modification without hiding the source code, however. POVRay and Pine are both distributed under licenses that allow the program to be either distributed or modified, but not both. In effect, they are freeware programs, with the source available for inspection. The most famous 'open source, but not Free' program is PGP1. PGP's source code was made available to the general public, under a license that allowed it to be compiled, but not used. To use PGP, one had to purchase a commercial version of it, or download a Freeware version. This allowed the users access to the source, without giving the the right to use the program, or make their own programs based on it.

Access to the source means that anyone, not just the (relatively) small group of developers, can perform whatever testing is required to prove to their satisfaction that the application is correct. If necessary, they can spend more time and money testing it than the developers have. And when it's all done, they can compile the application the same way the developers did, and confirm that the program they've been shipped is the same as the one they validated.

The reason why PGP was so successful was that it could be proved to the satisfaction of notoriously paranoid cryptography experts that the program was correct and that there was no malicious code hiding in it. At the time, no other cryptographic program offered this2, and thus for many, no other program could be trusted with their secrets.

Not providing source code does not prevent the user from modifying a program, it merely makes it harder. Even encryption and obfuscation of the object code will not stop a determined programmer. Executable wrappers like safedisk, which employ state-of-the-art anti reverse-engineering methods are cracked within days of each new release. They are thwarted by the simple fact that if you want your program to run, it must at some point unencrypt itself. The emulator Callus was maintained for over a year without access to the source code - the developers dissapeared off the face of the earth, but this did not stop third parties adding new features to the raw object code. If you're really bothered by people modifying your program, license it under terms that forbid modification, then sue anybody who does.

As well as the problem of having to take the word of external developers that the code you are using is correct, closed source software has additional complications - there are very few owners of the original source, making it not impossible that all copies of the original source may be destroyed or lost. Even if the source is still available, the owners may refuse to perform maintainance of the software, particularly if it is reaching the end of its lifecycle. To avoid these problems, many closed source solutions are now provided with the source code held in escrow by a trusted third party, to be delivered to the client should the developers go bust, and to help ensure that the developers do not lose all copies of their own source code.

1 - PGP is no longer released under such a license, after being bought by Network Associates.

2 - Now there are lots of Free crypto programs - GPG, a Free reimplimentation of PGP, is the most well known.

'Open source' does not mean 'freely modifiable', and 'closed source' does not mean 'not modifiable'. To assume anything else is to risk humiliation when your 'unmodifiable' copy protection is cracked, or your trade secrets are reverse-engineered. Relying on closed-source alone to protect against liability should your customers modify the software is a grave mistake, as closing the source is not actually sufficient to prevent them doing so. It makes no difference to the legal position of either the vendor or the customer whether the customer modified the software by altering the source and recompiling, or by disassembling the closed-source binary. Modification and reverse-engineering are legal matters, and should be prevented by the license agreement, rather than being hindered by obfuscation. Intellectual property should be protected by copyright and patent law, rather than the hope that no-one will bother to reverse-engineer your object code.

If closed source has any role in enterprise software, it may be in addition to an NDA in keeping trade secrets secret, or as an additional safeguard preventing patented or copyrighted algorithms less likely to be copied, but it certainly cannot do these things in and of itself. Closed-source may remain a useful tool in forcing consumers to stick to license agreements, but even this is becoming a lost cause. Research into copy protection is becoming more and more costly, and copy protection is becoming less and less effective.

Log in or register to write something here or to contact authors.