Yep, there are a lot of flashing lights and beeps sending code in the computer world. I still hear phones using "... -- ..." to indicate an incoming SMS.

You're welcome. So you never licensed? It's not too late to join the fun.

OpenSSL has first-to-market advantage, and anyone who hasn't evaluated the quality differences will choose the simpler license. Plus there are other alternatives, like Amazon's new SSL-in-5000-lines which is also gift-licensed.

The time for OpenSSL to dual-license was when it was the only available alternative to entirely proprietary implementations. That might indeed have funded a quality improvement.

I don't know a thing about the quality of GnuTLS or the Amazon thing. I've seen enough of the insides of OpenSSL to know it's not pretty, but am not a crypto guy and this don't work on it.

Maintaining FIPS compliance did not make anything easier. It's essentially a prohibition on bug repair, as you have to recertify afterward. But the people who wanted FIPS were the only ones who were actually paying for someone to work on OpenSSL.

I don't think any of the other Free Software projects ever tried to be FIPS certified.

If you are one of the infringed parties, I'd be happy to talk with you about what your options are. bruce at perens dot com or +1 510-4PERENS (I'm not there today, but it will take a message). I am not a lawyer but I work with the good ones and can bring them into the conversation if necessary.

As a community we've managed to almost completely ignore that because of their use of dual-licensing, MySQL made 1.1 Billion dollars after 9 years in business, and that for a database that was written by one person, and the code base remained available under the GPL.

IMO, 1.1 Billion dollars is pretty damn impressive. Especially if you get paid that to make Free Software. Heck, sign me up!

Oracle was a bad actor, and Monty is now leading further development of that same code base under the GPL. But it did not have to be that way.

How do you prove damages or have the right to settle violations if you don't have copyright?

If you have been doing enough work to justify getting paid for the software, you have an ample amount of your own copyrighted work to base your claim upon. If you haven't done that much work, what are you suing for?

You can also get a grant of the right to sue from your contributors. You can include in the agreement how you will apportion damages: for example you could take the ratio of your lines of modified code checked in vs. that of contributed code checked in, and give that portion of damages to FSF.

I have the front panel of Pixar's VAX 780, which was used to render the Genesis Effect scene using the old Reyes renderer. I think we only started calling it Renderman when it was put up for public sale.

As it should be. You're welcome.

I have several 'huh' reactions to this.

First: Apple's changes to GCC were released, but mostly lived in a separate branch in GCC's svn. A lot of them were never merged into the mainline. The GCC code has subsequently changed enough that applying them is no easier than completely rewriting them (source: a colleague at CodeSourcey who is working on doing exactly this).

Second: Apple is one of the largest contributors to LLVM and Clang (BSD licensed) and has been since the project was quite small - they hired the lead developer of LLVM to use LLVM in their graphics stack and started the Clang project to replace GCC with something that was useable for refactoring tools, syntax highlighting, and so on.

Third: I guess you're talking about the PS2, but optimisations for the Cell PPU are not really very useful when encouraging people to run code on the SPUs (the PPU was pretty underpowered) and Sony did not use Apple's GCC branch. For the PS4, their toolchain is entirely LLVM based (and their OS is FreeBSD based).

Not a great example. WebKit was originally released as a bunch of code dumps that were basically impossible to merge with upstream KHTML. It was the promise of outside developer interest (after many years of developing it with no community involvement), not the license, that caused them to release it as a proper open source project (i.e. with a public revision control system). Oh, and the Apple-original bits of WebKit (i.e. those not derived from KHTML) are BSD licensed...

Excluding the trait that your comparing for. The skin colour does not strongly correlate with enough other genetic traits to be able to identify a population.

No, the GPL does absolutely nothing to prevent this problem. Well, unless the problem is having contributors to your project.

If people are building something for distribution, they will often avoid the GPL'd project entirely. If they're building something for internal use, then they will either avoid the GPL'd project, or they will keep their changes private in exactly the same way (and often for longer because they're worried that if they upstream stuff then they'll be asked for a legal audit of everything or, often, they're linking against something proprietary with a EULA that prohibits linking with GPL'd code and don't want their supplier to know that they're in violation of this license).

It's far harder to start off not participating in the community and then join later if you use GPL'd code than BSDL'd code, and that's a route that I've seen a lot of companies following. Their choices aren't BSDL or GPL, they're BSDL or proprietary. If they go with a proprietary solution, then their only option if they want to become involved with an open source ecosystem is to buy their supplier. If they go with a BSDL project, then they can join in the community later.

If they're not the first to get their changes in, then they end up with a lot of pain on their next merge, which generally encourages them to become a bit better at upstreaming stuff early.

It depends a lot on the group at Google. I turned down a job at Google where most of my interviewers were at least late '30s and a couple late '40s, but I now collaborate with a couple of teams with similar demographics. Occasionally I go and visit and walk past groups that have no one over 30. Partly it's down to the kinds of project that appeal to different age groups - there's a lot that Google does that becomes a lot less interesting as you get older.

Some old guys do. Some get fixated on how things used to work a decade or more ago and insist that everything new is rubbish. The trick is to only hire the former...

Because people change over time. I've met a lot of people where I'd make very different decisions about whether to hire them over a period of 7 years. Even ignoring the maturity aspect, both the skills of the person and the skills needed by the company change a lot over that time. Google had a tiny LLVM team 7 years ago, but now is one of the largest employers of LLVM developers. They've gone on various other hiring sprees for different skills too.