What Aspects of Open Source Projects Do You Avoid? 344
paulproteus writes "I'm a Debian developer and a part-time contributor to a few smaller projects. I do a lot of free software-y and open source-y things. Sometimes, though, I don't do them. I figure some other Slashdotters might have similar hang-ups — we contribute to a project, but there are parts that we really dread thinking about. So I wrote a post about having these hang-ups, and I made a place on the web to share how others can help your project. What are the parts that, in your projects, you would be relieved if someone else looked at for you?"
irc.freenode.net (Score:2, Informative)
Adding comments (Score:4, Informative)
Re:Getting slashdotted... (Score:2, Informative)
Re:One thing I don't do is troublesome licenses (Score:2, Informative)
Have you ever read Slashdot before? There are tons of people who don't like the GPL on here, some with reasonable opinions, some frothing lunatics.
Re:Ego (Score:4, Informative)
Sorry guys 'n gals, but sometimes I need something now and can't wait for it to be included, supported or fixed in an open source solution. My clients aren't patient and don't really care about the necessity for creating an equal playing field for all software developers.
Re:Thanks for Slashdotting me (Score:5, Informative)
The blog post can also be read at http://www.asheesh.org.nyud.net/note/debian/avoiding-working-on.html [nyud.net]
Re:One thing I don't do is troublesome licenses (Score:3, Informative)
And the moment you distribute it you have to give the code to anybody you distributed to who asks
No you don't. You just have to give it to the people that you give binaries to. The GPL explicitly does not require you to give anything back, it requires you to give freedoms forward. In practice, this often means community-driven development with people contributing their changes upstream. They do this because it's cheaper than maintaining a fork though, not because the license compels them to. And, guess what? That economic incentive applies to permissive licenses too.
Compare, for example, Yahoo! contributing changes to FreeBSD back and Google keeping their internal version of Linux private. The GPL did absolutely nothing to protect Linux. The BSDL did nothing to protect FreeBSD. Yahoo! gave code back because they determined it that the cost of maintaining a fork was greater than the competitive advantage gained by keeping the code private. Google kept their filesystem (among other things) private because they made the opposite decision.
90% of software that is developed is never distributed. It is written in house to solve a particular problem. Whether you see any code back from these people depends entirely on whether they think it's cheaper. They can use GPL or BSDL code internally without any legal issues.
Re:One thing I don't do is troublesome licenses (Score:3, Informative)
Exact same thing I said. You have to give the code to anybody you gave the binaries to who asks for it.
Yes, but Google had to necessarily give the source for their changes for Android, while just try and get the source from Apple. Darwin OSS development was pretty much inexistent last time I looked, and what little there is seems to be unusable.
Sure. But that means Google can't ever sell that. The moment Google sells something with GFS in it, somebody will be able to ask for the code.
I find this overall to be an acceptable compromise. I can't just walk into Google's office and check out if they're using any of my source there and if they changed anything. Enforcing anything on internal usage would be very difficult, impractical, and involve tactics and methods I disapprove of. The moment Google releases anything to the public however, it doesn't matter whether they want to give it or not, they're legally obligated to give the code.
If you find the GPL to be insufficient, there's the AGPL, which Google seems to really hate as it makes the keeping changes internally much harder.
So resuming what was said so far:
When changes are made only internally, with BSD they get contributed when convenient, and with the GPL as well, with AGPL any user over the network can have them.
When changes are released externally, with BSD they get contributed when convenient, with GPL any user can have them, with AGPL any user can have them.
In light of that and my own preferences I therefore prefer the AGPL to the GPL where possible, and heavily prefer GPL to BSD.
Re:One thing I don't do is troublesome licenses (Score:2, Informative)
And the moment you distribute it you have to give the code to anybody you distributed to who asks
No you don't. You just have to give it to the people that you give binaries to.
Those two statements are the same... and you can eliminate the need for waiting for people to "ask" by simply offering equivalent access at the same time. eg: A src tarball available over HTTP in the same location as hte binaries. Even if the use chooses not to download, it was available. You only have to give hte "written offer" and then maintain those copies under certain circumstances.
But again - the GPL has nothing to do with forcing people to contribute back to projects - it only requires that if you want to redistribute code, modified or not, you must also distribute the source to those changes in a reasonably useful format. You owe no allegiance whatsoever to the "project" that started it.
Re:One thing I don't do is troublesome licenses (Score:3, Informative)
Which is exactly what he said... Swap "distributed" with "give" and it's nearly the same sentence.
This is just misleading enough to be untrue... While the GPL doesn't force you to contribute "back" (only "forward", as you've called it), you then can't stop anyone from, themselves, giving it "back", and contributing all changes upstream.
Yes, but the word "distribute" is peppered all over his post. He's clearly talking about distributing it.