Slashdot Mirror

Also, language matters in choosing a career path. If you want to work on virtualization or embedded systems, you should have a good knowledge of C/C++. But if you want to work on web/cloud apps, you should know Perl/PHP/Python and/or Java. And that doesn't mean just being able to compile successfully. You need to understand in depth such things as exception handling, libraries, file and memory management, data validation, web and database interfaces, etc., etc., etc. Sure you learn this on the job, but knowing about it coming out of school puts you ahead of the competition.

Several other people have mentioned working on a project on your own. I suggest that you look for a project that interests you at SourceForge. Even if your work doesn't end up being used, you should at least learn something.

Finally, there are two issues that I think get too little attention, both in school and at work: documentation and security. For these, you need to do some research. Everyone I know has complained about the doc or stupid error messages for apps they are trying to use. But most of those same people also complain about having to keep doc up to date whether they are programmers or admins. It's up to all of us to make it better.

Security is more complicated. Everyone talks about best practices, but if you ask 10 different people what that means, there will only be a little bit of overlap. Those of us who consider ourselves to be professionals (ie. expect a paycheck for doing the work) need to take responsibility for improving computer security. Leaving it up to the anti-virus vendors doesn't cut it. For programmers, here is a great start:

http://dwheeler.com/secure-programs/

So think about where you would like to go in your career, do some research on the skills needed for that, and take advantage of the opportunity to learn more than the minimum you need to get the job done (the OJT credo).

Later . . . Jim

Go to www.end6.org, download the little Javascript app, and apply it to your web site. Then, the first time the user goes to that site, they see a nag screen telling them to update their web browser. If they start seeing them on every site, they'll begin to get a clue.. while those whose companies will NOT allow change can at least get work done (it's not THEIR fault!). I installed in on my site, www.dwheeler.com, though in my case I complain about obsolete IE7 too.

Here's a great list of software innovations by David A. Wheeler:
http://www.dwheeler.com/innovation/innovation.html

In line with your comment, he focuses on the innovations rather than with what specific applications they became popular.

I wish TomTom had fought this; the FAT patents are utter nonsense. But patent fights are notoriously expensive, so I understand why TomTom did this instead. In the long term, I hope that software patents get eliminated, but that will have to wait for another day.

Could not agree more, however the only way to get arround this would be to use a file-system like ext2 or ext3 which is very easy to do from a Linux machine onto an SD, MS, XD, MMC or any USB storage device. The problem here is not using ext2 or ext3 it is the ability of the Microsoft OS to actually read the device since Microsoft won't support this file-system preferring to dictate what file-systems they support with their OS. Coupled with this is the fact that many devices (eg. cameras) that take cards or even USB storage devices also cannot read ext2/3 file-systems.

To get a file-system like say ext2/3 supported would require a courageous effort on the part of manufacturers to demand this type of support and I personally don't think that will happen any time soon.

What is bizarre is the fact that it is very easy to create a FAT32 file-system on just about any Linux platform yet you actually have to download software to a MS Windows (Win2000 on) machine to do this. This reinforces my impression that Microsoft expects everyone to do as they dictate and they don't even care about FAT32 except as a means of using it as a bargaining chip.

I wish TomTom had fought this; the FAT patents are utter nonsense. But patent fights are notoriously expensive, so I understand why TomTom did this instead. In the long term, I hope that software patents get eliminated, but that will have to wait for another day.

Your post demonstrates just how valuable Stallman has been to our community. If most people agreed with what he says then he wouldn't have to say it. Twenty years ago, people used ad hominem attacks similar to yours to castigate Stallman for the idea of Free software and the original GPL. Now, twenty years later, Stallman has been proven to be right. David Wheeler has made the case that a significant part of the success of Linux versus the BSDs was that the protections of the GPL attracted developers.

More recently he's been proven right about DRM; trusted/treacherous computing; and the need for the GPLv3. He was attacked for his stand on all of these issues and many of these attacks included name-calling similar to what you used above. Stallman was right and the name-callers were wrong.

My respect for Stallman has grown over the years (and decades) because it has taken longer time-scales for me to be able to observe how well Stallman has solved problems that most people refused to admit even existed. Attacks such as yours only increase my respect for him because he continues to speak his truth, the way he sees it, even if most people disagree with him, and even when some people attack him and call him names because they don't yet grasp the import of what he is saying.

First, if we accept your standard for good - and I do - then we can conclude that there are not that many good programmers. (It is a documented fact that the majority of programmers don't know how to do secure programming.)

That being said, you are totally missing the boat by mistakenly categorizing the system analysis and design task as programming. I can be a master of secure programming, but if the system design is flawed I will have perfectly implemented a flawed scheme.

Thanks for the plug for Secure Programming for Linux and Unix HOWTO. But I wrote it, not Bruce Schneier. Schneier has written other books, such as "Applied Cryptography" and "Schneier on Security".

So the general answer is no it will not be faster. This is because as a final step (the so called stage3) it compiles itself with itself. This assumes icc isn't malicious (yes I know - Trusting Trust and Countering Trusting Trust etc).

There is of course also the not-yet-quite-as-well-known article about a method to defeat that attack. You might want to read it (I have) since it's actually rather nice.

One location is at http://www.acsa-admin.org/2005/abstracts/47.html

Or more info, as well as the paper, on the author's blog at http://www.dwheeler.com/trusting-trust/

So, if you distrust your compiler(s) enough, there are ways for you to regain that trust, either by yourself or by enlisting some help.

I agree that a short list is important. I'd add "GPL version 2 or greater", "LGPL version 2 or greater", the BSD-new, and the MIT licenses to the short list of "reasonable licenses"; that list is still really short. I would recommend using the MIT license instead of the Apache 2.0 license; one problem with the Apache 2.0 license is that it's not compatible with the GPLv2 (though it is compatible with GPLv2 and GPL "version 2 or later"). In contrast, the BSD and MIT licenses are compatible with GPLv2.

It's particularly important to choose a license that's compatible with the GPL. The GPL is the most popular license, by far, so if every component is compatible with the GPL (of a specific version), then you can combine them all. I go into this in Make Your Open Source Software GPL-Compatible. Or Else.

You can see how that list of licenses (above) is compatible by examining my article, "The Free-Libre / Open Source Software (FLOSS) License Slide". Bruce is right, life becomes too complicated by trying to handle 70+ licenses. A short list, which are mutually compatible (or nearly so), is far more reasonable.

I agree that a short list is important. I'd add "GPL version 2 or greater", "LGPL version 2 or greater", the BSD-new, and the MIT licenses to the short list of "reasonable licenses"; that list is still really short. I would recommend using the MIT license instead of the Apache 2.0 license; one problem with the Apache 2.0 license is that it's not compatible with the GPLv2 (though it is compatible with GPLv2 and GPL "version 2 or later"). In contrast, the BSD and MIT licenses are compatible with GPLv2.

It's particularly important to choose a license that's compatible with the GPL. The GPL is the most popular license, by far, so if every component is compatible with the GPL (of a specific version), then you can combine them all. I go into this in Make Your Open Source Software GPL-Compatible. Or Else.

You can see how that list of licenses (above) is compatible by examining my article, "The Free-Libre / Open Source Software (FLOSS) License Slide". Bruce is right, life becomes too complicated by trying to handle 70+ licenses. A short list, which are mutually compatible (or nearly so), is far more reasonable.

You seem to be a bit trolling, but you're an interesting troll, so lets go ahead :-)

It's very clear that different parts of open source have different standards of review. Whilst the Debian SSL situation is bad to terrible (I had just installed my home web server on Debian for an experiment; I was not pleased!), however it was discovered only due to the source being open. It's known that actual deliberate attempts to put back doors into the Linux Kernel have been thwarted. By choosing properly supported stable well audited parts of Linux there can really be a benefit. Personally I would strongly recomment RedHat. I was impressed that ther distribution wasn't actually compromised during the recent attacks on their signing infrastructure. It showed a real commitment to defense in depth to a level which surprised me.

Even the compiler attack you mention has now been countered (see also Schneier's interesting discussion of double compilation). I'm surprised you don't mention it when discussing a 1980's paper (which is why I wonder about the trolling bit). This means that it really is possible to leverage the benefit of "open source" for better security.

I'd take a slightly different moral; you should have layered trust. More for Linux; less for Apache; little for Open Office very little for random Linux games; none for closed source software. Use SELinux to partition your software (if your OS doesn't support SELinux then change it :-). If you care about security then insist on source and actually pay for some parts of source level audits.

A key "talking point" in this discussion would be why the Chinese insisted on having Windows source whilst commercial customers don't get it. Discuss whether your company has any Chinese competitors. Seriously consider switching off a system which gives those competitors a benefit you don't have (sometimes Chinese competitors seem indistinguishable from the government). If they insist on source then so should you.

The U.S. Department of Defense's "Open Systems Joint Task Force" has some material.

Defining "open standards" is critical. Vendors with an open mouth will say they have an open standard. I'd go look at digistan.org for a more useful definition and justification.

European Interoperability Framework for pan-European eGovernment Services might help, too.

For statistics on why use open source software, see: Why FLOSS? Look at the Numbers!

This is a GOOD thing. DRM is a hideous disaster for end-users. When I buy music, I expect it to STAY bought, and to be able to use it on any device I have. DRM just guarantees that someone can take away my music with no judge and no jury.

But recording this information in the music file is a reasonable compromise. I can still play the music on any device I have. Yes, it's a bad idea to copy it to the world, but I never had the legal right to do that anyway. And yes, it'd be good if it were made clearer that this was happening... but this is NOT a big secret.

This isn't a perfect solution, of course. Even if someone has a copy of music originally bought by someone else, that does NOT mean the original buyer did anything illegal. Computers and networks get broken into all the time. Files can be modified to remove markings, or create bogus markings. Also, I believe people should continue to have the right to resell music, just like they can resell books (the "first sale" doctrine)... regardless of any nonsense spouted by the seller. But in the DRM system, a company operated as judge, jury, and executioner, and the company tended to act capriciously. At least with markings (or non-markings) in the file, a court can examine the evidence. It's not perfect, but it's better, and I can live with it better than the "everything's DRM'ed" world.

Now - where's my Ogg support in iTunes/iPods/iPhones? I'm not demanding that they only use Ogg, but they should be able to support Ogg formats (specifically Ogg Vorbis, Ogg FLAC, Ogg Speex, and Ogg Theora). Neither MP3 nor AAC (.m4a) files are open standards. Wikipedia, for example, provides audio files in Ogg and not in MP3 or AAC.

Please tell Apple to add support for Ogg; here's more info about why Apple should support Ogg.

What a ridiculous sum pulled completely out of thin air.

It's not out of the question. Given current software development cost models, the Linux kernel will cost about a billion US$ to redevelop soon http://www.dwheeler.com/essays/linux-kernel-cost.html

Given the fraction of the code base of a complete system that the kernel is, I'd say US$10.8B if anything is on the low side, if one were to do it again from scratch and pay for the development.

You can't sell the Linux ecosystem, and if you believe you can buy it

It's been tried before ... http://www.dwheeler.com/essays/linux-kernel-cost.html

Take a look at http://www.dwheeler.com - in particular, Open Source Software and Software Assurance (Security) and Why OSS/FS? Look at the Numbers!.

As you already know, this claim that "anyone can edit the open source software" is nonsense. They're conflating editing a file with getting that file into the supply chain. Anyone can edit a proprietary program, too; just open up a hex editor and start modifying. The issue is, can a malicious attacker modify the program AND get their changes into the binary you end up with? This isn't easy at all in the major OSS projects (the kind your company is likely to consider). Any OSS project has some kind a "trusted repository", the "official" version that people pull from. For a change to get into your system, the trusted repository has to be subverted AND not detected later. We already know of an attempt to subvert Linux that failed, so it's not as easy as they think it is. If they are REALLY concerned that they "don't know what the binary is", then get the source and recompile it.

Don't expert proprietariness to save you. Indeed, because the source code isn't being widely examined, any malicious code that gets in will be more difficult to find later.

The U.S. Department of Defense's policy is consider OSS equally with proprietary software, as does the entire U.S. government. In fact, the U.S. Department of Defense heavily depends on open source software, and they almost certainly have more stringent security requirements than your company.

If a company can't handle technological shifts in information technology, they risk their own long-term survival. OSS is now mainstream and widely used.

Take a look at http://www.dwheeler.com - in particular, Open Source Software and Software Assurance (Security) and Why OSS/FS? Look at the Numbers!.

As you already know, this claim that "anyone can edit the open source software" is nonsense. They're conflating editing a file with getting that file into the supply chain. Anyone can edit a proprietary program, too; just open up a hex editor and start modifying. The issue is, can a malicious attacker modify the program AND get their changes into the binary you end up with? This isn't easy at all in the major OSS projects (the kind your company is likely to consider). Any OSS project has some kind a "trusted repository", the "official" version that people pull from. For a change to get into your system, the trusted repository has to be subverted AND not detected later. We already know of an attempt to subvert Linux that failed, so it's not as easy as they think it is. If they are REALLY concerned that they "don't know what the binary is", then get the source and recompile it.

Don't expert proprietariness to save you. Indeed, because the source code isn't being widely examined, any malicious code that gets in will be more difficult to find later.

The U.S. Department of Defense's policy is consider OSS equally with proprietary software, as does the entire U.S. government. In fact, the U.S. Department of Defense heavily depends on open source software, and they almost certainly have more stringent security requirements than your company.

If a company can't handle technological shifts in information technology, they risk their own long-term survival. OSS is now mainstream and widely used.

Take a look at http://www.dwheeler.com - in particular, Open Source Software and Software Assurance (Security) and Why OSS/FS? Look at the Numbers!.

As you already know, this claim that "anyone can edit the open source software" is nonsense. They're conflating editing a file with getting that file into the supply chain. Anyone can edit a proprietary program, too; just open up a hex editor and start modifying. The issue is, can a malicious attacker modify the program AND get their changes into the binary you end up with? This isn't easy at all in the major OSS projects (the kind your company is likely to consider). Any OSS project has some kind a "trusted repository", the "official" version that people pull from. For a change to get into your system, the trusted repository has to be subverted AND not detected later. We already know of an attempt to subvert Linux that failed, so it's not as easy as they think it is. If they are REALLY concerned that they "don't know what the binary is", then get the source and recompile it.

Don't expert proprietariness to save you. Indeed, because the source code isn't being widely examined, any malicious code that gets in will be more difficult to find later.

The U.S. Department of Defense's policy is consider OSS equally with proprietary software, as does the entire U.S. government. In fact, the U.S. Department of Defense heavily depends on open source software, and they almost certainly have more stringent security requirements than your company.

If a company can't handle technological shifts in information technology, they risk their own long-term survival. OSS is now mainstream and widely used.

"It would be at best VERY difficult to know that some similar technique was not used on any given distribution."

here is an interesting counter:
http://www.dwheeler.com/trusting-trust/

This won't solve all the problems of the universe, but this is a GOOD THING. Securing DNS is absolutely critical to making the Internet a safer place. If I type in "irs.gov", I want to go to "irs.gov", not some spam site, and this helps me get there.

Irs.gov being irs.gov can be verified with HTTPS and SSL/TLS.

DNSSEC can provide IP addresses with a strong guarantee that the IP addresses are actually correct.

Yes, but having the correct IP address doesn't still prevent man-in-the-middle attacks or re-routing your traffic. HTTPS and SSL/TLS, on the other hand, would guarantee that you're talking to the correct endpoint.

DNSSEC can even provide other keys, and make it possible to EASILY send secure emails without having to do a key exchange ahead-of-time. See, for example:
http://www.dwheeler.com/essays/easy-email-sec.html

Easily? Did you read the text behind the link yourself? Non-DNS key from DNS to access LDAP to and fetch user keys via some 'not-yet-available' mapping?

What's wrong with using plain LDAP to fetch a certificate, verify certifice and encrypt away? You know, the standard way.

DNSSEC has it uses, but heck, well documented problems as well. It can certainly work for .gov, where single entity is verifying and certifying domain keys.

This won't solve all the problems of the universe, but this is a GOOD THING. Securing DNS is absolutely critical to making the Internet a safer place. If I type in "irs.gov", I want to go to "irs.gov", not some spam site, and this helps me get there. DNSSEC can provide IP addresses with a strong guarantee that the IP addresses are actually correct. DNSSEC can even provide other keys, and make it possible to EASILY send secure emails without having to do a key exchange ahead-of-time. See, for example: http://www.dwheeler.com/essays/easy-email-sec.html

The nice thing about Open Source is that it doesn't require billion-dollar budgets.

Wheeler might disagree with that, albeit the 'budgets' are largely time-based via volunteer effort or corporate-based via organizations who realize sharing software is cheaper than allowing it to be hoarded.

This is not a country that does great things any longer.

You might be right about that, but I find fault in the logic that we shouldn't fund NASA because they didn't do much during the last 40 years. You complain about stupid wars, but what they experienced in 1969 was the culmination of an effort to win the mother of "stupid wars". Whether the Russians or Communists were significant or not is up for debate, but the Cold, Korean, and Vietnam Wars were all unnecessary pissing contests and as a result of that American piss made it to the Moon.

If you are going to blame anything for the lack of "accomplishments" of NASA for the last 40 year, blame the lack of a structured plan when they hit the ground running in the 1960s. Since then --- technology has advanced, discoveries have been made, and science has caught up to the engineering accomplishment of putting a man on the moon. By suggesting that NASA be defunded, you are suggesting that everything during the last 40 years has been a waste.

By rights, we really should have a permanent base on the moon by now, and should have already put somebody on Mars.

If you consider that 2 of the 17 Apollo flight missions were failures and that 2 of 4 Space Shuttles have blown up (with 120+ successful mission), you'd realize that working in space is *really* hard and risky. Do you recall the challenges of Skylab in the early 70s when NASA had a pair of booster rockets that it needed something to do with? This was a far cry from what ISS is today. So, I would argue that the past 40 years have been instrumental towards getting us to where are today... which is in the position to *consider* a trip to Mars 20 years from now. However, without the groundwork that this and other missions have laid, it will never happen. Because the most important thing for a human Mars mission is that he (or she) doesn't die there. I have no doubt that any attempts in the 80s or 90s to customize a Saturn V with a crew vehicle destined for Mars would have resulted in such a death. In 20 years, though, I think technology exists that will enable such an astronaut to survive.

And the "present American's condition" cares very little about what was going on in the 1960s or what will be going on in the 2030s.

When can you consider a compiler "clean"?

Countering "Trusting Trust"

If you have any concerns with that, they should be answered in: David A. Wheeler's Page on Countering Trusting Trust through Diverse Double-Compiling (Trojan Horse attacks on Compilers)

If you find any holes in the theory that were not discussed, then consider writing up your findings for publication.

...reading for anyone who references Trusting Trust alone! Here are links to the original Ken Thompson's "Reflections on Trusting Trust" (HTML/non-PDF version) and David A. Wheeler's "Countering Trusting Trust" which offers potential solutions to the issues raised in the original.

Basically so long as I have another set of compilers AND at least one is trustworthy then there is process I can follow to build a compiler I can trust (but where it would help to have the compiler sources). There are other reasons why such an issue might find it hard to propagate in a changing software stack but that's a side note.

This seems to be a very popular Slashdot meme - people keep mentioning Trusting Trust without also answering the points offered in more recent literature.

Anyone who mentions Ken Thompson's Reflections on Trusting Trustshould also mention David A. Wheeler's "Countering Trusting Trust". Those who don't should be punished by having to argue both sides of the debate.

I occasionally post the counter argument in a reply but no one sees it... Next time you see someone else with this behaviour tr, here's ammo for countering it.

(I believe the gcc rebuilds aren't so much to remove this type of intentional bugging but rather ensure the final binary is free from things like first compilation optimisation issues... Comparing the compiler binaries would probably indicate differences due to things like dates being present BUT hopefully what they would output on a given source would be the same)

Dave Wheeler's Sloccount gives the following results on 2.6.25-tuxonice-r5 (Gentoo):

xfs 70248 (wc -l gets 84248)
jfs 17700 (32995)
reiserfs 20002 (27705)
ext3 11160 (16046)

Interesting that JFS has so many non-code lines in it, relative to the others. It's actually the second smallest, right after Ext3. XFS is the largest codebase of them all, actually.

This page includes a list of FLOSS automated theorem provers. Fedora 10 adds several of these tools, so you'll be able to easily install and try out some of them.

How can you reference Ken Thompson's "Reflections on Trusting Trust" (HTML/non-PDF version) without also mentioning David A. Wheeler's "Countering Trusting Trust" (as found via Bruce Schneier's blog)? So to answer your question:

What if you can't even trust your compiler?

Well so long as I have another set of compilers AND at least one is trustworthy then there is process I can follow to build a compiler I can trust. After spotting differences in the resulting binary I would also need to (ah-ha) examine the source code of the used compilers and find out which one is mis-generating the binary and fix it.

At some point I need to be able to understand binary and read the source of the compiler that generated that binary to ensure that someone else is not jacking me.

You can't even be sure when you have the source code.

The point there is that you have to have the code for the whole stack not just an isolated application. For an application to be secure, you have to be able to do a valid code audit. For the code audit to be worth anything it has to be done all the way down to the core: compiler, libraries, utilities and operating system. So you can be sure when you have the source code, but you do have to have all of the source code.

So without even touching on the quality issues with MS, lack of code access rules out all MS products from the system on up to user applications. "Shared" source might be fine for specific, limited, platform-specific development contexts, but is basically the same as "escrow" And "escrow" is just another name for closed source, namely, as Ken Thompson point out, insecure. Ditching MS products won't automagically make your site secure, but it is a necessary first step.

Now there are some short cuts one can take in Ken Thompson's example. However, they all boil down to having the code for the whole system as he points out, not just parts. Even diverse double compiling requires, at the end of the day, a system that has been vetted top to bottom to use as the baseline.

Now the next step is to deal with smaller, more modular units of code. They're not only good design but also easier to manage. Again, that rules out a certain party ...

FWIW it's interesting that the ACM recently pulled the Thompson article. It had been available for over a decade. One wonders how much longer the ACM will be a useful source of technical information.

Yes, I can.

Ada has a lot going for it when it "has to be correct every time"; that is its main purpose. The big advantage is that the language maximally checks everything at compile time - so if it HAS to work correctly every time, that's a big plus. It also has more run-time checks. It even has some extra features that let it be more specific. It has a nearly-unique ability to specify number ranges; if you spec a variable as being in the range 1..100, then any attempt to assign outside that range is immediately detected. That turns out to detect lots of errors before they get out of hand. It's not the best language for EVERY purpose, but it has its place. I have a tutorial here, if you're curious: Lovelace tutorial.

It's a bite that MS can always come late to the table with something broken and then get equal billing in the press. MOOX came as an attempt to compete with ODF, after some 600 companies reviewed ODF as an open standard. How is it then, that no matter how positive the articles is to open standards, the situation always gets spun as MS vs MS competitors? Really, how else can it be? One the one side you have the cult of MS. On the other side, all the major companies, governments and universities, except for the cult of MS. So by definition these are going to be 'MS competitors'. How about some reality injections here.

It's a bite that MS can always come late to the table with something broken and then get equal billing in the press. MOOX came as an attempt to compete with ODF, after some 600 companies reviewed ODF as an open standard. How is it then, that no matter how positive the articles is to open standards, the situation always gets spun as MS vs MS competitors? Really, how else can it be? One the one side you have the cult of MS. On the other side, all the major companies, governments and universities, except for the cult of MS. So by definition these are going to be 'MS competitors'. How about some reality injections here.

Here is the source: http://www.dwheeler.com/oss_fs_why.html#history. If that source is invalid, or if you have sources that claim something else, please do us the favour of correcting the wikipedia article, so people like me won't be misled.

If, however, you have absolutely no clue, then I suggest a big dose of STFU and lay off the FUD.

Here is a bunch of links about Computer Ethics from when I was researching about it. The google video link (last one on this list) is particularly interesting. Computer ethics is actually a university research topic! http://www.brook.edu/its/cei/cei_hp.htm http://ethics.csc.ncsu.edu/ http://www.southernct.edu/organizations/rccs/resources/teaching/teaching_mono/moor/moor_definition.html http://plato.stanford.edu/entries/ethics-computer/ http://www.cs.sunysb.edu/ProfessionalEthics.html http://www.cs.berkeley.edu/~bh/hackers.html http://cat.inist.fr/?aModele=afficheN&cpsidt=4279094 http://cyberethics.cbi.msstate.edu/ http://www.oekonux.org/texts/copykillsmusic.html http://www.progilibre.com/Open-Source-Alternative-ou-fausse-route-_a350.html http://www.osalt.com/ http://en.wikipedia.org/wiki/FOSS http://en.wikipedia.org/wiki/Richard_Stallman http://en.wikipedia.org/wiki/Copyleft http://en.wikipedia.org/wiki/GNU_General_Public_License http://creativecommons.org/ http://www.dwheeler.com/oss_fs_why.html http://www.itc.virginia.edu/policy/ethics.html http://www.brook.edu/its/cei/overview/Ten_Commanments_of_Computer_Ethics.htm http://www.acm.org/serving/se/code.htm http://www.ieee.org/portal/site http://video.google.fr/videoplay?docid=-3088012854941915784&q=computer+ethics

Except it's Microsoft who calls themselves an innovator. The Ayn Rand Institute even said during the MS trial that MS should be allowed to innovate. And MS had it's own Freedom to Innovate campaign.

I don't know why this is, I think its just human nature.

one reason for this is that when you pick up someone elses project, you're picking it up from point X where that person coded it from the beginning. Where at their starting point, the goal may have been one thing and was shifted several times over the development timeline and the programmer learned new tricks to keep up with the changing demands and also evolved. This, in addition to different people having different thought processes when coding can lead to challenges when picking up other people's code.

For me, I have the same issue when I look at my code from today versus 6 months ago versus 6 years ago. When I look at my own code from just a couple years ago, I say "this is impossible... I need to rewrite this." It's the same way when I look at code that I did when I was sick or when I wasn't in the zone. Because of this, I've found that putting comments in my code is important. rather than commenting "Recursively loop over directory and process", to actually putting in a paragraph explaining what's happening and why. My code now is probably about half comments for larger projects. Projects that are under 200 lines typically only have a few dozen comments. It's also interesting when you look at your code and you see it's 3500 lines, but you run it through sloccount and realize it's only 1800 lines or less when comments and whitespace are stripped.

Programming is an evolution. It's constantly changing. Your best bet is to familiarize yourself with the code and break it down into a use-case. Program around the way you want the code to be used in the end and it becomes easier to maintain and follow because you've got levels of abstraction and it becomes easier for someone else to pick up later.

Neither of them is compatible with any version of the GNU GPL. See this link for details why this pretty much means that the only user of these licenses will be Microsoft.

You may sell a copy or two, but it will be available for free in short order, and your business is done.

If you're trying to sell a COTS product to a whole bunch of people, yes, it will probably make its way out into the world right quick if it's free software. Indeed, even if it's not free software - what percentage of Photoshop users have paid for it?

This mass market COTS it is already starting to be displaced by commercially developed open source. If that's your business model, I suggest you get out quick.

On the other hand, if you're selling a system to a few companies in a specific field, it's unlikely thery are going to share. If you make a telephony application and sell it to Sprint, they are not going to give a copy to Verizon. Of course, you're more likely to enter into a development contract with Sprint first, rather than make the product first then go trying to sell it.

"Intellectual property" is a misleading portmanteau of completely separate branches of law: trademarks, copyrights and patents. But the OIN despite the badly worded mission statement concentrates on patents. Specifically its a defensive patent pool (with contributions from Red Hat, Sun, Novell, IBM and others) which can be licensed by any company agreeing not to use its own patents in aggressive lawsuits against pool members.

Currently the three largest licensess are Google, Barracuda and Sun.

David Wheeler has a good overview here

Given the current lamentable state of the patent system the OIN is probably the only way in which some sanity can be established. It must be awkward to be Novell right now having endorsed the OIN on one hand, and also endorsed the existence of Microsoft's Snuffleupagus Patents.

Most open source developers work a full-time job elsewhere, and have a very limited amount of time to contribute to their open source projects of choice.

Where did you get that datum? I think if you read any decent analysis, you'll find that the vast majority of code in active FOSS projects is written by programmers paid to do so. This means that project leaders, i.e. the ones who invest the most in the project have every incentive to think long and carefully about the future of their project, because it affects their professional future, too.

The one solution I see is to just avoid the GPL family of licenses.

You only see that one solution because you haven't done your analysis properly.

There are very good reasons why more FOSS developers choose the GPL than all the other licenses combined. Perhaps you should investigate those reasons before discarding it as a nuisance.

Sorry, I honestly thought this was common knowledge, but some informal checking with colleagues demonstrated that it isn't quite so widespread as I thought. Here's a fairly well-researched source:

http://www.dwheeler.com/essays/gpl-compatible.html

Rhetoric notwithstanding, this guy does check his facts.

Take a look at http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html, section 3.2. Are any of the GNU system components that the author mentions there absent from any major Linux distribution?

Please provide a quantitative definition of "largely" and evidence that this is true for any significant number of the common Linux distributions.

Take a look at http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html, section 3.2. Are any of the GNU system components that the author mentions there absent from any major Linux distribution?

Certainly it is NOT okay to remove the copyright notices from BSD material, as long as there's something left in the file that's covered by the BSD license. So, don't do that. But you CAN take a BSD work, combine it with other works, and have the final result as essentially GPL'ed or proprietary. My FLOSS license slide even helps you figure out when you can do that, and when you can't.

But that only covers the legal issues. If there's an existing project that releases something under an OSS license, it's usually better to continue to use their license than to fork off another project under a new license, especially if you're not making many changes. For a lot of reasons.

LWN's article "Relicensing: what's legal and what's right" is worth a look.

gcc 2.96 was just under a million lines of code -- I've no idea how big gcc 4.2.1 is. In any event, if Microsoft (or whomever) were to claim that gcc 4.2.1 had a back door (here's a famous hypothetical (?) example) but not give any details, then it would be difficult (i.e. very time consuming) for somebody (knowledgeable) to go over all million+ lines of code to certify that it does not exist.

Having source helps take the bite out of FUD, yes, but it doesn't remove it completely. Merely having the code is not enough -- you need to have the skills to understand the code, and the time to properly analyze it. Either that, or you need to trust somebody else to do this for you.

So, yes, I have the source code for gcc. I believe that it has been eyeballed by dozens (hundreds?) of people way smarter than I am, looking for problems. Most of these people probably report their problems to the maintainers, who I assume fix them when they're serious enough. A few are bad guys, looking for holes to exploit. (Well, gcc probably isn't nearly as exploitable as some daemon like Apache, but there are ways it can be abused.) In any event, merely having the source isn't enough to prove to you that it's good (efficient, secure, reliable, not patent encumbered, not copyright infringing, etc.) code. You have to actually look, and know what you're looking at -- and very few users actually do this.

http://www.dwheeler.com/essays/gpl-compatible.html

If you want to use software, you must have software to use. If you want to have software to use, there must be a way to develop it. The GPL has been the "Constitution" enabling the development of a vast amount of really useful software; indeed, the majority of Free-libre / open source software (FLOSS) uses the GPL. And people are finally realizing that most FLOSS is commercial software; it's no longer exclusively "just a hobby". Before the GPL, the only ways of creating software were complete proprietary control (often by a company intent on preventing you from switching) or public domain/BSDish licenses (which sometimes works very well, but sometimes get sucked into proprietary projects often enough to die or live only on life support). So yes, if you wish to be able to use software in the future, the GPL is important; it establishes a viable method of making the software that people would like to use. In fact, it's been extraordinarily effective at doing so.

Even you don't write code yourself, you can still hire someone to write or change code. So the GPL provides additional capabilities to users, even if the user can't write code him/herself. And even if you use proprietary software, GPL'ed software has had a profound impact on limiting the costs of much of that software, which is also great for end-users (and again matters to them).

Here's an analogy - that statement is like saying that agriculture doesn't matter because many people aren't farmers. But non-farmers must eat too! Having viable methods to grow food - and a competitive system to lower costs and raise quality - are still of vital interest to the users of products from farmers. Unless you want to stop eating.