natefinch

I never said large. Small proprietary companies also can't use GPL. I guess, fuck them, too? Fuck anyone who wants to actually make money writing software for a living? How very 1998 of you. Doh, I did say large. Well, crap. How about "thousands of small proprietary companies..." ?

Not if you want to leverage the millions of professional software developers out there. With GPL you're stuck with the hobbyists and the very few companies that can survive getting paid for support of their GPL software.

You know what's BSD/MIT licensed (or similar)? Python, Ruby, Rails, and probably a million other things you use every day. Good software is good at making a community of developers, regardless of the license.

I think it's pretty obvious this is a 5 year old article. And in fact, it has ideas that are much more appropriate to 10 years ago than today.

GPL is a hindrance to your code, not a help... unless you're lucky enough to have your code become popular with a large open source community.

GPL prevents any proprietary software maker from using your software. It requires that if you use the code, your software also be GPL. Well, good luck with that. Software companies need to make money for a living, and most of them want to do it selling their software, not hoping someone will pay them to support their software.

In practice there's no difference between BSD and GPL in the worst case, and in the best case, BSD is better.

Worst case:

Some awesome devs make Cool GPL Software™. Hundreds of large proprietary software companies like the look of the software, but it's GPL, so they can't use it. They use something else. Cool GPL Software™ loses out on all the manpower that could have been given to it by proprietary software makers.

vs. BSD:

Some awesome devs make Cool BSD Software™. Hundreds of large proprietary software companies like the look of the software, and use it, but never open source their changes. Cool BSD Software™ loses out on all the manpower that could have been given to it by proprietary software makers.

end result: the same, but the BSD guys feel butthurt, and the GPL guys feel ignored

Now, the best case, which is what actually happens quite often these days:

GPL (same as above)

vs. BSD:

Some awesome devs make Cool BSD Software™. Hundreds of large proprietary software companies like the look of the software, and use it. Some of them contribute their work to the original BSD project, because it's good karma, good publicity, and keeps the community around that software alive. Cool BSD Software™ gains a bunch of hard work from devs who get paid to work on their software 40+ hours a week.

end result: GPL guys feel ignore, BSD guys feel elated.

This is why I'll never use GPL for any software I write.

This is very good advice. You may not be maintaining your script later on, maybe someone who is new to unix will be asked to go change it. Having the intention much more obvious will save them some hassle. Hell, even someone who uses unix a lot may not know every flag of every command you use. With no other context, it's pretty hard to know if -r is recursive or reverse sort, or something else entirely.

And god forbid you think you know which one it is and end up being wrong... you might not realize until it hits production (scripts not always being the best tested things in the world).

Yes, they might not be supported on BSD.. they're also not supported on Windows, what's your point? It's a lot more likely you'll have to read and/or change the script 6 months down the line when you've forgotten everything about what's in it, then you'll all of a sudden need to run your script on BSD when you've never had to in the past (obviously if portability is a requirement from te beginning, then that changes how you write the script from the start).

Nothing says duck typing has to be at runtime.

The only requirement to duck typing is "an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface".

This is exactly how Go's interfaces work. You define the methods you require an argument to have, and then anything that has those methods can be used as that argument, without the original type having any knowledge of the interface that was designed. The only difference between Go and Python in this regard is that Python doesn't actually define what a duck is for a specific method, it is implicitly defined by the methods that are called on it. Go explicitly defines what a duck is, which makes it a hell of a lot easier to know if the object you're passing in qualifies as a duck without reading every line in the damn function.

Yes, go checks that an object is a duck at compile time, that doesn't have anything to do with duck typing.