Ironically, you have conflated two different IP concepts, and you have the rebuttal in your first sentence. If Bruce owns the Trademark for the name "BusyBox", that is a whole different kettle of fish, and your analysis would be pretty solid. I seriously doubt he has any copyright claim on the term "BusyBox". I don't know what the licensing terms were between the USL and anybody else on the usage of the term "UNIX", but I suspect BSD Unix vs. AT&T UNIX is all about the contractual terms, for which the GPL has no analog. Look how carefully the Mozilla Foundation uses trademark law to protect their brand, but they fully open the source. Again, barring a Trademark being involved, I think you're incorrect.

Kirby

That's not strictly true. If I started out with a movie that was original "Star Wars", and I slowly but surely removed every frame of that film, and then saved the film. It would not be considered a derived work of Star Wars. No harm no foul. If I started out with the Linux Kernel, and I released version 0.1, 0.2, 0.3, 0.4, up to 0.9, and finally released Kirbix at 1.0 and claimed I owned the copyright. I would be obligated to give the source code out for versions 0.1 and 0.9 (assuming I distributed them to anyone), but at 1.0, I'd be well within my rights to re-license the software. Bruce is claiming "compiliation copyright", which I'm unfamiliar with the basics of that.

I don't understand what legal principle is being applied to claim some piece of the copyright if I had replaced all of the pieces and parts. The mostly commonly known situation like this is the old BSD UNIX distribution. Eventually it was determined that UC had sole rights to all of their copy of UNIX, because they had slowly but surely replaced all of the pieces of AT&T's UNIX. I thought 4.4BSD Lite was essentially BSD UNIX minus the 7-10 files that AT&T still owned. Eventually those last bits were re-written and 386BSD and it's decendents (FreeBSD, OpenBSD, and NetBSD) were spawned in the late '80s (looks like I might have the timeline wrong, but the salient points at the end of the Wikipedia story linked above shows the thrust of this is correct). In my mind that sets a much stronger precedent then what I have seen of Bruce's claims, assuming that "I've re-written every line" claim is true. However, I believe Bruce is probably right, that it hasn't all been re-written. Just a hunch. Re-writing "everything" is pretty darn difficult.

Kirby

Funny, I took off my shoes after 9/11 but before they required it, precisely because my work boots always set off the metal detectors.

Yeah, but Evian water is just an inconvenience, as I'll buy some when I get there (if I drank bottled water). I'm not dropping the money for a laptop on the other side, especially if I can't bring it back with me. I'm highly unlikely to check my $1800 laptop. For my work, I'd not go on the trip, as me without my laptop has virtually no value. It'd take a half day just to get a machine setup so I could get logged in over the VPN, and get all of the tools I need installed.

So cheap items, there's no big deal, but items that are too expensive to just replace upon every trip, are likely to cause a much bigger backlash. Especially if they affect business people, who generate the bulk of the revenue in flying. Hell, they could tell me I couldn't take clothes except what I had on, and I'd deal with that (assuming there I could locate a decent big and tall shop in town). Who knows, maybe they'll create a "laptop license", and charge $50/year to get it renewed, and have a background check done on it. My work would cover that.

If they do ban them, look for people to start carrying on laptop hard drives, and using laptop rentals. Or a lot more driving than flying.

Kirby

Unless you have a compiler that can generate meaningful names, you are in trouble. All code must have human readable and comprehensible names. ANTLR is a great code generator, that generates very readable code, but even it has poorly named variables. You can solve the file history by extracting the commit messages. You can solve the function call tree documentation if you write a good parser (the parser for C++ is non-trivial, which is why we didn't do that).

You can write tools to detect a lot of the issues. You can write code formatters to re-flow the code to 80 characters. You might be able to get a very good code re-writer to have only one return statement. All variable names must be meaningful.

However, documenting the flow of control is beyond any compiler, at least in any human fashion. You can't indent more then 5 levels of code, which is a problem for code generators. Finally, if you use a COTS (Commercial off-the-shelf) code generator then it is acceptable. However, if you use an internal code generator, it must follow the VVSG guidelines as I recall.

They very much frown upon any generated code, that is generated by an internal tool. We used a code generator to parse the XML documents, and used some for re-formatting some Java. However, C/C++ is extremely difficult to get automated tools to work with (macros and #includes are non-trivial to deal with).

Code that is automatically translated from Python to another language will never pass compliance. You might be able to resolve trivial issues.

I completely and totally agree with the notion that those rules are stupid. However, most states use Federal Funding for the purchase of hardware for elections. Once that is done, you must be certified by the FEC, and you must follow the above guidelines. Unless your state officials want to break Federal laws, or can find all the money for it from non-Federal sources, those rules will have to be followed. It's not like you can use an off-the-shelf computer, and the hardware is only good once maybe twice a year. You'll need one that refuses all external input except for the types of storage you plan on using to transport the votes from a machine. Even if all of the software is secure from this Open Source code, they will still need to get secure hardware. The problem is you send everyone to a place alone with the machine where they have total access. Securing the machine is actually, extremely difficult.

From what I know of the state and counties, they all use Federal money. Everybody who took HAVA money has to follow both those and ROHS rules for the hardware (ROHS, I might have the acronym wrong, but it's the environmental friendly hardware when you go to dispose of it, so no using lead, etc, etc). Even most states defer to the FEC to set testing guidelines, and most states will refuse anything that does not pass the VVSG hardware and software guidelines.

You can't run an election without a scanner of some sort. You'll need a scantron type solution for a state wide vote. You can't run those any other way. If you say "DRE", I'm going to smack you. Even one's with paper trails are stupid. Scantrons to count, and paper ballots are the only way, unless we hand count (which I've got no problem with, but the computers generally do a better job, especially if you want to do accurate stats for funding of parties). Once you start doing scantrons it will require custom hardware, and the state will be incapable of dealing with it.

I think it would be great to require a security review from real security folks. The problem with most of the VSTL employees I've dealt with, is that they aren't capable of getting a paying programmers job. That's why they review someone else's code. We tried fairly hard with the stuff I worked on. We used Linux, and used a "known" Live CD to boot from, and had a completely scripted build from source code. With the exception of the RSA Crypto library and the JDK/JRE (because we couldn't prove OpenSSL's was FIPS-140.2 compliant on our OS and hardware), everything was built in from of an Election official. We built the entire toolchain that would then build the absolutely everything that was installed on the firmware. For a "real" security review, we had almost everything. If OpenJDK had been released at the time, we would have built the JDK/JRE from scratch also.

The stuff I worked on could have been hacked, especially if the source code ever leaked. Not that it was blatantly insecure, but like most code written, it has bugs and flaws that more eyes would catch. We generally did a good job using constructs that avoided buffer overflows (we avoided most C in favor of C++ where possible). The problem was the size of the programming team (I'm guessing that maybe 5-6 full time programmers worked on the system that counted a significant fraction of the votes in the 2000 and 2004 elections). I left because of the dysfunction inside the company due to dealing with Federal crapola. I just hated the code I had to write. I hated how old and antiquated the rules I had to follow were. It was a fun gig, and I liked that I got to contribute to cleaning up some of the problems folks have with electronic voting. I took it very seriously.

I agree with you, the solution is to update the rules to involve actual security. The problem is you most literally can't. There are lots of "rules of thumb", but if there were actual rules to follow, we wouldn't have security professionals we'd just write a compiler that understood the rules. These rules exist as a proxy. Each one of them was added to mitigate some problem they had before. To require more security reviews by appropriate security professionals (who are hard to come by). Most gov't officials don't have clue about most of these topics, so it is exceedingly difficult to convince them that this structure they cling to has to be changed.

Come back when it is not written in an interpreted language, in a language capable of driving hardware, and it has "real" functionality. I looked quickly, and the tabulation code is virtually empty. Both the Python and the Javascript will be non-starters and the code rejected out of hand the first time reviewed (and none of the VSTL's will have anyone capable of reviewing Python). Java passes because of the bytecode. Python might pass because of the .pyc files. The Javascript will be a problem. The lack of type declarations will likely also be a problem in Python. It will be hard to follow the documentation rules that require all of the types to be documented.

None of this code stands a chance of VVSG compliance (the Federal Election standards which code must pass to be certified if any Federal funds are used to purchase the hardware or software). The list of blatantly obvious things wrong with the code base in the one file I looked in:

• The code files does not have a valid modification history for the file.
• The code does not have per function comments.
• The code uses multiple returns inside of a single function.
• Repeatedly use the same values without having them be assigned to a constant.
• Have single variable letter names that are not used for array indexes.
• Usage of numerical constants other then -1, 0, 1 without a comment explaining the value.
• Not all control flows decision points are documented.
• It has lines longer then 80 characters.

Or at least those are the obvious things I found in one example file in the 2 minutes it took me to scan it quickly. Remember, the coding guidelines are written by people who have never written a line of code, and are designed to protect against common mistakes from the mid-80s. So the fact that the entire system is in version control is irrelevant. Even if you give them all of the version control, you must document the changes to the code at the top of the file. You must document the changes per function. Even though no one would ever do it in this day and age, your code must be printable on a standard 8.5" wide paper.

All of the rules required to follow are obscene. You can't have function or variable names that differ by a single letter. It took 3-4 years to get an exception to that rule to allow the usage of "getFoo", "setFoo", because they differ by a single letter. You can't use 0x80 to represent the MSB of a byte, if you call that PIN_8, and had PIN_1 those differ by a single character, so we had to do PIN_EIGHT, PIN_ONE. It's just archaic. Oh, and you get to document every function a function calls. Because they couldn't possible use a compiler that would build a call list automatically.

The rules don't explicitly mention exceptions, so it depends on who is reading the code if they treat an exception as having multiple entry/exit points. So it is generally easier to get the code past compliance without exceptions, even if it does lead to buggier code. The other rule they invoke is that you are only allowed to use the control flow structures documented in the VVSG (they have flow charts for the allowable forms of if, if/else, for, while, and switch statements. They specifically state that if the language you are using does not have those, you must simulate those flows of control in the language used.

Oh, and if LA thinks it has the hardest jurisdiction because they have 7 languages, I believe NY has at least 20-30 languages or dialects just in NYC, they have several election districts (they'd be called precincts anywhere else in the country, but in NY, the word precinct is only used for the NYPD and maybe the NYFD) that have more then 7.

I've written code that has been used to count ballots in both state and federal elections. Trust me, this code base will have to be re-written from scratch to meet the 2002 or 2005 VVSG standards. By the time this code is likely to be ported to certified election hardware, it will have to support the 2007 VVSG standard. Which will impose yet more conditions upon it, the most obvious is that everything is stored in the clear. Everything involved in storing the results of a ballot count must be stored in encrypted formats on all physical media. Never had to be certified under those rules, but I read them. I believe that is the big change.

I wish them the best of luck, and hope that they succeed. I think it is a great thing. I think they are tackling the engineering aspects, but lack the understanding of the bureaucracy that will be required to allow this code to ever be Federally certified. The hard part isn't writing the code. It isn't even writing the secure code. It's finding programmers willing to follow the awful rules they impose upon the code. No rule has an exception. EVER. Using gotos to avoid duplicating error handling code as is common in C in the Linux kernel, is verboten. The code would fail immediately, and no amount of explanation will overcome that. Fortunately Linux is considered "COTS", and does not have to pass review. Ultimately, they will be forced to swallow their pride and modify the code to be in a style no programmer will ever want to read or write if they want it to actually comply with the VVSG rules.

I've read both the links, and it sure seems like both you and RMS came to exactly the same conclusions. You appear to be disagreeing on the justification of that if I understand it correctly. I'm not trolling, I'm honestly confused, and think that understanding would be enlightening. You appear to be saying: "Oracle should not be allowed to own MySQL" (or at the very least, it's bad for Free Software/Open Source for that to happen). From the open letter RMS signed:

Defenders of the Oracle acquisition of its competitor naively say Oracle cannot harm MySQL, because a free version of the software is available to anyone under GNU GPL version 2.0, and if Oracle is not a good host for the GPL version of the code, future development will be taken up by other businesses and individual programmers, who could freely and easily "fork" the GPL'd code into a new platform. This defense fails for the reasons that follow. MySQL uses the parallel licensing approach to generate revenue to continue the FLOSS development of the software. If Oracle acquired MySQL, it would then be the only entity able to release the code other than under the GPL. Oracle would not be obligated to diligently sell or reasonably price the MySQL commercial licenses. More importantly, Oracle is under no obligation to use the revenues from these licenses to advance MySQL. In making decisions in these matters, Oracle is facing an obvious conflict of interest – the continued development of a powerful, feature rich free alternative to its core product. ...

I think RMS is over the top, but generally follows his principle to a fault. So the assertion that he's failing the Free Software Principles strikes me as odd. You've got plenty of credibility as a major MySQL (and derivatives) developer. If I keep getting the source code, I'm not sure I see the problem. Now that somebody who isn't Free Software friendly owns the copyright seems like a crying shame (in order to upgrade to GPLv3 will take a total re-write). The fact that only Oracle will be able to sell a commercial license doesn't seem like a bad thing for Free Software. It seems like a really bad thing for all the folks that wanted to buy a commercial license to avoid being a part of the free software community. Again, I'm just trying to understand your perspective. I think you have a salient point, but I'm not able to see what the significant difference in yours and RMS's opinion is. From what I can tell, you both clearly agree on the outcome, just not the justification. I think if you can clarify this it would be enlightening to me personally, and many others.

True, but if you give me the written offer, I believe I'm capable of transferring it to anyone I wish to work on that software on my behalf. If you read up on the early Stallman writings, he was worried that non-technical people would be unable to work on the software themselves. I have always interpreted that clause as part of the solution. Someone who knows nothing about software can hire a third party to fix the software on their behalf. In that case, I would transfer my written offer to that third party and they would request the software and work on it.

Maybe I misunderstood it all. I don't agree with the first, second, and third party analysis of the other response to my original post. However, I am not a Lawyer, so my layperson understanding might be completely wrong.

Kirby

Section 3.B:

Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

To give any third party, not merely a third party that happens to know my magic number that give me access.

At my company we always choose to satisfy 3.A, because for the cost of handing you the CD with the source code along with our product, the entire transaction is finished, there are no more obligations on either side to provide anything else.

They should be providing a written offer that any third party should be able to show up with to give the source code. I shouldn't need to know any magic numbers or any other details. I might have to show up with the original authentic copy of the written offer, but there is not much to quibble about over there. I have always assumed that I could give the written offer to as many people as I feel like, but I've never seen that clearly established. Otherwise, subverting the GPL would be fairly trivial. Once I show up with the original authentic original written offer, I can distribute it to whomever I wish.

Kirby

Careful, you've just caused a different class of problems by you're macro. Well, actually you have the signature wrong, and then you've caused a problem. It is "memcpy(dst, dst_size, src, src_size)", the sizes go next to the appropriate pointers. Next, if size has any side affects the Macro you propose will cause the side affects twice. I forget the idiomatic way to resolve this is off hand, but check "Code Complete" or "Writing Solid C", I'm fairly sure they discuss the "right" way to handle this problem. While my hunch is that you're smart enough to know this, my guess is that too many C programmers don't realize the danger of such macros.

However, this has the law of unintended consequences. Ulrich Drepper has some epic rants about why you shouldn't use any of the str* functions, and the logic is the same. If you are copying and you stop short in the copy, might be just as bad as going long. What is going to happen when the security problem is caused *BECAUSE* you didn't copy everything? The lack of a complete copy is silently truncated with no way for the caller to tell it happened. Well they can tell it happened, merely by duplicating the check in the call and then propagating the error. If nothing else, imagine a really long command line that ends with "rm -rf .kde", and I lined it all perfectly so that the all that is copied is "rm -rf .". We just have 30 years of experience to tell us that copying long is a problem. I'm curious if in 30 years, we'll have the experience to tell us that copying short is a problem also. Maybe, just maybe programmers should be very careful.

Without the actual specs of memcpy_s, I'm not sure. This is my best guess as to the semantics. You're portability concern however is fairly laughable: #define memcpy_s(dest, dest_size, src, src_size) memcpy(dest, src, MIN(dest_size, src_size)) Assuming that the MIN correctly handles the parameters with side affects problem. People have been handling trivial portability concerns for a long time. The bcopy function comes to mind. I'm sure Autoconf will have this added as a standard macro inside of a month, but it is simple enough to implement yourself if you don't use autoconf or the like.

Kirby

I don't know, it's probably literally closer to "priceless", which isn't infinitely valuable, but a market can't be established, therefore a value/price cannot be determined (see the description of "Neoclassical Value" on the Wikipedia link, lots of artwork is priceless in this sense, even though it sells for a specific value).

What you're describing is the cost, not the price or value. If I blew $100K on rebuilding a fully restored mint condition Ford Fiesta from 1994, doesn't mean that I could sell it for that, or that it represented the value. It means I blew $100K, and now had a car that is probably worth 1/10th at best. That's just a guess.

Even if you were going to present it that way, it's not like the rocks are the only thing that came out of that money. So if you want to determine if it was "worth it", or "profitable" to go to the moon, the rocks aren't the only thing of value to come out of all that money being spent.

Kirby

I've got plenty of friends who are in fact teachers... Yes, they get a lot more time off then I do. Several of them that I know get the quoted 18-20 weeks off a year. Between 12 weeks for summer, and another 3-4 off during the school year between winter and spring break. Generally they start one week earlier, and stay one week later. As to weather or not they can get a paying job for that time. Yes, yes you can. I knew several teachers who lined up seasonal work. It's not like they don't get their regular paycheck. A slightly over minimum wage job at retail place is "good money" (i.e. it's like getting a $6/hr raise for every hour you work seasonally, I'd take a $6/hr raise any time), when you have a regular job you're not at paying you. Besides, the time off is compensation. Lots of people would really appreciate getting all that time off. I would, but not enough to put up with with the pay or the coddled students.

I'm not anti-Teacher, I'm anti-Teachers-Union. I hate that the union has a strangle hold on an honorable profession, that should be held in far higher esteem then it is.

I didn't say the job was easy or fun. Neither is being a Janitor, but it's not hard to fire Janitors as far as a I know. I've been a teaching assistant and a grader! I know exactly how much work that is. I've taught classrooms full of college freshman remedial math for 20hrs a week while going to college. Believe it or not, it's actually not particularly difficult or nearly as stressful as my current employer. Not even close. Yeah, and I made minimum wage and was annoyed by it at the time.

Finally, lets discuss the false analogy between: people are outstanding at what they do and are in total control of their pay and projects, and folks who let a union work negotiate all of their compensation. Wait, there's no point, it's a false analogy that has nothing to do with the discussion at hand.

Some Unions are good, and some are bad. I'm unaware of the various entertainment unions negotiating that actors or directors become effectively life long employees assuming they don't kill someone or sexually assault one children. The entertainment business is fundamentally different because the jobs end, and you resolve problem children by just not hiring them again. If teachers faced such behavior a lot of problem teacher situations would get resolved. There wouldn't be a problem firing a bad teacher, you'd just not hire them at the beginning of the following year.

And I totally agree, that teachers should be far, far better compensated, I've been saying that for 15 years. It would be a great investment. Part of that is teaching should be seen as a privilege, not the "right", that the teachers union has turned it into once you join.

Kirby

Well, let's see... Teachers make a lot less money because they work a lot less then a regular 9 to 5 guy (Assuming they work 8-10 hour days, which not all do, some HS instructors probably put in a 10 hour day on a regular basis), they still end up with 18-20 weeks off a year. That's a huge perk, and a great time for them to go earn additional income if it interests them.

Teachers make a lot less because they have to follow the laws of economics too... There are more applications for jobs then you can shake a stick at. Which generally means there's going to be lower pay. It's also a sign that it's not a job that requires unique talents (or at least it doesn't require it to get hired, in my experience it does to do it well). Plus teachers aren't a profit center, at least in the short term. So there's no revenue to pay them with if they excel. They get paid out of state tax money generally.

Next, teachers earn a lot less, because well, they attract a lot of folks with a lot less talent. That isn't to say no teacher have talent. Now some of that is a vicious cycle. I'd go be a teacher if I could teach high end mathematics right away, and I could make similar money as I do as a professional programmer. Unfortunately, that's not how the system works. I've been teaching folks mathematics since I was probably 5 or 6 years old. I'm really, really good at math and teaching math. I'd have to teach remedial algebra, or consumer math for 15 years before I could get a crack at teaching the best and brightest students calculus or discrete mathematics in a High School.

I know the Education College was where folks went when they couldn't cut it in the Arts and Sciences college. Just because you're flunking Chemistry, sure won't stop you from teaching it in a High School. I was also amused at just how much plagerism and flat out cheating folks from the Education college did. They all had copies of assignments previous years students handed it. They all pooled together and worked on non-group projects in groups. I was amused how little respect they had for the types of rules they would then be asked to enforce. Ironically, I always found teachers to be a fairly poorly educated group while I was in college.

Finally, teachers make a lot less because there's a union. All pay raises are on a schedule, and generally fairly uniform year to year. Because it's hard to objectively rate teachers, and there's a union and there's relatively little competition or reason to excel or perform, and the bad people aren't forced to leave because of sheer economics. Finally they are paid out of our taxes, and nobody who works for the state is overpaid generally.

Finally, don't forget that like most state or union jobs, it's not generally about the "pay", it's about "compensation". Generally speaking, teachers get much better benefits and retirement plans the folks in the private sector.

Triple the pay of teachers, and I think you'd see a huge change in the education system in this country. There are plenty of us who like teaching, but realize the economics of it are just awful. I'd work at a private school in a heartbeat assuming the pay was reasonable relative to my current compensation, and I was allowed to eject students who were disruptive with impunity.

I have a great deal of respect for quality teachers, and I had plenty as I went to some of the better public schools in the country. I had plenty of great teachers, who worked hard to ensure that I learned valuable skills. I know they enjoyed all the leisure time it got them. I know how frustrating it was to teach remedial classes and deal with angst ridden, over protected students. That however, doesn't mean that unions aren't part of the problem. It doesn't mean that the state isn't part of the problem. It doesn't mean the bureaucracy isn't part of the problem.

Kirby

If it makes you feel any better, you beat Woz to registering for slashdot.

Kirby

All of the history is cryptographically signed, so nobody can re-write history without everyone else noticing. Unless there is precisely one copy of the history.

Imagine that you have v2.3.1, and you want to write feature v2.3.1 + FooFeature. In my experience, it is best to write "FooFeature" as a series of small self contained patches that move from the base, towards implementing FooFeature. For now, let us say that FooFeature will take 4 patches for the sake of argument. We'll call them Foo1, Foo2, Foo3, Foo4. I go implement this feature, and publish it out to a repository of mine in a branch called "FooFeature-branch".

I publish it to my personal repository. You go review it, and you tell me that I have one flaw in each patch. So I have two choices:

• Implement Foo5 fixing the 4 flaws.
• Modify the four patches generating Foo1', Foo2', Foo3', Foo4'.

Historically are you interested in having 4 perfect patches, or 5 patches, 4 of which are flawed? I prefer having 4 really solid patches, rather then fixing all the flaws in a fifth. In Hg, you can use Mercurial to accomplish this, but it's hard to do once you publish. With git, it's trivial... Search for git rebase --interactive to find people talking about the wonders of it. It's also useful to linearize your history. Doing this is makes all of the concurrent work look like it was done sequentially. That's a good thing when you go to use bisect functionality to search for a bug. You cannot do that in hg, which means using hg bisect is less likely to zone in on an error when doing lots of concurrent development.

In the end, the rule is, you never re-write history once it's published to a "public" repository. I use it all the time, while developing features in my personal repository.

Kirby