I have heard this kind of issue raised many times before, and I believe the first and fundamental problem with licensing software engineers/programmers is:
What exactly should be licensed?
In my opinion there is a vast difference between a programmer and a software engineer.
The average programmer you find in every nook and cranny are the people who, given a problem, program directly from point A to point B. Program from the problem to a possible solution, without EVER thinking of how to re-use code, how to optimize the design and how to improve his/her coding, effectiveness, and performance. This is a person who does not believe in using version control because it is just another thing that can keep them from churning out another program in a day and a half, instead of two. Someone who is too short sighted to see the benefits of peer review and module testing (especially on re-usable code). Someone who says "I do not have to do that, it WORKS this way!". With this type of programming comes an arrogance, a belief that they are superior because they can create a new piece of code in a quarter of the time another person does it. I have seen many of them ... and I have seen their code. Hap-hazard combinations of non-conforming styles (depending on what they feel ike that day). From zero comments to cute little annecdotes like "If you can't understand this you should not be programming", and "dude, this is way cool code!". These people are programmers ... and nothing more. They do not see the benefit of improvement and rarely, if ever, improve at all. Granted, they will learn to do many different things, and figure out how to do way cool things from "Programming for Dummies" ... but ... they have rarely read a book about software engineering ... a book that does not have one line of code in it ... because it is not about programming, it is about the process of engineering software by means of repeatable, predictable, and proven processes.
Using software engineering principles you can write VB, C++, Java, Fortran and assembly code ... you can connect them together in constructive ways ... you can make people look in awe at an unbelievable things happening on the screen, or in confusion at a black box doing all kinds of things with stuff connected to it ... but you can also do that with programming (and probably the first time round in a shorter amount of time). The difference is ... When you support the application, modifications will be done in less time. When you have to create a new application which conforms, in part or totality, to the one you wrote before the time to delivery is much less. I have seen products being delivered 11 months early on 18 month projects re-using code from various other preceding projects. I have seen projects delivered with no bug reports in 6 months ... and I have seen companies prosper due to that.
BUT, most of my experience in that regard comes from a military background where bugs are fatal ... space shuttles can fall, fighter aircraft can crash in the middle of a densely populated city ... missiles can go haywire and explode in a school building ... Errors are not allowed. Many of the software engineers I have been privy to work with write thousands of lines of code, never compiling once, not testing every step ... just implementing the ideas they have in their head and designs they have on paper. And when they compile the errors are few ... 5 errors per thousand lines of code. Now, why do I know these figures ... because these programmers REQUIRE THEMSELVES to have metrics ... measuring their performance and striving to imporve every step of the way. This is not something enforced by management, but by the people themselves. In my mind these people are SOFTWARE ENGINEERS .
Now for the shocker ... many of these people did not have any degrees from any cool universities ... they were even old and MOST start-ups would not hire them because they are seen to be ancient. Granted, these older people are not the ones you see that want you to program in fortran because that is all they know ... many of them have intimate knowledge of COM, Windows internals, UML, and many of the other buzzwords you hear today ...
To get to my point ... there are software engineers and programmers out there ... software engineers are very very good programmers ... and many programmers will never be software engineers.
I am sure I would be some kind of genius if I knew how to make a clear distinction between them, but unfortunately I am also just human. I do think that references and a proven track record should be THE ONLY determining factors when deciding whether a programmer may call himself/herself a software engineer. Graduating from MIT or wherever means nothing much towards being a software engineer. Some people will go through the best software engineering courses and never grasp the fact that programming is ... OR should be ... AN ART.
My two cents worth ....
Life's like that!