That "story" linked above wasn't written by any reportrer, hack or not. It's a press release from StatMarket and WebSideStory. Press releases are nothing more than marketing propaganda designed to financially aid the group that makes the press release. Generally, press releases are written by a company's marketing department.
It should come as no surprise to anyone that the statistics in that release are flawed. Someone who can competently produce statistical analyses is very unlikely to be employed in a marketing department; there are far more lucrative and fulfilling employment opportunities for statisticians in other areas.
I addressed all of your points already in this thread.
"negotiate" doesn't mean that there is a two-way discussion of terms. In its simplest form, and the form that is nearly always the case, there is an offer of terms from one party and an acceptance by the other. That is still "negotiation" in the legal sense.
Next, in nearly all contract situations, the two parties are not aware of each other. It's a one-way affair in which the accepting party is aware of the offering party, but not the reverse. The offering party only becomes aware of the accepting party/after/ acceptance occurs.
As far as receiving something of benefit, I have already addressed what benefit/I/ receive when people use Linux. I don't need to know that it's Mrs. Marge Simpson, of 123 Evergreen Terrace to receive my benefit.
It is certainly/possible/ to negotiate terms on the Linux kernel. But there is no single point of communication, so it would be difficult to do so. You'd have to contact every one of the hundreds (if not thousands) of contributors to the Linux kernel, and convince them all to participate. Or, at least, the contributors who have affected portions of the kernel that you're going to be using.
As for agreement, the Linux authors collectively agree to the terms when they offer them to you. If they didn't agree, they wouldn't have offered those terms, now would they? You agree when you exercise one of the benefits of those terms that you couldn't've gotten in any other way: by redistributing the kernel.
It depends on how weak microsoft gets, and how much time my other projects are demanding.
If microsoft gets so weak that there's no chance of it ever recovering, then I'll consider that goal to be achieved.
If there's something new that I need out of Linux, I'll probably keep working on it (I like my mini beowulf cluster, after all). Otherwise I might dust off that old OS that I was writing and abandoned when I started up with Linux.
It's not always possible (in fact it rarely is) to write a license that it simultaneously rigorous enough for a court and comprehensible enough for the average person. That's why a lot of modern licenses have commentaries at the beginning that attempt to explain the goals behind the license. The GPL is a good example of this. But the commentary is just that: it has no importance in legal proceedings except in that it speaks to the intentions of the parties.
You have to look at it the same way as a program and its users' guide. We programmers have little problem reading source code (even complex source code) and figuring out what's going on. But joe blow can't do that. Both of us benefit from the users' guide: joe blow so he can make sense of what he's seeing, and us so that we can figure out whether or not a particular behavior is a bug or if it's intentional in some strange way. But as far as the computer is concerned, the users' guide is meaningless. The code is the be all and end all of the system's function.
Secondly, in the context of licences intended to be used internationally I think that attempts to be clever with the legalese are misguided. Sure your obscure term of art wins you points in your home jurisdiction but elsewhere it may be interpreted completely differently - it may even have an established contrary meaning. And no, you can't just assume that foreign courts will accept any clauses you put in that forbid them from interpreting the contracts under their own laws.
That's certainly true. Unfortunately there isn't a whole lot of precedent about the validity of choice of jurisdiction clauses. English common law countries tend to obey them (and US courts seem to always do so). But I can't speak about European common law countries, Confucian law countries, or others.
But this whole issue about things happening internationally is really quite new. Before the computer age, international commercial agreements were nearly always exchange-of-goods, so there really wasn't any kind of licensing issue. There were certainly cases of a foreign manufacturer buying a production model of someone's invention, then copying it and producing it themselves in their own countries. And the few court proceedings in these matters were nearly always ineffective. But with the rate at which things are going, we can expect to start seeing a whole lot more cases discussing international licensing.
Thirdly, you're simply wrong in your assertion "The next thing is that all licenses are based in contract law. There is no room in copyright law for granting permissions beyond those explicitly enumerated (and irrevocable) in copyright law."
The one thing that copyright law does give the copyright holder is the right to give people permission to do the activities that are otherwise prohibited by copyright law.
You're thinking about contract law. Copyright law says "this thing is owned by the copyright holder, and he can prevent anyone he wants from getting access to it" (basically). The only variant that exists in copyright law is the concept of "public domain": a person who would otherwise hold copyright over something can put that thing into the public domain, in which case no one has differential rights to that thing. Contract law says "different parties have different rights, resources, and privileges, and they can negotiate exchanges of those rights, resources, and privileges under these rules." Copyright grants a privilege to one party that is excluded from other parties. Contract law influences how the copyright holder can grant his priveleges to other people.
It depends on the license. For the MS EULA, you are certainly correct. But software written by developers that expect/invite/encourage participation in the development process should have a license written for developers. Of course lawyers and judges will be one audience for the license, but they will not be the primary audience.
Why would you ever write a license that you don't want to be enforceable? If you want it to be enforceable, then it has to be (principally) comprehensible in court. As to determining whether or not a contract is clear, the court will look at the language itself, not defer to the statements of the defendant or plaintiff. The only exception is when both defendant and plaintiff agree on the interpretation of a particular clause, in which case the court will take that interpretation rather than the interpretation that the court might find on its own. But in such a case, I think you'd agree that the license is sufficiently clear.
Here's a sample license: "You may freely copy, distribute, modify, translate, or otherwise transmit and transform this software without restriction." Just how does this qualify as a contract? Where is the agreement? Where is the consideration? Are you saying that the above license is not valid?
Agreements between parties fall exclusively under the jurisdiction of contract law. The parties may, in fact, act under an agreement that is an invalid contract, but it is still under the jurisdiction of contract law.
More directly, let's look at your sample license. Presumably, the person offering the license possesses a copyright in the software. So the holder is granting certain distribution and modification privileges. That's the consideration that he's giving. The license doesn't explicitly enumerate consideration that the recipient is granting back to the holder, but (and this is an important principle in contract law) since the holder is the party that offered the contract, it is presumed that the holder is gaining an automatic intangible concession in return (such as the pride of knowing that other people want to use his software). The important thing is that the person who offers terms is presumed to agree to the terms; if he didn't agree to them, he wouldn't've offered them in the first place.
Then, if the recipient of the software actually does exercise one of the privileges granted to him in the license, then he has also agreed to the license (contract). This is another important concept in contract law: implied consent. If one party exercises a privilege granted only under a contract, then that party has consented to that contract. This concept actually doesn't exist in the text of the legislation that forms contract law. This exists in a more important place: legal precedent.
So the example license that you present has offer, has exchange of consideration, and has consent. All three of the keystones that are required for a contract to be valid.
What exchange? In the case of the Linux (as an example) I have given nothing to Linus Torvalds. No money. No pledges of royalties. No promises that I will ever contribute anything back to the project.
I'm glad that you brought up Linux. Linux uses a fragmented intellectual property model, in which the entire body is covered by a single license, but the ownership of the individual pieces are retained by the original authors. So when you use Linux, you are entering into an agreement with each of the separable authors of the kernel.
As one of the authors of the Linux kernel (interval timers, original/proc filesystem, assorted bugfixes, and the PCI WDT support), allow me to explain the consideration that you have granted back to me by using Linux. My principle motivation in being involved in Linux is to weaken Microsoft. By using Linux, you are not using Windows on that same box at the same time. Therefore, you, by using Linux, are acting to weaken Microsoft. So by using Linux, you are volunteering your time and effort in support of one of my goals. That's the consideration that you give me.
I can say for certainty that the same consideration applies to a large number of the people involved in the Linux kernel, but I will neither name names, nor will I attempt to enumerate all the considerations that are gained by all the individual contributors to Linux (primarily because I don't know them all).
I'm not granting him any permissions or benefits. Heck, Linus and I have never even met, so how can we possibly exchange anything!
If physical meeting were a requirement for a binding contract, then the only commerce that would exist would be face-to-face barter. Mail order, internet sales, telephone solicitation, early book sales (even in person), credit cards, checks, ATM cards, and even paper currency all exist only because of nonlocal agreements to contracts.
Contracts are never "imposed." They must be agreed to voluntarily by both parties.
That's only sort of true. As the holder of a copyright, I can offer a contract without allowing negotiation. True, the contract doesn't bind unless the other party agrees, but in that case the other party doesn't get my software, either. So I have effectively imposed my contract on all people who want to use my software.
This is the central argument behind the (many) suits over the years asserting that Microsoft has illegally leveraged its monopoly power to impose contracts.
First off, licenses aren't written for end users. Yes, they're purportedly intended to inform a user of their privileges, but the true audience of a license is a judge and a pack of lawyers. The important thing for a license isn't that it's clear to joe blow, but that it's clear in court: a contract that's clear to joe blow is meaningless if a court can't make heads or tails of it. Confusing terminology in contracts is the result of two problems. First, colloquial language is very subjective and very slippery, and so legal documents have to be written in a specialized dialect of English that has arisen over centuries of effort. It's the same problem with programming languages: we can't have a truly natural language programming language because it's too imprecise. But just as engineers have an easy time reading and understanding source code, so do lawyers have an easy time reading legalese. The second problem is that most lawyers have a very poor mastery of both English/and/ the law, so an already dense dialect is made nearly incomprehensible.
The next thing is that all licenses are based in contract law. There is no room in copyright law for granting permissions beyond those explicitly enumerated (and irrevocable) in copyright law. If you want to grant extra permissions, or revoke certain permissions, then you/must/ use contract law. You have no choice. That's the primary purpose of contract law: to provide a framework under which two parties can clearly enumerate an exchange of permissions or other benefits.
Next, you have to consider the purpose behind an OSS license. One person may have a different purpose from you. To me, the term OSS means "you can read my source code, and you can contribute changes back to me". That's it. It doesn't say anything about whether or not someone can use the source code. It doesn't say anything about whether or not someone can produce derivative works. Sure, GPL talks about those things, but that's because GPL goes farther than the simple concept of OSS. The same goes for other OSS licenses: they will almost always go beyond the simple concept of OSS, building on top of the concept in order to further the purposes that the author has in offering the software as OSS in the first place.
As an example, someone might be making their software OSS for the purpose of crushing Windows. It shouldn't be too surprising to see that their license contains a clause prohibiting the porting of the software to any Microsoft operating system, either natively or under an emulator. Does OSS say anything about that? Nope. Does GPL say anything about that? Nope. But that author wants to crush Windows, so he's not very well going to allow his software to be used under Windows, now is he? He's got a purpose, and his license reflects that purpose.
Then there's the last point. Software licenses/as contracts/ are not an invention of the proprietary software industry. Software licenses/in their entirety/ are an invention of the proprietary software industry. Specifically, an invention of Microsoft. Before Billy went on a rampage about people "stealing" his BASIC interpreter in the early 70s, there were no software licenses at all. Software was freely distributed or it was custom coded under contract for a specific client's internal use. That was software. There was no (serious) retail software at all. Then Billy got upset at those pesky Altair users and went off on a tear. After years of work, the courts started upholding software copyrights, and the entire retail software industry was born.
The only thing that software copyrights do is to allow the author of software to restrict his software's distribution. Once that's in place, the author can then impose a license (read: contract) on the user for the software. Without software copyrights, the licenses would be meaningless, because a user could just say "naw, I'm not gonna agree to the license, so it doesn't bind me, but I'm gonna use the software anyway because you can't prevent me from getting a copy of it."
Erm. Maybe I'm being a little bit antiquated, but it isn't necessary to have TiVo or Replay or anything like that in order to catch shows that are in bad timeslots. I have this amazing device called a VCR. It does this just fine.
Re:correction...it was an Altos
on
Lineo Frees CP/M
·
· Score: 1
Ah, the Altos. My first computer was an Altos 5-5D. Same story as you, pretty much. Got it with CP/M (on 8" floppies). Had a massive 5MB winchester disk. And I still have my 8" Zork I floppy. This old Altos didn't have a built-in monitor or anything: it had 3 serial ports to connect to terminals. I had an Adds Viewpoint and a TVI hooked up to it. I even got on the MP/M beta test.
God, I loved the Kaypro 10. My first professional programming gig was writing a BBS on the Kaypro 10, in assembly, with a Hayes Smartmodem (an actual Hayes Smartmodem, not a clone). That was a fun job. *sigh* Memories.
Gyroscopic effects are proportional to the rotational speed of the gyro, the mass of the gyro, and the diameter of the gyro. This thing has a tiny diameter, tiny mass, and huge speed. I don't think there would be much effect.
Well, I was just talking about the mass that you have to invest in the turbine rotor in order for it to remain structurally sound as a function of size. That's why I said that the efficiency/potentially/ increases with a reduction of size. The mass of the rotor has a major influence on the amount of energy that can be extracted from the incoming airstream.
Why does the power output decrease by the cube? I understand why friction decreases by the square (actually, I suspect that friction decreases more slowly than that, because surface imperfections become more important than at normal scales).
Even better is the fact that the diffusion speed of pure H2 at standard temperature and pressure is pretty damned fast. Even if you had a catastrophic failure of the tank, your ignition source would have to be present at the time of the failure of really soon thereafter (we're talking miliseconds here) in order to ignite the H2.
The problem with fuel cells is that they're BIG for the power that they produce. A turbine is small for the power that it produces. So this dime-sized turbine supposedly generates 20W of power. How big of a fuel cell do you need in order to get 20W out of hydrogen?
I don't know the numbers myself. It could very well be that a fuel cell's power-to-volume ratio is good enough that you could still manage to power a laptop off of one. But since it's not as good as a turbine, that means that the turbine-powered "battery" pack would have more space available for fuel.
Even better, a turbine's efficiency (potentially) increases as you get it smaller. The major stumbling block for turbines is making the fan strong enough to handle the huge stresses that are put on it by the awesome speeds at which it rotates. But as a turbine gets smaller, its strength increases: mass decreases as the cube, but the various strength measurements (torsional, tensile, etc.) decrease by the square of the size. Silicon is far too weak for full-sized turbines, but (apparently) it works just fine for these submini turbines.
Yes, as an undergraduate. By that point, I had already been programming for 10 years (I started programming when I was 12, in assembly, on an Altos 5-5D "minicomputer").
There are two things that you apparently don't realize.
The first is that academia is overwhelmed by politics and jockeying for position. This is most prevalent among graduate students (who are struggling to attract influential professors as research sponsors) and among associate professors (whor are struggling to advance along the tenure track, which has progressively fewer openings the farther you travel). In academia, it's not the project that matters, but how you're able to leverage that project for personal advancement. Yes, the corporate world has politics as well, but aside from a few rare companies, corporate politics are babies struggling over teddybears in the crib compared to academic politics.
The other thing that you don't realize is that the nature of user interface design is that it is subtle. You need to come up with mechanisms that help the user out without the user being made aware that they're being helped out. That's the whole game. So if you come up with a successful mechanism, that mechanism is, by the very nature of the game, subtle.
Here are the details:
When I came on board, vertices were selected by clicking the mouse within 20 pixels of the vertice's location. When you have a lot of vertices on the screen, these regions overlap, and the specific vertex that gets selected when you click in an overlap is unpredictable (it depends on the ordering of the vertices in the data structures). You could even end up selecting a vertex that was scrolled out of the visible area of the layout.
My change was to define "pick regions". These regions were dynamic, depending on your view, the vertex density, etc. The way it worked was that I iterated over the visible vertexes (we had a data structure that made this easy, and also let us easily find the vertices closest to a particular x,y coordinate: that was another research project in itself). For any click location, I found the eight closest vertices. For each vertex, I calculated its weighted distance from the click location (I used distance-squared, rather than distance, for reasons that will become apparent). I found the vertex that had the smallest distance, and then I looked for the vertex with the second smallest distance. That second vertex's distance had to be at least 35% larger (that was a tunable parameter, and my experiments showed that 35% number to be the best) than the first vertex's distance in order for the first vertex to be selected. If that test failed, then no vertex was selected. All of these calculations were done using screen coordinates (pixels) rather than routing coordinates, so that the view parameters would get incorporated into the calculation. The net result of this is that each vertex was surrounded by a lumpy region that was "owned" by that vertex. Any click in that region would select the owning vertex. The regions were lumpy because their shape in any direction would depend on the neighboring vertices. But by using a distance-squared metric, the lumpiness was somewhat smoothed out, thereby avoiding long and counterintuitive peninsulae spreading through the layout (and spared me the cost of a square root calculation). The overshoot requirement ensured that there were gaps between every pick region, where a click wouldn't select any vertex. These gaps were about 16% of the vertex density (sqrt(1.35) ~= 1.16). So they were small enough that it would be hard to click in a gap, but large enough that any click that fell outside of a gap was unambiguously associated with the same vertex for both the computer and the user.
The change had two results: 1) when the user successfully selected a vertex, it was always the same vertex that the user intended, and 2) when the user was being ambiguous, no vertex would get selected. The second possibility also existed in the previous mechanism, so it wasn't noticeable. And the first possibility meant that the users never ended up selecting the wrong vertex.
So, yes, the change was subtle. It wasn't subtle to someone looking at the code, but at that time the UI was 5MB of dense X11 and Motif code, so the researchers never ventured into it. We also had a standing policy that no one was to touch anyone else's module, and if anyone needed UI work done, they were to come talk to me to code it. This all means that they never even looked into the code until after my bombshell was dropped.
Yes, actually, GIMP is a deployment tool. We don't use that nasty gui that GIMP has.
Our website, if you had browsed around a bit to see, has an ad banner creator on it. That creator is a cgi front end to a number of scheme scripts that I and a contractor wrote, that run in GIMP's script-fu plugin.
Our website designer doesn't use macromedia software to generate web pages. But he does play around a lot with flash animations. Has a lot of fun with them. And there's some website out there that gives a lot of tips and info on scripting in flash, which he spends a lot of time browsing. He told me the URL once, but I don't have it handy right now. Anyway, the point is that it's not very surprising that he recycled an existing name for his stuff. And look at that MM_openBrWindow() function. It's not exactly a difficult function, now is it?
When I was in college, I worked on a research project for surface routing of multichipmodules. I wasn't actually one of the researchers, I was just there to code the user interface that went on top of the actual research project.
A major part of the user interface was clicking on vertices in the routing layout and dragging them around. When you have 10,000 vertices visible in the window, this can get obnoxious if you don't have a good and unambiguous selection mechanism.
Unfortunately, when I came on board, we had a bad and ambiguous selection mechanism.:(
We had weekly meetings of all the coders (that includes all the grad students who were doing the actual research) and we'd discuss new ideas. I'd seen a whole lot of ideas get passed around at previous meetings, and no matter the idea, it was always met with grave resistance. People wanted feasability studies, analyses, reports, blah blah blah. It was nasty. Far worse than any company I've worked for since, but that was academia, so it's not surprising.
So before presenting my new interface, I coded it up (took me 4 hours) and put it into the standard build. This was on a Tuesday. So for 3 days (Wednesday, Thursday, and part of Friday) people were using my new interface without realising it. I noticed a distinct change in the character of the conversations going on. But the change was subtle enough that no one immediately came to me to discuss it. Previous to my change, there was always a lot of grumbling and cursing whenever someone selected the wrong vertex, and all those stopped suddenly when I installed the new interface.
Friday came and I presented my new interface idea. People were very down on it. They wanted studies. They wanted an analysis of the time it would take to code it. They wanted references to existing peer reviewed user interface studies. Blah blah blah. I knew that would happen. So then I dropped the bombshell. I explained that I already coded it, it took 4 hours, and they've all been using it since Wednesday morning. The expressions on their faces and the stunned silence were precious. Apparently they were going over their use of the UI in their heads over the past few days, because shortly the room erupted in very complimentary discussion all around.
Of course I was told not to do that again, but I considered it an unqualified success. Not only did I get my new mechanism into the project, not only was the new mechanism successful, but I also managed to show everyone how damned bureaucratic they were being, and how much damage they were doing to the productivity of the project.
It was beautiful.
The point of this story is that a successful feature depends much more on the end result, not on the process. The function is far more important than the process. Sure, the process is important, but when you find yourself sacrificing functionality for the sake of process, you've just lost the war. Clear coding is nice. An architecture document is nice (I agree that a well thought out architecture is essential, but that is different from a well thought out written architecture). But they are both pale shadows when weighed against the final product.
First, I'm going to assume that what you're talking about is projects that use OSS, rather than projects that generate OSS.
At AdAce (shameless plug), I pressured my CEO to let me build the website on top of OSS tools and systems. It was a relatively easy sell at the time, because I (the CSO) and the CTO were both OSS enthusiasts, and we got a lot of respect from our CEO for our technical expertise. This wasn't one of those micromanaging CEOs that some companies have.
Now I'm both CTO and CSO, and I'm quite happy with the result of using OSS wherever possible.
The website linked above is built on top of Apache, Linux, GIMP, MySQL, mod_ssl, and smail. We use gcc and all the other g-tools to build the beast. (We wanted to use PNG for all our graphics, but IE's support for PNG is just too horrible.)
Our system has only two pieces using closed-source closed-source software.
The first is the library provided to us by our credit card processor in order to communicate with their systems (signio, now bought by verisign). But that library was built using ssleay, and knowing that I was able to patch up the binary library to avoid certain SSL attacks against us. (thank you, ssleay!)
The second piece is our ad servers (realmedia). We chose closed source ad servers because we needed a certain set of features, and the OSS ad servers out there are too far behind in that feature set for us to use them. We could have added the features we need, but that would've but a huge engineering burden on us that we couldn't afford at the time. Now that we've come far enough, we're evaluating the current OSS ad servers to see which one we're going to adopt, and add the features that we need (and, of course, commit those new features back to the project).
The selling points that we used to push the OSS point are:
1) The security of an OSS project is superior to the security of a closed source project. This is because either the security holes are found by other people and patches are submitted back to the project, or I (whose duty it is to analyze our security) can find the problems and fix them. While with a closed source project, this is all dependent on the very busy engineers at the software's vendor, who will always prioritize security below where we would want it prioritized (we want it to be the #1 priority). It's so nice to be free of worrying over priority conflicts between us and a software vendor.
2) The stability is superior for the same reason.
3) Licensing fees are trivial. For most OSS projects, licensing is a voluntary donation to the support organization, and the size of that donation is up to us to determine. For other OSS projects, licensing is free. The only real exception is MySQL, which has specified certain donation levels which, nevertheless, are far lower than competing database software's license fees.
4) When (not if) the vendor of a closed source project moves on to other projects, and abandons the software that we're using, we're screwed. But if we use OSS, then we've got the source code, and can continue to support ourselves. Plus, when that happens, we've developed enough internal expertise with the software that it's not too difficult for us to support ourselves.
Apache, in particular, has been a huge boon to us. It's so easy to write modules for Apache that we've got our server packed to the gills with custom modules to perform certain session management and dynamic content tasks for us. These have improved our website's speed and maintainability by a huge margin. (some of these modules have progressed far enough that we're nearly ready to contribute them back to the Apache project.)
In hindsight, we made one big mistake with our OSS work. That is, whenever we brought some new OSS project on board, we would assign it to one engineer, and that engineer was to become our expert on that system. We spread this load around so that no one engineer would be overburdened. But what we should have done (in addition) was to have a "debriefing" a couple weeks after the assignment, so that that engineer could brain-dump a portion of his expertise into the rest of us. As it happened, we had engineers leave us (which is the usual case in engineering) who were the only people with expertise in a particular piece of the puzzle. And when that happened, we were left scrambling to redevelop the lost expertise. It all turned out ok, but it might not have.
These days, as a large result of using OSS wherever possible, we're in a very good position. Nearly all of our competing ad networks have abandoned the market for greener pastures, and that includes every ad network that's bigger than us except for 24/7 and doubleclick. The other big guys have switched to licensing their proprietary ad servers to other ad networks. As a direct result of our adoption of OSS, our total monthly technology costs are trivial, and we can survive comfortably on a truly tiny number of sales in a month. Having leaned heavily on OSS software, we were also able to focus a lot of our engineering on automating the administration of our system to a large a degree, so our administrative burdens are also tiny. This is letting us ride out this deep depression in our industry without worries, and when things turn around we'll be in a very enviable position.
The only downside to OSS is that there are a large number of licenses to read and discuss with our legal department. This number is, of course, similar to the number of licenses that we would be under if each individual portion of our website used equivalent closed source projects. However, closed source projects tend to bundle multiple pieces together under a single license, so we would actually have fewer pieces (and hence fewer licenses) if we used closed source. What's worse, many OSS projects use licenses that are superficially the same, but contain modifications that are specific to that project. So, though it's tempting to read the opening clauses and conclude that the license is the same as this other license that we already analyzed, it's foolish to do so.
But the bundling phenomenon of closed source projects is actually a disadvantage. Since no closed-source project satisfies all our needs, we would definately need multiple. And if different closed-source pieces overlap in their bundling, then either we have to reject a piece that we'd like to use, or we'd have to find a way to disable the pieces that we don't want to use. That's always a pain.
I've always loved the back references in The Tick comic and cartoon. Both references to previous episodes (like "CHA" carved into the moon) and cultural references (the opening shot of the diner scene in the first issue of the comic). Do you intend to follow in that "tradition" in the live-action series?
I know you get asked this with every Tick project that you do, but here it is again: are you guys open to the idea of redoing The Night of the Million Zillion Ninjas for the live action series? That story line was always the cornerstone of The Tick in my mind. I think it would work well in the live action. And since, in the previous interview, you mentioned that you might bring Paul the Samurai into the live action series, NofMZN seems like the perfect way to do it.
And this is one of the points that I brought up in my email to W3C: any "RAND" license is automatically going to be unreasonable to open source people. So if the W3C implements the policy, and then later produces a RAND standard, then one of two things will happen:
1) the standard covers some method that no one really cares about, and so it is ignored, or
2) the standard covers some method that people do care about, in which case open source people will develop a competing RF standard that will (given a few years) utterly dominate the niche. The W3C's RAND standard will then be ignored.
In either case, the W3C's effort in developing the RAND standard is completely wasted. The only one who receives any benefit from such a standard is the patent holder. W3C loses. Users lose. Developers lose. Patent licensees lose.
So if any RAND-based standard is a waste of time, why have a RAND policy in the first place?
And this doesn't even get into all the complaints I had about how their RAND policy completely fails to fulfill its goal: ensuring that if a W3C recommendation is encumbered, that it learns about it before acceptance of the recommendation.
I'm innocent, I tell you! I've never slashdotted anyone. . . Well, perhaps I've contributed to someone being slashdotted.:)
The rigidium vs. rigidum difference could easily be my error. I'm known for using -ium when -um is correct. A common mistake on my part.
I think I'll take your expert's advice and switch to nolite
I like your version that explicitly uses audere. But why did you form it as nolite audere orbiculum.... delere instead of nolite audere delere orbiculum...?
Some small background. Years ago, I was told of someone making a usenet posting that contained latin translations of various computer-related phrases. This was one of the phrases. I never did find that posting (not that I looked too hard), but being that I'm somewhat interested in Latin, I decided to take a stab at some of these. This is the result of one of my efforts.
Of course I'm not saying that cookies are more likely to be logged than URLs. URLs are absolutely guaranteed to be logged. But if someone is operating a proxy or sniffing HTTP traffic for the purpose of hijacking sessions, then I also absolutely guarantee that the person is going to log cookies too, or he's an incompetent baboon who poses no threat to anyone.
The fact that my session information is never written to disk nothing to do with cookies, true, but it has a lot to do with this discussion. And that is whether or not mangled URIs do a better job of protecting privacy than cookies. And the answer to that is clearly "yes", because there is no way for an outside attacker to recover the session information.
Further, a person doesn't have to look at logs in order to get cookie values. Theoretically cookies can only be read by people who are at a compatible domain to the one who set the cookie. But that's hogwash. Go check some security archive some day, the number of methods that currently work in order to read the cookies of other sites is huge. And that's not even counting the attacks against the client computer to read his hard disk.
Now, your session hijacking attack is true. Someone who finds a (current -- sessions time out quickly when idle) session ID on our site can use that information to start browsing in that person's session. What can that person do, what information can that person find, by hijacking the session? Well, if he's got a credit card, he can purchase a new advertising campaign for this user. He can't purchase a new campaign on the legitimate user's card because we never store credit card numbers (anyone who does should be shot out of hand). So the user ends up getting a free ad campaign, courtesy of the hijacker. Shucks. He can certainly see what ad campaigns the user has that have already been booked. And so can see what that user is advertising. So what? It's advertising. The whole point is to get lots of people to know about it. This could be a problem if the user has booked a campaign for a special promotion in the future, and doesn't want people to know about it before the promotion starts. He couldn't change the user's password (or see it). He couldn't cancel any of the user's campaigns. He could get the user's email address for sure. And, yes, that's a problem. We don't have a solution for either of those problems. But it's certainly a better situation than if we were using cookies, in which case at least this much information would be available.
And Im curious about what "better checking" you're considering. I hope you aren't thinking about IP address verification. That doesn't work, because you end up blocking out every AOL user (people browsing through AOL potentially change IP from request to request, because of the mandatory proxies that AOL uses). We tried that for a while.
And I don't know why you believe that url rewriting makes it harder to use from a programming stand point. You write a library to access cookies or you download one. You write an apache content handler to rewrite urls. Both are extremely easy things, and once done you don't have to do it again. Have you ever written an apache module? It's very easy.
Regarding your last comment, there's only really one reason that we don't use purely relative paths: we're cheapskates. All of our absolute URIs are links into or out of our secure server (or attempts to change the session ID). Since SSL certificates are dependant on the host name, and we have a huge number of partners, each of which have their own domain name on our site, we didn't want to have to buy >2500 SSL certificates. So we bought one certificate, and every entry to or exit from SSL goes through a single domain name. That forces us to use absolute urls. Other than that, everything can be a relative URL. Personally, I find relative URLs much easier to work with than absolute URLs, because it makes it a whole lot easier to maintain the website.
Slashdot Mirror
Just a quick clairification here.
That "story" linked above wasn't written by any reportrer, hack or not. It's a press release from StatMarket and WebSideStory. Press releases are nothing more than marketing propaganda designed to financially aid the group that makes the press release. Generally, press releases are written by a company's marketing department.
It should come as no surprise to anyone that the statistics in that release are flawed. Someone who can competently produce statistical analyses is very unlikely to be employed in a marketing department; there are far more lucrative and fulfilling employment opportunities for statisticians in other areas.
I addressed all of your points already in this thread.
/after/ acceptance occurs.
/I/ receive when people use Linux. I don't need to know that it's Mrs. Marge Simpson, of 123 Evergreen Terrace to receive my benefit.
/possible/ to negotiate terms on the Linux kernel. But there is no single point of communication, so it would be difficult to do so. You'd have to contact every one of the hundreds (if not thousands) of contributors to the Linux kernel, and convince them all to participate. Or, at least, the contributors who have affected portions of the kernel that you're going to be using.
"negotiate" doesn't mean that there is a two-way discussion of terms. In its simplest form, and the form that is nearly always the case, there is an offer of terms from one party and an acceptance by the other. That is still "negotiation" in the legal sense.
Next, in nearly all contract situations, the two parties are not aware of each other. It's a one-way affair in which the accepting party is aware of the offering party, but not the reverse. The offering party only becomes aware of the accepting party
As far as receiving something of benefit, I have already addressed what benefit
It is certainly
As for agreement, the Linux authors collectively agree to the terms when they offer them to you. If they didn't agree, they wouldn't have offered those terms, now would they? You agree when you exercise one of the benefits of those terms that you couldn't've gotten in any other way: by redistributing the kernel.
Every agreement constitutes a (potentially valid) contract, even if that contract is verbal or even if it's implied.
And, yes, I'm talking about US law.
It depends on how weak microsoft gets, and how much time my other projects are demanding.
If microsoft gets so weak that there's no chance of it ever recovering, then I'll consider that goal to be achieved.
If there's something new that I need out of Linux, I'll probably keep working on it (I like my mini beowulf cluster, after all). Otherwise I might dust off that old OS that I was writing and abandoned when I started up with Linux.
It's not always possible (in fact it rarely is) to write a license that it simultaneously rigorous enough for a court and comprehensible enough for the average person. That's why a lot of modern licenses have commentaries at the beginning that attempt to explain the goals behind the license. The GPL is a good example of this. But the commentary is just that: it has no importance in legal proceedings except in that it speaks to the intentions of the parties.
You have to look at it the same way as a program and its users' guide. We programmers have little problem reading source code (even complex source code) and figuring out what's going on. But joe blow can't do that. Both of us benefit from the users' guide: joe blow so he can make sense of what he's seeing, and us so that we can figure out whether or not a particular behavior is a bug or if it's intentional in some strange way. But as far as the computer is concerned, the users' guide is meaningless. The code is the be all and end all of the system's function.
Secondly, in the context of licences intended to be used internationally I think that attempts to be clever with the legalese are misguided. Sure your obscure term of art wins you points in your home jurisdiction but elsewhere it may be interpreted completely differently - it may even have an established contrary meaning. And no, you can't just assume that foreign courts will accept any clauses you put in that forbid them from interpreting the contracts under their own laws.
That's certainly true. Unfortunately there isn't a whole lot of precedent about the validity of choice of jurisdiction clauses. English common law countries tend to obey them (and US courts seem to always do so). But I can't speak about European common law countries, Confucian law countries, or others.
But this whole issue about things happening internationally is really quite new. Before the computer age, international commercial agreements were nearly always exchange-of-goods, so there really wasn't any kind of licensing issue. There were certainly cases of a foreign manufacturer buying a production model of someone's invention, then copying it and producing it themselves in their own countries. And the few court proceedings in these matters were nearly always ineffective. But with the rate at which things are going, we can expect to start seeing a whole lot more cases discussing international licensing.
Thirdly, you're simply wrong in your assertion "The next thing is that all licenses are based in contract law. There is no room in copyright law for granting permissions beyond those explicitly enumerated (and irrevocable) in copyright law."
The one thing that copyright law does give the copyright holder is the right to give people permission to do the activities that are otherwise prohibited by copyright law.
You're thinking about contract law. Copyright law says "this thing is owned by the copyright holder, and he can prevent anyone he wants from getting access to it" (basically). The only variant that exists in copyright law is the concept of "public domain": a person who would otherwise hold copyright over something can put that thing into the public domain, in which case no one has differential rights to that thing. Contract law says "different parties have different rights, resources, and privileges, and they can negotiate exchanges of those rights, resources, and privileges under these rules." Copyright grants a privilege to one party that is excluded from other parties. Contract law influences how the copyright holder can grant his priveleges to other people.
It depends on the license. For the MS EULA, you are certainly correct. But software written by developers that expect/invite/encourage participation in the development process should have a license written for developers. Of course lawyers and judges will be one audience for the license, but they will not be the primary audience.
/proc filesystem, assorted bugfixes, and the PCI WDT support), allow me to explain the consideration that you have granted back to me by using Linux. My principle motivation in being involved in Linux is to weaken Microsoft. By using Linux, you are not using Windows on that same box at the same time. Therefore, you, by using Linux, are acting to weaken Microsoft. So by using Linux, you are volunteering your time and effort in support of one of my goals. That's the consideration that you give me.
Why would you ever write a license that you don't want to be enforceable? If you want it to be enforceable, then it has to be (principally) comprehensible in court. As to determining whether or not a contract is clear, the court will look at the language itself, not defer to the statements of the defendant or plaintiff. The only exception is when both defendant and plaintiff agree on the interpretation of a particular clause, in which case the court will take that interpretation rather than the interpretation that the court might find on its own. But in such a case, I think you'd agree that the license is sufficiently clear.
Here's a sample license: "You may freely copy, distribute, modify, translate, or otherwise transmit and transform this software without restriction." Just how does this qualify as a contract? Where is the agreement? Where is the consideration? Are you saying that the above license is not valid?
Agreements between parties fall exclusively under the jurisdiction of contract law. The parties may, in fact, act under an agreement that is an invalid contract, but it is still under the jurisdiction of contract law.
More directly, let's look at your sample license. Presumably, the person offering the license possesses a copyright in the software. So the holder is granting certain distribution and modification privileges. That's the consideration that he's giving. The license doesn't explicitly enumerate consideration that the recipient is granting back to the holder, but (and this is an important principle in contract law) since the holder is the party that offered the contract, it is presumed that the holder is gaining an automatic intangible concession in return (such as the pride of knowing that other people want to use his software). The important thing is that the person who offers terms is presumed to agree to the terms; if he didn't agree to them, he wouldn't've offered them in the first place.
Then, if the recipient of the software actually does exercise one of the privileges granted to him in the license, then he has also agreed to the license (contract). This is another important concept in contract law: implied consent. If one party exercises a privilege granted only under a contract, then that party has consented to that contract. This concept actually doesn't exist in the text of the legislation that forms contract law. This exists in a more important place: legal precedent.
So the example license that you present has offer, has exchange of consideration, and has consent. All three of the keystones that are required for a contract to be valid.
What exchange? In the case of the Linux (as an example) I have given nothing to Linus Torvalds. No money. No pledges of royalties. No promises that I will ever contribute anything back to the project.
I'm glad that you brought up Linux. Linux uses a fragmented intellectual property model, in which the entire body is covered by a single license, but the ownership of the individual pieces are retained by the original authors. So when you use Linux, you are entering into an agreement with each of the separable authors of the kernel.
As one of the authors of the Linux kernel (interval timers, original
I can say for certainty that the same consideration applies to a large number of the people involved in the Linux kernel, but I will neither name names, nor will I attempt to enumerate all the considerations that are gained by all the individual contributors to Linux (primarily because I don't know them all).
I'm not granting him any permissions or benefits. Heck, Linus and I have never even met, so how can we possibly exchange anything!
If physical meeting were a requirement for a binding contract, then the only commerce that would exist would be face-to-face barter. Mail order, internet sales, telephone solicitation, early book sales (even in person), credit cards, checks, ATM cards, and even paper currency all exist only because of nonlocal agreements to contracts.
Contracts are never "imposed." They must be agreed to voluntarily by both parties.
That's only sort of true. As the holder of a copyright, I can offer a contract without allowing negotiation. True, the contract doesn't bind unless the other party agrees, but in that case the other party doesn't get my software, either. So I have effectively imposed my contract on all people who want to use my software.
This is the central argument behind the (many) suits over the years asserting that Microsoft has illegally leveraged its monopoly power to impose contracts.
You're a bit off target here with some facts.
/and/ the law, so an already dense dialect is made nearly incomprehensible.
/must/ use contract law. You have no choice. That's the primary purpose of contract law: to provide a framework under which two parties can clearly enumerate an exchange of permissions or other benefits.
/as contracts/ are not an invention of the proprietary software industry. Software licenses /in their entirety/ are an invention of the proprietary software industry. Specifically, an invention of Microsoft. Before Billy went on a rampage about people "stealing" his BASIC interpreter in the early 70s, there were no software licenses at all. Software was freely distributed or it was custom coded under contract for a specific client's internal use. That was software. There was no (serious) retail software at all. Then Billy got upset at those pesky Altair users and went off on a tear. After years of work, the courts started upholding software copyrights, and the entire retail software industry was born.
First off, licenses aren't written for end users. Yes, they're purportedly intended to inform a user of their privileges, but the true audience of a license is a judge and a pack of lawyers. The important thing for a license isn't that it's clear to joe blow, but that it's clear in court: a contract that's clear to joe blow is meaningless if a court can't make heads or tails of it. Confusing terminology in contracts is the result of two problems. First, colloquial language is very subjective and very slippery, and so legal documents have to be written in a specialized dialect of English that has arisen over centuries of effort. It's the same problem with programming languages: we can't have a truly natural language programming language because it's too imprecise. But just as engineers have an easy time reading and understanding source code, so do lawyers have an easy time reading legalese. The second problem is that most lawyers have a very poor mastery of both English
The next thing is that all licenses are based in contract law. There is no room in copyright law for granting permissions beyond those explicitly enumerated (and irrevocable) in copyright law. If you want to grant extra permissions, or revoke certain permissions, then you
Next, you have to consider the purpose behind an OSS license. One person may have a different purpose from you. To me, the term OSS means "you can read my source code, and you can contribute changes back to me". That's it. It doesn't say anything about whether or not someone can use the source code. It doesn't say anything about whether or not someone can produce derivative works. Sure, GPL talks about those things, but that's because GPL goes farther than the simple concept of OSS. The same goes for other OSS licenses: they will almost always go beyond the simple concept of OSS, building on top of the concept in order to further the purposes that the author has in offering the software as OSS in the first place.
As an example, someone might be making their software OSS for the purpose of crushing Windows. It shouldn't be too surprising to see that their license contains a clause prohibiting the porting of the software to any Microsoft operating system, either natively or under an emulator. Does OSS say anything about that? Nope. Does GPL say anything about that? Nope. But that author wants to crush Windows, so he's not very well going to allow his software to be used under Windows, now is he? He's got a purpose, and his license reflects that purpose.
Then there's the last point. Software licenses
The only thing that software copyrights do is to allow the author of software to restrict his software's distribution. Once that's in place, the author can then impose a license (read: contract) on the user for the software. Without software copyrights, the licenses would be meaningless, because a user could just say "naw, I'm not gonna agree to the license, so it doesn't bind me, but I'm gonna use the software anyway because you can't prevent me from getting a copy of it."
Erm. Maybe I'm being a little bit antiquated, but it isn't necessary to have TiVo or Replay or anything like that in order to catch shows that are in bad timeslots. I have this amazing device called a VCR. It does this just fine.
Ah, the Altos. My first computer was an Altos 5-5D. Same story as you, pretty much. Got it with CP/M (on 8" floppies). Had a massive 5MB winchester disk. And I still have my 8" Zork I floppy. This old Altos didn't have a built-in monitor or anything: it had 3 serial ports to connect to terminals. I had an Adds Viewpoint and a TVI hooked up to it. I even got on the MP/M beta test.
God, I loved the Kaypro 10. My first professional programming gig was writing a BBS on the Kaypro 10, in assembly, with a Hayes Smartmodem (an actual Hayes Smartmodem, not a clone). That was a fun job. *sigh* Memories.
Gyroscopic effects are proportional to the rotational speed of the gyro, the mass of the gyro, and the diameter of the gyro. This thing has a tiny diameter, tiny mass, and huge speed. I don't think there would be much effect.
Well, I was just talking about the mass that you have to invest in the turbine rotor in order for it to remain structurally sound as a function of size. That's why I said that the efficiency /potentially/ increases with a reduction of size. The mass of the rotor has a major influence on the amount of energy that can be extracted from the incoming airstream.
Why does the power output decrease by the cube? I understand why friction decreases by the square (actually, I suspect that friction decreases more slowly than that, because surface imperfections become more important than at normal scales).
Even better is the fact that the diffusion speed of pure H2 at standard temperature and pressure is pretty damned fast. Even if you had a catastrophic failure of the tank, your ignition source would have to be present at the time of the failure of really soon thereafter (we're talking miliseconds here) in order to ignite the H2.
There's efficiency and there's power output.
The problem with fuel cells is that they're BIG for the power that they produce. A turbine is small for the power that it produces. So this dime-sized turbine supposedly generates 20W of power. How big of a fuel cell do you need in order to get 20W out of hydrogen?
I don't know the numbers myself. It could very well be that a fuel cell's power-to-volume ratio is good enough that you could still manage to power a laptop off of one. But since it's not as good as a turbine, that means that the turbine-powered "battery" pack would have more space available for fuel.
Even better, a turbine's efficiency (potentially) increases as you get it smaller. The major stumbling block for turbines is making the fan strong enough to handle the huge stresses that are put on it by the awesome speeds at which it rotates. But as a turbine gets smaller, its strength increases: mass decreases as the cube, but the various strength measurements (torsional, tensile, etc.) decrease by the square of the size. Silicon is far too weak for full-sized turbines, but (apparently) it works just fine for these submini turbines.
Yes, as an undergraduate. By that point, I had already been programming for 10 years (I started programming when I was 12, in assembly, on an Altos 5-5D "minicomputer").
There are two things that you apparently don't realize.
The first is that academia is overwhelmed by politics and jockeying for position. This is most prevalent among graduate students (who are struggling to attract influential professors as research sponsors) and among associate professors (whor are struggling to advance along the tenure track, which has progressively fewer openings the farther you travel). In academia, it's not the project that matters, but how you're able to leverage that project for personal advancement. Yes, the corporate world has politics as well, but aside from a few rare companies, corporate politics are babies struggling over teddybears in the crib compared to academic politics.
The other thing that you don't realize is that the nature of user interface design is that it is subtle. You need to come up with mechanisms that help the user out without the user being made aware that they're being helped out. That's the whole game. So if you come up with a successful mechanism, that mechanism is, by the very nature of the game, subtle.
Here are the details:
When I came on board, vertices were selected by clicking the mouse within 20 pixels of the vertice's location. When you have a lot of vertices on the screen, these regions overlap, and the specific vertex that gets selected when you click in an overlap is unpredictable (it depends on the ordering of the vertices in the data structures). You could even end up selecting a vertex that was scrolled out of the visible area of the layout.
My change was to define "pick regions". These regions were dynamic, depending on your view, the vertex density, etc. The way it worked was that I iterated over the visible vertexes (we had a data structure that made this easy, and also let us easily find the vertices closest to a particular x,y coordinate: that was another research project in itself). For any click location, I found the eight closest vertices. For each vertex, I calculated its weighted distance from the click location (I used distance-squared, rather than distance, for reasons that will become apparent). I found the vertex that had the smallest distance, and then I looked for the vertex with the second smallest distance. That second vertex's distance had to be at least 35% larger (that was a tunable parameter, and my experiments showed that 35% number to be the best) than the first vertex's distance in order for the first vertex to be selected. If that test failed, then no vertex was selected. All of these calculations were done using screen coordinates (pixels) rather than routing coordinates, so that the view parameters would get incorporated into the calculation. The net result of this is that each vertex was surrounded by a lumpy region that was "owned" by that vertex. Any click in that region would select the owning vertex. The regions were lumpy because their shape in any direction would depend on the neighboring vertices. But by using a distance-squared metric, the lumpiness was somewhat smoothed out, thereby avoiding long and counterintuitive peninsulae spreading through the layout (and spared me the cost of a square root calculation). The overshoot requirement ensured that there were gaps between every pick region, where a click wouldn't select any vertex. These gaps were about 16% of the vertex density (sqrt(1.35) ~= 1.16). So they were small enough that it would be hard to click in a gap, but large enough that any click that fell outside of a gap was unambiguously associated with the same vertex for both the computer and the user.
The change had two results: 1) when the user successfully selected a vertex, it was always the same vertex that the user intended, and 2) when the user was being ambiguous, no vertex would get selected. The second possibility also existed in the previous mechanism, so it wasn't noticeable. And the first possibility meant that the users never ended up selecting the wrong vertex.
So, yes, the change was subtle. It wasn't subtle to someone looking at the code, but at that time the UI was 5MB of dense X11 and Motif code, so the researchers never ventured into it. We also had a standing policy that no one was to touch anyone else's module, and if anyone needed UI work done, they were to come talk to me to code it. This all means that they never even looked into the code until after my bombshell was dropped.
Yes, actually, GIMP is a deployment tool. We don't use that nasty gui that GIMP has.
Our website, if you had browsed around a bit to see, has an ad banner creator on it. That creator is a cgi front end to a number of scheme scripts that I and a contractor wrote, that run in GIMP's script-fu plugin.
So, yes: GIMP is a deployed part of our website.
No, "closed-source closed-source" was a pyto.
Our website designer doesn't use macromedia software to generate web pages. But he does play around a lot with flash animations. Has a lot of fun with them. And there's some website out there that gives a lot of tips and info on scripting in flash, which he spends a lot of time browsing. He told me the URL once, but I don't have it handy right now. Anyway, the point is that it's not very surprising that he recycled an existing name for his stuff. And look at that MM_openBrWindow() function. It's not exactly a difficult function, now is it?
When I was in college, I worked on a research project for surface routing of multichipmodules. I wasn't actually one of the researchers, I was just there to code the user interface that went on top of the actual research project.
:(
A major part of the user interface was clicking on vertices in the routing layout and dragging them around. When you have 10,000 vertices visible in the window, this can get obnoxious if you don't have a good and unambiguous selection mechanism.
Unfortunately, when I came on board, we had a bad and ambiguous selection mechanism.
We had weekly meetings of all the coders (that includes all the grad students who were doing the actual research) and we'd discuss new ideas. I'd seen a whole lot of ideas get passed around at previous meetings, and no matter the idea, it was always met with grave resistance. People wanted feasability studies, analyses, reports, blah blah blah. It was nasty. Far worse than any company I've worked for since, but that was academia, so it's not surprising.
So before presenting my new interface, I coded it up (took me 4 hours) and put it into the standard build. This was on a Tuesday. So for 3 days (Wednesday, Thursday, and part of Friday) people were using my new interface without realising it. I noticed a distinct change in the character of the conversations going on. But the change was subtle enough that no one immediately came to me to discuss it. Previous to my change, there was always a lot of grumbling and cursing whenever someone selected the wrong vertex, and all those stopped suddenly when I installed the new interface.
Friday came and I presented my new interface idea. People were very down on it. They wanted studies. They wanted an analysis of the time it would take to code it. They wanted references to existing peer reviewed user interface studies. Blah blah blah. I knew that would happen. So then I dropped the bombshell. I explained that I already coded it, it took 4 hours, and they've all been using it since Wednesday morning. The expressions on their faces and the stunned silence were precious. Apparently they were going over their use of the UI in their heads over the past few days, because shortly the room erupted in very complimentary discussion all around.
Of course I was told not to do that again, but I considered it an unqualified success. Not only did I get my new mechanism into the project, not only was the new mechanism successful, but I also managed to show everyone how damned bureaucratic they were being, and how much damage they were doing to the productivity of the project.
It was beautiful.
The point of this story is that a successful feature depends much more on the end result, not on the process. The function is far more important than the process. Sure, the process is important, but when you find yourself sacrificing functionality for the sake of process, you've just lost the war. Clear coding is nice. An architecture document is nice (I agree that a well thought out architecture is essential, but that is different from a well thought out written architecture). But they are both pale shadows when weighed against the final product.
First, I'm going to assume that what you're talking about is projects that use OSS, rather than projects that generate OSS.
At AdAce (shameless plug), I pressured my CEO to let me build the website on top of OSS tools and systems. It was a relatively easy sell at the time, because I (the CSO) and the CTO were both OSS enthusiasts, and we got a lot of respect from our CEO for our technical expertise. This wasn't one of those micromanaging CEOs that some companies have.
Now I'm both CTO and CSO, and I'm quite happy with the result of using OSS wherever possible.
The website linked above is built on top of Apache, Linux, GIMP, MySQL, mod_ssl, and smail. We use gcc and all the other g-tools to build the beast. (We wanted to use PNG for all our graphics, but IE's support for PNG is just too horrible.)
Our system has only two pieces using closed-source closed-source software.
The first is the library provided to us by our credit card processor in order to communicate with their systems (signio, now bought by verisign). But that library was built using ssleay, and knowing that I was able to patch up the binary library to avoid certain SSL attacks against us. (thank you, ssleay!)
The second piece is our ad servers (realmedia). We chose closed source ad servers because we needed a certain set of features, and the OSS ad servers out there are too far behind in that feature set for us to use them. We could have added the features we need, but that would've but a huge engineering burden on us that we couldn't afford at the time. Now that we've come far enough, we're evaluating the current OSS ad servers to see which one we're going to adopt, and add the features that we need (and, of course, commit those new features back to the project).
The selling points that we used to push the OSS point are:
1) The security of an OSS project is superior to the security of a closed source project. This is because either the security holes are found by other people and patches are submitted back to the project, or I (whose duty it is to analyze our security) can find the problems and fix them. While with a closed source project, this is all dependent on the very busy engineers at the software's vendor, who will always prioritize security below where we would want it prioritized (we want it to be the #1 priority). It's so nice to be free of worrying over priority conflicts between us and a software vendor.
2) The stability is superior for the same reason.
3) Licensing fees are trivial. For most OSS projects, licensing is a voluntary donation to the support organization, and the size of that donation is up to us to determine. For other OSS projects, licensing is free. The only real exception is MySQL, which has specified certain donation levels which, nevertheless, are far lower than competing database software's license fees.
4) When (not if) the vendor of a closed source project moves on to other projects, and abandons the software that we're using, we're screwed. But if we use OSS, then we've got the source code, and can continue to support ourselves. Plus, when that happens, we've developed enough internal expertise with the software that it's not too difficult for us to support ourselves.
Apache, in particular, has been a huge boon to us. It's so easy to write modules for Apache that we've got our server packed to the gills with custom modules to perform certain session management and dynamic content tasks for us. These have improved our website's speed and maintainability by a huge margin. (some of these modules have progressed far enough that we're nearly ready to contribute them back to the Apache project.)
In hindsight, we made one big mistake with our OSS work. That is, whenever we brought some new OSS project on board, we would assign it to one engineer, and that engineer was to become our expert on that system. We spread this load around so that no one engineer would be overburdened. But what we should have done (in addition) was to have a "debriefing" a couple weeks after the assignment, so that that engineer could brain-dump a portion of his expertise into the rest of us. As it happened, we had engineers leave us (which is the usual case in engineering) who were the only people with expertise in a particular piece of the puzzle. And when that happened, we were left scrambling to redevelop the lost expertise. It all turned out ok, but it might not have.
These days, as a large result of using OSS wherever possible, we're in a very good position. Nearly all of our competing ad networks have abandoned the market for greener pastures, and that includes every ad network that's bigger than us except for 24/7 and doubleclick. The other big guys have switched to licensing their proprietary ad servers to other ad networks. As a direct result of our adoption of OSS, our total monthly technology costs are trivial, and we can survive comfortably on a truly tiny number of sales in a month. Having leaned heavily on OSS software, we were also able to focus a lot of our engineering on automating the administration of our system to a large a degree, so our administrative burdens are also tiny. This is letting us ride out this deep depression in our industry without worries, and when things turn around we'll be in a very enviable position.
The only downside to OSS is that there are a large number of licenses to read and discuss with our legal department. This number is, of course, similar to the number of licenses that we would be under if each individual portion of our website used equivalent closed source projects. However, closed source projects tend to bundle multiple pieces together under a single license, so we would actually have fewer pieces (and hence fewer licenses) if we used closed source. What's worse, many OSS projects use licenses that are superficially the same, but contain modifications that are specific to that project. So, though it's tempting to read the opening clauses and conclude that the license is the same as this other license that we already analyzed, it's foolish to do so.
But the bundling phenomenon of closed source projects is actually a disadvantage. Since no closed-source project satisfies all our needs, we would definately need multiple. And if different closed-source pieces overlap in their bundling, then either we have to reject a piece that we'd like to use, or we'd have to find a way to disable the pieces that we don't want to use. That's always a pain.
I've always loved the back references in The Tick comic and cartoon. Both references to previous episodes (like "CHA" carved into the moon) and cultural references (the opening shot of the diner scene in the first issue of the comic). Do you intend to follow in that "tradition" in the live-action series?
I know you get asked this with every Tick project that you do, but here it is again: are you guys open to the idea of redoing The Night of the Million Zillion Ninjas for the live action series? That story line was always the cornerstone of The Tick in my mind. I think it would work well in the live action. And since, in the previous interview, you mentioned that you might bring Paul the Samurai into the live action series, NofMZN seems like the perfect way to do it.
Printers and shares now remember the passwords.
Umm. That's a bad thing, not a good thing. Do you know if that can be turned off?
I agree wholeheartedly.
And this is one of the points that I brought up in my email to W3C: any "RAND" license is automatically going to be unreasonable to open source people. So if the W3C implements the policy, and then later produces a RAND standard, then one of two things will happen:
1) the standard covers some method that no one really cares about, and so it is ignored, or
2) the standard covers some method that people do care about, in which case open source people will develop a competing RF standard that will (given a few years) utterly dominate the niche. The W3C's RAND standard will then be ignored.
In either case, the W3C's effort in developing the RAND standard is completely wasted. The only one who receives any benefit from such a standard is the patent holder. W3C loses. Users lose. Developers lose. Patent licensees lose.
So if any RAND-based standard is a waste of time, why have a RAND policy in the first place?
And this doesn't even get into all the complaints I had about how their RAND policy completely fails to fulfill its goal: ensuring that if a W3C recommendation is encumbered, that it learns about it before acceptance of the recommendation.
... I'll have to take the slashdotter's word...
:)
.... delere instead of nolite audere delere orbiculum...?
I'm innocent, I tell you! I've never slashdotted anyone. . . Well, perhaps I've contributed to someone being slashdotted.
The rigidium vs. rigidum difference could easily be my error. I'm known for using -ium when -um is correct. A common mistake on my part.
I think I'll take your expert's advice and switch to nolite
I like your version that explicitly uses audere. But why did you form it as nolite audere orbiculum
Some small background. Years ago, I was told of someone making a usenet posting that contained latin translations of various computer-related phrases. This was one of the phrases. I never did find that posting (not that I looked too hard), but being that I'm somewhat interested in Latin, I decided to take a stab at some of these. This is the result of one of my efforts.
Of course I'm not saying that cookies are more likely to be logged than URLs. URLs are absolutely guaranteed to be logged. But if someone is operating a proxy or sniffing HTTP traffic for the purpose of hijacking sessions, then I also absolutely guarantee that the person is going to log cookies too, or he's an incompetent baboon who poses no threat to anyone.
The fact that my session information is never written to disk nothing to do with cookies, true, but it has a lot to do with this discussion. And that is whether or not mangled URIs do a better job of protecting privacy than cookies. And the answer to that is clearly "yes", because there is no way for an outside attacker to recover the session information.
Further, a person doesn't have to look at logs in order to get cookie values. Theoretically cookies can only be read by people who are at a compatible domain to the one who set the cookie. But that's hogwash. Go check some security archive some day, the number of methods that currently work in order to read the cookies of other sites is huge. And that's not even counting the attacks against the client computer to read his hard disk.
Now, your session hijacking attack is true. Someone who finds a (current -- sessions time out quickly when idle) session ID on our site can use that information to start browsing in that person's session. What can that person do, what information can that person find, by hijacking the session? Well, if he's got a credit card, he can purchase a new advertising campaign for this user. He can't purchase a new campaign on the legitimate user's card because we never store credit card numbers (anyone who does should be shot out of hand). So the user ends up getting a free ad campaign, courtesy of the hijacker. Shucks. He can certainly see what ad campaigns the user has that have already been booked. And so can see what that user is advertising. So what? It's advertising. The whole point is to get lots of people to know about it. This could be a problem if the user has booked a campaign for a special promotion in the future, and doesn't want people to know about it before the promotion starts. He couldn't change the user's password (or see it). He couldn't cancel any of the user's campaigns. He could get the user's email address for sure. And, yes, that's a problem. We don't have a solution for either of those problems. But it's certainly a better situation than if we were using cookies, in which case at least this much information would be available.
And Im curious about what "better checking" you're considering. I hope you aren't thinking about IP address verification. That doesn't work, because you end up blocking out every AOL user (people browsing through AOL potentially change IP from request to request, because of the mandatory proxies that AOL uses). We tried that for a while.
And I don't know why you believe that url rewriting makes it harder to use from a programming stand point. You write a library to access cookies or you download one. You write an apache content handler to rewrite urls. Both are extremely easy things, and once done you don't have to do it again. Have you ever written an apache module? It's very easy.
Regarding your last comment, there's only really one reason that we don't use purely relative paths: we're cheapskates. All of our absolute URIs are links into or out of our secure server (or attempts to change the session ID). Since SSL certificates are dependant on the host name, and we have a huge number of partners, each of which have their own domain name on our site, we didn't want to have to buy >2500 SSL certificates. So we bought one certificate, and every entry to or exit from SSL goes through a single domain name. That forces us to use absolute urls. Other than that, everything can be a relative URL. Personally, I find relative URLs much easier to work with than absolute URLs, because it makes it a whole lot easier to maintain the website.