BSD Licensing Versus GPL

> To put it another way, if RMS were evangelizing about the BSD license, the GNU tool-chain were licensed under BSD, and Linux the same, growth would still be pretty much what it is.

Maybe you should ask the Wine project what they think about that.

>Maybe you should ask the Wine project what they think about that.

You don't think the people doing Wine would have started the project if there were no GPL?

I'm not so sure that BSD-style licenses inihibit growth. As way of anecdotal evidence, I offer: the Apache, Tomcat, and Geronimo.

The Apache License is very similar in style to the BSD-style license. And that doesn't seem to have hurt the propagation and adoption of Apache.

Just my $0.02 - take it for what it's worth.

>>Maybe you should ask the Wine project what they think about that. > > You don't think the people doing Wine would have started the project if there were no GPL?

Wine switched to the LGPL later in the game (from a BSD-like permissive license) as they got fed up with the growth issues stemming from the destructive forks (relicensed forks). They claim development sped up significantly after doing it. It's basically a case study in how the GPL/LGPL promote growth by preventing self-destructive behavior of the market.

Linus also was recently quoted in an interview saying that the GPL.2 boiled down to "give the code back", something that the BSD license doesn't do.

He's also said that if he had known about BSD he wouldn't have started Linux, but I'm not sure that had anything what so ever to do with the license.

All that said, let's turn it around and look at it from the other side:

Microsoft _LOVES_ the BSD license.

If my greatest nemesis says, "Please, use this. We have no problem with you using this", that is the one thing I am not going to do. Or if I do, I will first find out what they like about it, and see if I can do without that which benefits my nemesis.

The "benefit" of the BSD license is that the code is less restricted in the "upstream" direction. It can be re-used without attribution in a binary-only distribution. Only the source code must retain the BSD license in comments.

So can F/OSS projects and communities live without that little bit more freedom, which those who would destroy those same F/OSS communities love so much?

"Those that give up essential Liberty for a little temporary safety, deserve neither." But is redistribution of code without attribution an essential Liberty?

>Wine switched to the LGPL later in the game (from a BSD-like permissive license) as they got fed up with the growth issues stemming from the destructive forks (relicensed forks)

So, the BSD license didn't keep anybody from developing WINE. Developers who were working on it decided to switch to something else.

Sounds reasonable to me, but I fail to see how it supports a hypothesis that BSD inhibits growth any more than the article can support a hypothesis that GPL inhibits growth.

woa, these threads do wander! How about we try a different perspective: most FOSS licenses (there are so many OSI licenses I dasn't say "all") support growth and creativity a meelyun times more than closed, proprietary licenses. The article itself is just a muddy, feeble justification of the 'businesses really really want to lock up FOSS code and maybe we should let them' school of thought.

TC -

Absolutely. The critical element : free or not free.

The flavors of free are far less (not un) important.

> Sounds reasonable to me, but I fail to see how it supports a hypothesis that BSD inhibits growth any more than the article can support a hypothesis that GPL inhibits growth.

As I said, destructive forks (relicensed forks). Can you not see why destructive forks hinder progress?

It slowed Wine down, and it slowed XFree86 down.

In Wine's case, to move forward out of destructive fork territory, they relicensed LGPL. In XFree86's case, the market eventually died and the destructive forks went away.

I don't know anything about destructive forks, having never seen one. I seem to recall the ability to fork being a strength of free software. In fact, your mention of XFree86 is curious. The fork of X.org was not very good for the XFree86 project, but it certainly was good for the state of X on the Intel (ish) architecture and for Linux. Or, for that matter, the fork of Joomla from Mambo. TigerCRM from SugarCRM.

Dino, he's not talking about all forks - just the ones where someone forks the project under a non-free license. You know, like Apple does with FreeBSD.

>just the ones where someone forks the project under a non-free license.

Yeah, I know.

But those are hardly destructive. They leave the original project in place. What they really are is irksome. People who are serious about freedom should understand that freedom allows people to irk you. The only way to prevent being irked is to tighten down the screws.

> But those are hardly destructive. They leave the original project in place.

The problem is that they compete /against/ the Free version. This means the Free version is having to deal with developer headhunting, anti-competitive practices, etc. and when a destructive fork fails, all the effort that went into it is usually lost. Splitting the workforce and letting one half of its progress whither and die, as happened many times with XFree86 for example (AccelX, MetroX, etc.), hasn't proven to be a very efficient way to write Free Software. :)

swbrown -

That darned freedom. So annoying.

Seriously, though, forks are both good and bad.

As noted before, the X.org fork was bad for XFree86, but good for the rest of us. The real danger comes when a free project simply isn't good enough to compete.

> Seriously, though, forks are both good and bad.

Destructive (relicensed) forks are pretty much always bad. Can you think of a destructive fork that turned out well for the Free Software version? I can't.

>Can you think of a destructive fork that turned out well for the Free Software version?

Given that I don't believe there is such a thing as a "destructive fork", the answer would have to be no.

> Given that I don't believe there is such a thing as a "destructive fork", the answer would have to be no.

You're free to pretend the term means something else, but the question still stands: can you think of a /relicensed/ fork that turned out well for the Free Software version?

To avoid having to argue pointless topics like semantics again, here are some useless arguments that avoid answering the question in advance:

1) Argue semantics with something like "Well, Apple's Darwin is Free Software, and so was FreeBSD, so they're both the Free Software version".

2) Argue misdirection with something like "Well, Konqueror was GPL, but by publishing changes as part of a huge blob with no comments, it was effectively a 'destructive' fork too by your standards".

3) Argue the wrong question with something like "Well, x.org and XFree86 are effectively related by a relicensed fork, and the GPL-compatible version is doing great".

swbrown -

Well gosh -

And I suppose Rainy Days and Mondays never will get you down if you

a) define Rainy Days as only those days on which it rained for 24 consecutive hours,

b) raining means raining sufficiently hard that you would get thoroughly soaked going from the house to the car without some form of rain gear,

c) that your car must be outside in the driveway, and the driveway must be a "normal" driveway, not some "super" driveway,

d) that Mondays include regular "I must get up and go to work" Mondays, not holidays, vacations, working-from-home, or boss is out of town on a business trip, or YOU are out of town on a business trip Mondays.

e) cannot include Mondays after a Friday-off 3 day weekend because the glow from the extra off will skew your results,

f) "down" must be sufficiently down to make the entire day miserable,

g) but clinical depression cannot be included because, well, you're always down, right?

h) Taking your meds religiously is not sufficient to overcome g,

i) Listening to Country and Western music or old Leonard Cohen songs invalidates your argument, and

j) You must deal with the fact that, on any Monday, it's not Monday on the other side of the international dateline.

I know I've made a solid point when you refuse to answer. :)

>I know I've made a solid point when you refuse to answer. :)

I don't know. You've never made one.