1. It is absurd to expect to be able to make money from the work they are doing. That said, they may need to make accommodations to allow commercial plugins / complementary services.
2. The "you give your contribution to us" clause is standard in any open source project. How, for example, will they be able to update the project license if they don't own the copyright?
1. They're allowed to make $200,000 off of the community but other developers aren't?
When you can demonstrate to me how the existence of GPL-licensed web servers prevents the creation and sale of proprietary web servers, and additionally demonstrate to me that people will not pay other people to host stuff for them, I will accept that you "aren't allowed to" make money off of this.
Diaspora is delivering on their promises to their contributors. There is no problem.
Fundraise for your own project and you can run it in any way you see fit.
Write the code yourself and you can license it in any way you see fit.
The Affero licensing prevents some commercial venture from using their code as a foundation, creating a hosted service, tacking on some proprietary candy that locks users in, and out-marketing them. I'm fine with them safeguarding against that.
2. Open Source projects require that you sign your copyright away and assign it to them or offer them a license on compatible terms with their license. Signing a contract to assign your rights or offer your contribution under AGPL is standard fare. How many open source projects did you contribute to where you DIDN'T have to assign your rights?
1. They didn't "make" $200,000, they got $200,000 in donations, and yes, people should be allowed to accept donations. If you don't like the terms, don't donate. I'm sure the Diaspora guys would love it if someone put up another kickstarter page accepting donations towards contributing to the Diaspora code base.
Linux is well established - the licensing terms are unlikely to change and the community understands (independant of the legal agreement, which they mostly don't) that once they contribute code it is out of their hands.
The business of Diaspora is just as green as the code of Diaspora, and requiring copyright transfer is a very sensible way of anticipating the inevitable pivots.
I'm not anti-Free Software. I'm all for it. I make my living off of it, and I contribute regularly to open source projects. I'm anti-Overly-Restrictive-and-Innovation-Stifling-Licenses. You'll note that I recommended that the BSD license would be way more appropriate for this project.
Snarky translation: I'm all for embrace and extend of other peoples, just like late 90's Microsoft. Look at how well that worked for everyone.
BSD licenses are great and all, but often lead to a situation where the original developers get used with little to no compensation in return in terms of code improvement or financial benefit. A great example of how annoying this can be to the original developers - look at the bottom paragraph of http://openssh.org/
My take on the whole thing - they should have published a spec, with hard and fast guidelines for interaction and preferably a protocol verification test suite, rather than code. Then release an implementation with a license that is GPL or proprietary or whatever - just make it so that 3rd parties can write interoperable code if they want.
To put this succinctly, we need the "HTTP" of social media, not the "Apache" of social media.
That's a good point, and I totally agree that would be a good solution. It needs more than just one working implementation out there, or it will just turn into Google Wave part 2. The good thing is the Diaspora protocol is much simpler than the Wave protocol, so hopefully it won't take very long before good alternative implementations start showing up.
To put this succinctly, we need the "HTTP" of social media, not the "Apache" of social media.
That is very deep and it applies to a LOT of different "markets," not just social networking. A truly open standard API for interoperability is a very different thing from a truly open standard implementation.
BSD license is such a failure from the perspective of the copyright holder. It's a bunch of OSS guys working for free to enrich parasites who don't give back to the original developers.
Society benefits, sure. Those who use the code benefit, yes. But the guys who initially develop the software get little back. Charity work should be for poor people.
See the problem in this case is that Diaspora was open sourced in such an immature state that it's almost certain that a large chunk, if not the majority of the development will be done by people other than the initial developers. Large portions of the codebase are already being rewritten by outside contributors, because of all of the security holes.
Now add to that the Contributor Agreement, which assigns joint ownership to Diaspora, Inc. (who is free to license their work to other companies under any agreement of their choosing), compared to the contributors (who are bound by the AGPL).
So who's doing the charity work, and who are the parasites getting enriched here?
That's a fine point. Personally I favour the GPL and am not really sure what to think about this Diaspora license scheme.
My post was really targeted at BSD style licenses and how they are awful.
The entire principle of pro bono work is as a civil service - improving society by engaging with the disadvantaged in your community.
Software professionals are still new to the professionalism thing. We haven't learned the lessons that lawyers and doctors learned a long time ago. Do pro bono work - it's an important part of life - but choose your beneficiaries wisely.
BSD licensed software is just handing free cash over to the advertising industry. Re-brand it, market it, make easy cash, and destroy the popularity of any GPL competitors which then stifles innovation for that particular type of product.
Heh. The reasons given also explain why the GNU project has failed to release any influential software like GCC, the various GNU shell utilities, GNU Emacs, GDB and other such insignificant projects.
No denying the influence of GNU, but have you noticed that commercially tolerant licenses are becoming more popular and businesses are some of the biggest producers of new major open source projects?
I've noticed the polar opposite in my field (enterprise security): major open source providers pulling back on source code rights because of rampant abuse.
Depends on how you apply it. MongoDB uses an AGPL core, with Apache drivers. The end result? Your deployed modifications to MongoDB must be made available, but your application itself can stay closed. It's kind of like the LGPL, but for network services.
It's always seemed to me that with truly free software, you absolutely could compile into a binary and distribute it without the source code. I'm all for abolition of most if not all intellectual property protection, but the copyleft stuff always seemed to me just "we don't like certain restrictions on software, but we're perfectly fine with these restrictions on software."
Thanks for saying this. I think it's best to compare this kind of freedom to freedoms we get from our constitution. You can't deny others those freedoms.
Remember that the GPL prevents one thing and one thing only: making proprietary forks. Meaning, the only "freedom" it doesn't give you is the freedom to restrict the freedom of others.
This limit is perfectly in line with the Declaration of the Rights of Man and of the Citizen. I argue that anything that allow this limit to be crossed does not most efficiently promotes freedom.
Yes, permissive licences do not most efficiently promote freedom. (Don't get me wrong: they do promote freedom.)
Now the AGPL, because of its additional restriction, could be seen as less free. I think that technically, it is (it doesn't fully give you the right to private modifications). But the spirit is the same, applied to remote applications instead of distributed software.
It seems to me that in a world with absolute freedom when it comes to software, it would be perfectly fine to conceal source code. If not, that would imply that the string of bits encoded onto your personal hard drive in your house would be an infringement on others' freedom to have access to that data. Free software in that regard is incompatible with privacy and property rights.
You can conceal any code you write from scratch, but you can't build onto GPL code for free without agreeing to reciprocate. It seems a fair exchange to me.
[Condescending explanation] Among the four freedom, free software gives you freedom 1: the right to private modifications. Meaning, as long as you do not redistribute the software, you don't have to redistribute the source code. And if you do distribute a particular version of that software, only that version of the source code must be accessible. You can still conceal a private fork.
Now in the case of software executed remotely, or software as a service, Eben Moglen himself reckons there is a conflict of rights: because the client is effectively using the code, it should have access to the source code. And because the server do not actually distribute the software, it should have the right not to release anything.
You can't satisfy both rights at the same time. The GPL satisfies one (it is 100% compatible with privacy rights), and the AGPL satisfies the other (and makes itself incompatible with some privacy rights in the process). That's a pity, because before the rise of software as a service, the GPL was the ultimate freedom respecting licence. Now you have to choose between two compromises.
PS: Don't say "property" about software, if you can help it. It is a inaccurate analogy from the physical goods, which fail to convey the truth about knowledge. (Of course, software is pure knowledge.)
I don't understand how your comment is opposed to mine. We're both saying that the GPL (and AGPL) is inconsistent. The only difference is you deem it an acceptable compromise, while I'm still a bit skeptical.
Specifically, I'm skeptical of the claim that if a client uses code, he or she deserves access to the source code. Sure, it's probably better to provide access to it, just like it's probably better to donate to charity, but I don't think either should be enforced by threat of violence (while it may sound silly initially, software license litigation boils down to a threat of violence).
To me, code in the public domain (or all code in a society with no legal protection for code) is perfect. That seems to me like purer freedom.
Lastly, when did I say "property" about software? I'm against legal protection for intellectual property when it comes to software. I agree that software is pure knowledge, every piece of software (that compiles/runs) is an algorithm (in fact, a number), and that writing a piece of software or coming up with an algorithm should give you no inherent ownership of it.
The reason you deserve to have access to the code you run is because it's the only way for you to trust it. Code you don't have access to has a tendency to betray you with various "features" (spying, arbitrary limitations…), that just wouldn't be there if you had access to the code. In my view, resorting to state violence to prevent such treason is perfectly justified.
What you call "purer freedom" is actually negative freedom, which is about not forbidding. The GPL promotes positive freedom, which is about enabling. As we can see when we compare the GPL and permissive licences, the GPL is more effective at enabling everyone to look at the source code. For me, that's what counts. I don't care about how "pure" the freedom is, I just care about it's effectiveness.
Lastly, you said "Free software […] is incompatible with privacy and property rights". "Privacy" was appropriately used, but I think you tossed "property" without much thought, using its positive and undeniable aura.
Are you saying your and/or the Free Software Movement's philosophy goes like this: Since access to code is the only way to trust software, everyone deserves the right to the access? The only way I'll be able to have a Ferrari is if it's sold to me for only a few thousand dollars. Does that mean I a deserve a Ferrari for a few thousand dollars? Something being preferable doesn't mean it's deserved.
How can this be a negative vs. positive freedom argument? Not distributing source code places restriction on the client, while forcing developers to distribute source code places restriction on the developers. Either way, if software usage is restricted at all, then someone's freedoms are going to be restricted. The only solution I see is for there to be no legal protection of software, period.
I used "property" to refer to the physical hard drive holding your data, as well as your house and land. Of course, many argue that privacy rights follow logically from property rights, so the distinction probably isn't necessary.
I certainly did not want to say that for any A and B, if the only way to have B is to have A, then we must have A. In some case, however, B is either a fundamental right, or is necessary to exercise that right. Here, B is the right to privacy and free speech.
To exercise your right to free speech, the only reasonable way is to use the Internet. And you need to run computer code to do that. Similarly, to protect your privacy, the code you run (all of it) has to be trustworthy. And I say that to be trustworthy, the code must be free, at least for you. Conclusion: running free code (and only free code) is necessary to exercise some fundamental rights. Therefore, everyone deserve it.
The positive/negative freedom argument comes from the facts that (0) the four freedom are way more important than the freedom to proprietarize software, and (1) they conflict. If you want to preserve the greater freedoms, you have to sacrifice the lesser one. Now, people could be reasonable, and respect the four freedom even when they are allowed not to. But I think we can agree that many people aren't reasonable (the most famous example was X).
I now understand your usage of the word "property" was indeed legitimate.
This word "viral" is like "death tax" or "pro-choice"; it communicates a real phenomenon with an overt spin.
The reality is that this "virality" you're talking about is a perfectly reasonable authorship protection. It allows groups that want to claim firm ownership of a project to release its source code without worrying about ending up competing with a fork.
We all know, at least ever since Github made it cool, that forks are a desirable property of open source development. But it wasn't always looked on that way and sometimes it in fact isn't desirable. Perfect example: a company that wants to make a living selling a product. We're all better off if they publish their source code, but if they do it with straight GPL, it's going to end up used against them in someone's web app.
This is neither here nor there with respect to Diaspora. They may have made some claim about exactly how "open" their "openness" is intended to be. But it's simply not fair to suggest that the AGPL is an egregious license. "ALL RIGHTS RESERVED" is an egregious license, and the most popular license in the world.
Actually the AGPL doesn't prevent you from competing with a fork, as long as that fork is also open.
Also as far as the contract goes, it's only if you want to contribute code back to Diaspora project and have it become part of canonical codebase. There's nothing to prevent you from making those contributions available on your fork and have them remain open.
Actually it should properly be proprietary fork, since if it ends up with one company being like Red Hat, they can still sell (with added services) what give away for free.
In general, you often see these types of labels when two groups collide (e.g. "Pro-Choice" vs "Pro-Life"). I think "viral" is the counter to the redefinition of "free" used by the FSF.
Maybe if the author started with the premise that Diaspora is more about offering an open source, secure and decentralized alternative to Facebook rather than zomg facebook killer h8 gpl mindset they might understand the situation better?
Yeah maybe I got confused at the part where they said "We think we can replace today's centralized social web with a more secure and convenient decentralized network."
A better title might have been "Some thoughts on the Diaspora software license and contributor agreement."
It's alpha software. It's not perfect. They're not going to get everything right on the first go, be it software bugs or maybe-too-restrictive licensing. Let's give it more than 24 hours before declaring it 'dead.'
Use an extremely restrictive and viral license that will force companies and "serious" developers to release the source code of derivative works.
Wasn't that kinda the entire point of diaspora, to be open, this is really just the guys ensuring that it stays that way. Sure it sucks that you need to sign a contract but in order to maintain that it remains open, it needs to be restricted.
I like to compare it with WordPress, what with wordpress.com and wordpress MU, etc. Rails and AGPL vs PHP and GPLv2. Admittedly Diaspora are two steps up on the language and license stakes but I don't think that's a real road-block. That's probably just small stakes. If it's popular enough, site providers will fall over themselves to enable 'installation' of Diaspora. People (theme designers mostly) complain about GPL in WordPress too, but lots of web designers are making custom WordPress sites and making money off it too.
Reason #2 ("they make you sign the contributor agreement") is basically a declaration that the author doesn't understand US copyright law. If you are serious about keeping your code free, up to and including the ability to enforce its license in court, there are legal reasons to do this.
At least, so says the FSF (and so do the IP lawyers I've talked to about it):
And if you are serious about relicensing your code under a commercial license in the future, there are legal reasons to do this. The gnu project is pretty trustworthy, but how much do you trust diaspora?
Actually, the contributor agreement is about getting the open source community to contribute a large percentage of the work and aggregating the copyright so they can sell it to other companies via dual-licensing, without giving the contributors the right to do the same thing.
I ran a non-profit called ossline for a while (www.ossline.org) which helped open source projects with contributor license agreements, so I am familiar with the issues.
I don't understand this "no way in hell I am signing a contract just to contribute to an open source project" sentiment. It is trivially easy to do (see Node.js's CLA which is an entirely electronic form,) and it gives the users all sorts of additional protections that traditional open source licenses can't otherwise provide, such as patent royalty protections.
The downside of these CLA agreements is that it allows the controllers of the project to re-release code under a less stringent license, and in some cases a commercial license. I can see someone becoming upset that code they worked on in a GPL project was later released as BSD, but that doesn't seem to be an issue with the OP.
All in all, the only reasonable take away here can be summarized in a sentence: "Diaspora may have a more limited uptake by corporations who are hesitant to open source proprietary additions to the software."
Do we really need to reach out to the license to declare this project DOA? This is a hacker community, right?
For me the technical "architecture" did it.
A rails-app, of all things, to serve as some sort of "superpeer" for what cries to be a P2P system? Really?
And their answer to their stated goal of "privacy aware, personally controlled" is to store the data not in one opaque box (facebook) but to distribute it over many opaque boxes, under the control of random people, without some sort of end-to-end encryption involved?
Really?
Sorry, but not only does real P2P technology exist, there are even free and mature implementations out there for most of the primitives that a distributed facebook would require. Why not plug together what's needed and invent what's missing?
We have mature DHT impls like Kademlia (edonkey), Chord, freenet. Look at the concept of Web-of-Trust and RSA/PGP for identity management in a distributed system.
Look at jabber for messaging and presence.
Something is seriously, fundamentally wrong when your answer to "distributed system" comes out as "Rails".
I don't think social networks need the same architecture as file-sharing networks. I want the data I publish on my social network node to be available 24/7 to my network friends. Since neither I nor most of my friends have a server at home, that means hosting the data on some server in some hosting center. So Rails isn't a necessarily stupid idea for a social network consisting of people like me.
Since neither I nor most of my friends have a server at home, that means hosting the data on some server in some hosting center.
No. P2P networks like freenet and edonkey already distribute content over many nodes, just with different goals and priorities. It would be possible to adapt these mechanisms to ensure that data you push to the network actually stays in the network for a reasonable period of client-downtime. I could think of various ways to achieve this technically (n-copies, caching superpeers, and each of your friends would naturally hold on a copy anyways).
One important bit to realize here is that the data volume is rather small because only meta-data (friends-graph, profile, wall, messages, etc.) needs to be handled in a truly distributed fashion.
Big chunks, such as images, could and should mostly remain on centralized services for the time being.
Another important thing to realize is, that the privacy in such a network could be made to be much better than on any remotely hosted solution because you can implement end-to-end encryption. All data on the network would naturally be transmitted and stored only in encrypted form. You would reveal chosen pieces to your friends by sharing the respective keys with them.
So Rails isn't a necessarily stupid idea for a social network consisting of people like me.
People like you (the end-user) aren't even supposed to install diaspora on their machines. Instead (if I understood them right) you are supposed to sign up on someone else's diaspora installation and generally trust all diaspora nodes in the network because your data travels freely between them.
Disclaimer: If this description is wrong then someone please correct me. There's some conflicting information about what diaspora is and what it wants to be.
Rails surely has its place in many applications. But for this one it just screams "We have no clue what we're doing" to me.
Perhaps we have different threat models regarding social networks. I'm concerned about one big company being able to analyze (within its own databases) the social network communication and friend-graph of a large part of the population. I'm less concerned about targeted attacks on individual semi-public messages. Some of my friends use Adobe Reader anyway.
If reading a person's social network communication and local friend graph requires approximately the same effort as breaking into an individual mail server or sniffing SMTP traffic on a network node, and the criminal effort is approximately proportional to the number of persons to supervise, that's OK for 1.0 for me.
I don't know the details of the protocol between Diaspora instances. But I hope that if some foreign Diaspora instance wants to read my messages to my friends on my own Diaspora instance, then it has to supply some proof that one of its users is a friend of mine.
Well, as said, my criticism comes from half a privacy angle, but mostly from the technical/execution angle.
Their prototype leaves so many basic (and hard!) questions unanswered that, to me, their architecture smells less like a conscious decision and more like a strong case of: "If all you have is a hammer then everything starts to look like a thumb."
In all honesty it looks like a non-starter to me.
Sure, "just start hacking" is what everyone tells young startups to do, and that's what they apparently did.
But that approach doesn't work very well for building a distributed system where all the components absolutely must snap into one another if you don't want the whole thing to fall apart under stress. Much less if your stated goals include terms like "privacy" and "security".
The old proverb "Weeks of coding can save you hours of planning" does not apply here, at all.
Agreed. Diaspora looks like it'd be more of a privacy nightmare than Facebook, not less. With Facebook (or something similar), your concern is do you trust 1 entity (ie, the Facebook company) with your data. From what I can tell, with Diaspora the question becomes do you trust every peer than any of your friends might be using?
It seems like the sole reason for aggregating copyright in this manner is to be able to dual-license the source code to companies. So basically the community is more than welcome to help improve Diaspora (and by releasing at such an early Alpha stage, it's all but certain that large amounts, if not the majority of the code will be written by the community), but only Diaspora has the right to make any money off of it.
> but only Diaspora has the right to make any money off of it.
That doesn't follow. Anybody can take the AGPL'd codebase and make money off of it. It's not necessary to distribute something as closed source in order to make money, ya know.
That said, I hate the AGPL, simply because I disagree with trying to redefine "providing a service using Software X" as "distributing Software X." I'd have preferred to see them go with the plain old GPL, if they wanted a "viral" license. But whatever... it's their project.
It seemed to me that Diaspora is trying to hold the code and project together, and the open source community isn't exactly the best for holding code together. We have forks all over the place. I've got a fork, you've got a fork; we all have forks and no spoons.
Is it better for the world for the open source community to fork left and right and ultimately risk fragmenting the market to fail to compete against facebook, or is it better for the open source community to work together as a singular voice and produce something spectacular?
I remain neutral in the answer, and I think Diaspora has a difficult path ahead of it.
It would be more interesting in my mind if the community actually worked together rather than forking to compete against Facebook. What if this was the opportunity for the open source community to rise up as a single voice and strike Facebook down? Afterall, we failed against Microsoft. Can we learn from our marketing and sales mistakes with Desktop Linux to strike a blow to closed source software? I don't know if it this project or some future project. I don't know if it is the slow march that will prevail. All I know is that the more we fragment, the easier we are to discount.
I totally agree, and I think the best way to get the community to work together and prevent forks is with a less restrictive license and no contributor agreement.
During the Unix Wars, we lost about a decade of progress entombed in parasitic forks as Microsoft ran away with the whole market. Is there any reason to hope that applying the BSD license to Diaspora would not give it the same Achilles' heel?
It seemed to me that Diaspora is trying to hold the code and project together, and the open source community isn't exactly the best for holding code together. We have forks all over the place. I've got a fork, you've got a fork; we all have forks and no spoons.
AGPL was written to address this exact issue. If it does not accomplish it (as is the case the original article is arguing for) then it's a problem with the license and not the Diaspora project.
I'm not familiar with the AGPL.
Does this mean that I cannot modify the Diaspora source code to run on my server for my business needs, without giving join ownership of my modifications to Diaspora? / without releasing the modifications to the public?
Yes, it means that you have to allow your users to access any modifications you did and freely use and redistribute them further under AGPL.
The only problem I see here is site design - companies certainly won't like that their corporate style will be used freely. Hope this'll be worked around somehow (trademarking?)
About the code itself - Diaspora is a distributed system, so IMHO it's quite absurd to attract users with some proprietary installation-unique features. Diaspora is more of a network, not a product. Imagine some ISP creating their own proprietary extensions to the TCP procotol - sounds weird, right?
Actually it's not so absurd to want to build in proprietary features. Let's say Yahoo! wants to create their own seed for their users, but they want to tie the user accounts to their internal, confidential authentication systems. It is both completely disadvantageous for Yahoo and has absolutely no benefit for the OSS community for Yahoo to adopt Diaspora in that scenario. And I'm sure there are a lot of companies and developers out there who have unique features to add to their seeds that have absolutely no relevance to the main codebase or other developers.
I see no real problem with this. They just have to write dummy AGPLed adapter module, querying proprietary RPC service (or they can even use OpenID/OAuth internally). There won't be anything confidential more than curious user can find out, inspecting his browser's requests with completely proprietary service.
AGPL + contrib agreement is a way to ensure that commercial investments in open source projects are more likely.
everyone may use and modify it, but has to disclose its modifications. (since its AGPL'ed)
contributions that find their way back into the parent project (dispora) must sign the contrib agreement so that diaspora can license it commercially under terms they pick. this allows them to potentially make some money selling commercial licenses. investors need this security because they do not want to invest in a product that everyone exploit equally.
i think the model is valid and fair. it work for the company i currently work for (zarafa.com).
jarin has the right to not like the license, sure. but if he used his patches to serve a diaspora instance from heroku to anyone besides him self he should (AGPL) disclose those patches. of course this does not mean he should sign the contrib agreement, but that would limit the impact of his work...
jarin calls diaspora dead. i think thats unfair. they did a great job and it will be nice reference material for a rails3+mongodb+haml+jquery+websocket project. good choise of technology in my eyes! (thank $DEITY for not going with php)
This guy apparently haven't heard about the freedom box.[1] It's not out, but it's doable, and once we have it, self hosted Diaspora seed will be a matter of plug and play.
Therefore, we have no need for huge, scalable seeds. And despite the AGPL, profitable companies can make money out of Diaspora: contribute => make the freedom box more attractive => sell more freedom boxes. Pure software companies can be paid by hardware companies to do this job, everyone's happy. Equating profitable with "proprietarizeable" is quite a stretch.
I feel like I'm stating the obvious, here. Could I be missing something?
Let me put it this way. Say you have a Facebook account. Say you use it as intended: by doing most of your (semi) private communication through it.
Now, how much would I have to pay you for you to surrender a copy of your Facebook account, with your wall, your past conversations, and a copy of what your friends let you see? Promise, I won't do anything bad, but please sign this little paper that let me to, just in case.
That's the real price of using Facebook. Either you really think your price is $0, or you didn't think this through (most people don't, which is why I think Facebook is so popular). My price is $you_can't_afford_it.
(Edit: I forgot to mention advertisements, but I don't know how much they really cost me.)
Diaspora is asking users to do the exact same thing: give up their Facebook accounts and start over on Diaspora. In order for that to happen, there needs to be a serious incentive for users to move over.
"It's open source" is not going to cut it for anyone but a subset of techies. Data portability probably won't be a big incentive for most people either, considering you can't even get them to back up their hard drives. Although I think it is a pretty cool idea (and I would like to have one), I have serious doubts that "you can pay us for a thing that you plug into your wall and your profile lives on it" will be much of a sales point for most people either.
(1) Diaspora does not ask you to surrender your data to anyone. You host it yourself. At home.
Now there's still the switching busyness. As far as I know, Diaspora is shall communicate with existing social networks, and of automatic import for your remote data. So, the transition really amounts to by the FreedomBox, plug it in, and push a few buttons. From there you feel no change, except for the eye candy.
No change, no cost. Sure, Zuck will still spy on you while your friends are still at Facebook, but as they move, he progressively won't be able to. The same mechanism can apply to gmail: when you move out, you can still send and receive emails, and you are spied by Google when you communicate with a gmail user (but only then). I glossed over encryption, but that's the idea.
(2) Well, you nailed it: convenience trumps everything. It's like the Maslow's hierarchy of needs, but for the "average consumer". Concrete and immediate needs, like convenience, are at the bottom. More abstract and remote needs, like freedom, are at the top. That's not how it should be, but I'm a bit guilty of this myself.
So, I agree that if the FreedomBox isn't as convenient as services on the cloud, it won't be used. I just believe that it can be. Heck it will even do automatic distributed backup. It could even do High Availability with your mail server (and your web servers if we manage to actually change HTTP to look up srv records).
Now, I reckon the FreedomBox is like Diaspora 2 months ago: vaporware. For now, we can only wait, see, and contribute. But I'm confident. An Iphone-like success in 2 years from now as predicted by Eben Moglen seems actually quite realistic.
I appreciate what they are doing and really want this to succeed, but with this (maybe a little premature?) release it seems they are alienating their early adopters right off the bat with licensing questions and shaky code (and bad press). Sure it's pre-alpha, but once someone has an opinion it's hard to change their mind later, even if their first impression was based on false information.
Their biggest challenge however isn't code but rather getting the 500+ million people who don't care about private seeds to go through some clunky prohibitive process and start all over again. That's not to mention getting the millions of websites already building on top of FB to change.
88 comments
[ 2.6 ms ] story [ 157 ms ] thread2. The "you give your contribution to us" clause is standard in any open source project. How, for example, will they be able to update the project license if they don't own the copyright?
2. That's not the problem. The problem is making developers sign a contract just to contribute to the project.
When you can demonstrate to me how the existence of GPL-licensed web servers prevents the creation and sale of proprietary web servers, and additionally demonstrate to me that people will not pay other people to host stuff for them, I will accept that you "aren't allowed to" make money off of this.
Where is your great, timely, mind-share grabbing, relevant-to-the-times project? I would like to contribute money towards it.
Otherwise, stop sounding like such a h8r !
Fundraise for your own project and you can run it in any way you see fit.
Write the code yourself and you can license it in any way you see fit.
The Affero licensing prevents some commercial venture from using their code as a foundation, creating a hosted service, tacking on some proprietary candy that locks users in, and out-marketing them. I'm fine with them safeguarding against that.
1. They didn't "make" $200,000, they got $200,000 in donations, and yes, people should be allowed to accept donations. If you don't like the terms, don't donate. I'm sure the Diaspora guys would love it if someone put up another kickstarter page accepting donations towards contributing to the Diaspora code base.
The Linux kernel doesn't require copyright transfers. Most open source projects don't either (though many require a contributor license agreement).
The business of Diaspora is just as green as the code of Diaspora, and requiring copyright transfer is a very sensible way of anticipating the inevitable pivots.
BSD licenses are great and all, but often lead to a situation where the original developers get used with little to no compensation in return in terms of code improvement or financial benefit. A great example of how annoying this can be to the original developers - look at the bottom paragraph of http://openssh.org/
My take on the whole thing - they should have published a spec, with hard and fast guidelines for interaction and preferably a protocol verification test suite, rather than code. Then release an implementation with a license that is GPL or proprietary or whatever - just make it so that 3rd parties can write interoperable code if they want.
To put this succinctly, we need the "HTTP" of social media, not the "Apache" of social media.
That is very deep and it applies to a LOT of different "markets," not just social networking. A truly open standard API for interoperability is a very different thing from a truly open standard implementation.
Society benefits, sure. Those who use the code benefit, yes. But the guys who initially develop the software get little back. Charity work should be for poor people.
Now add to that the Contributor Agreement, which assigns joint ownership to Diaspora, Inc. (who is free to license their work to other companies under any agreement of their choosing), compared to the contributors (who are bound by the AGPL).
So who's doing the charity work, and who are the parasites getting enriched here?
My post was really targeted at BSD style licenses and how they are awful.
The entire principle of pro bono work is as a civil service - improving society by engaging with the disadvantaged in your community.
Software professionals are still new to the professionalism thing. We haven't learned the lessons that lawyers and doctors learned a long time ago. Do pro bono work - it's an important part of life - but choose your beneficiaries wisely.
BSD licensed software is just handing free cash over to the advertising industry. Re-brand it, market it, make easy cash, and destroy the popularity of any GPL competitors which then stifles innovation for that particular type of product.
If you want to keep your code closed, then you're more than welcome to do that. Just honor the choice that others have made with their code.
This limit is perfectly in line with the Declaration of the Rights of Man and of the Citizen. I argue that anything that allow this limit to be crossed does not most efficiently promotes freedom.
Yes, permissive licences do not most efficiently promote freedom. (Don't get me wrong: they do promote freedom.)
Now the AGPL, because of its additional restriction, could be seen as less free. I think that technically, it is (it doesn't fully give you the right to private modifications). But the spirit is the same, applied to remote applications instead of distributed software.
You can build onto GPL for free without reciprocating. That's called freedom 1: the right to private modifications.
[Condescending explanation] Among the four freedom, free software gives you freedom 1: the right to private modifications. Meaning, as long as you do not redistribute the software, you don't have to redistribute the source code. And if you do distribute a particular version of that software, only that version of the source code must be accessible. You can still conceal a private fork.
Now in the case of software executed remotely, or software as a service, Eben Moglen himself reckons there is a conflict of rights: because the client is effectively using the code, it should have access to the source code. And because the server do not actually distribute the software, it should have the right not to release anything.
You can't satisfy both rights at the same time. The GPL satisfies one (it is 100% compatible with privacy rights), and the AGPL satisfies the other (and makes itself incompatible with some privacy rights in the process). That's a pity, because before the rise of software as a service, the GPL was the ultimate freedom respecting licence. Now you have to choose between two compromises.
PS: Don't say "property" about software, if you can help it. It is a inaccurate analogy from the physical goods, which fail to convey the truth about knowledge. (Of course, software is pure knowledge.)
Specifically, I'm skeptical of the claim that if a client uses code, he or she deserves access to the source code. Sure, it's probably better to provide access to it, just like it's probably better to donate to charity, but I don't think either should be enforced by threat of violence (while it may sound silly initially, software license litigation boils down to a threat of violence).
To me, code in the public domain (or all code in a society with no legal protection for code) is perfect. That seems to me like purer freedom.
Lastly, when did I say "property" about software? I'm against legal protection for intellectual property when it comes to software. I agree that software is pure knowledge, every piece of software (that compiles/runs) is an algorithm (in fact, a number), and that writing a piece of software or coming up with an algorithm should give you no inherent ownership of it.
What you call "purer freedom" is actually negative freedom, which is about not forbidding. The GPL promotes positive freedom, which is about enabling. As we can see when we compare the GPL and permissive licences, the GPL is more effective at enabling everyone to look at the source code. For me, that's what counts. I don't care about how "pure" the freedom is, I just care about it's effectiveness.
Lastly, you said "Free software […] is incompatible with privacy and property rights". "Privacy" was appropriately used, but I think you tossed "property" without much thought, using its positive and undeniable aura.
How can this be a negative vs. positive freedom argument? Not distributing source code places restriction on the client, while forcing developers to distribute source code places restriction on the developers. Either way, if software usage is restricted at all, then someone's freedoms are going to be restricted. The only solution I see is for there to be no legal protection of software, period.
I used "property" to refer to the physical hard drive holding your data, as well as your house and land. Of course, many argue that privacy rights follow logically from property rights, so the distinction probably isn't necessary.
To exercise your right to free speech, the only reasonable way is to use the Internet. And you need to run computer code to do that. Similarly, to protect your privacy, the code you run (all of it) has to be trustworthy. And I say that to be trustworthy, the code must be free, at least for you. Conclusion: running free code (and only free code) is necessary to exercise some fundamental rights. Therefore, everyone deserve it.
The positive/negative freedom argument comes from the facts that (0) the four freedom are way more important than the freedom to proprietarize software, and (1) they conflict. If you want to preserve the greater freedoms, you have to sacrifice the lesser one. Now, people could be reasonable, and respect the four freedom even when they are allowed not to. But I think we can agree that many people aren't reasonable (the most famous example was X).
I now understand your usage of the word "property" was indeed legitimate.
The reality is that this "virality" you're talking about is a perfectly reasonable authorship protection. It allows groups that want to claim firm ownership of a project to release its source code without worrying about ending up competing with a fork.
We all know, at least ever since Github made it cool, that forks are a desirable property of open source development. But it wasn't always looked on that way and sometimes it in fact isn't desirable. Perfect example: a company that wants to make a living selling a product. We're all better off if they publish their source code, but if they do it with straight GPL, it's going to end up used against them in someone's web app.
This is neither here nor there with respect to Diaspora. They may have made some claim about exactly how "open" their "openness" is intended to be. But it's simply not fair to suggest that the AGPL is an egregious license. "ALL RIGHTS RESERVED" is an egregious license, and the most popular license in the world.
Also as far as the contract goes, it's only if you want to contribute code back to Diaspora project and have it become part of canonical codebase. There's nothing to prevent you from making those contributions available on your fork and have them remain open.
Diaspora is about choice, not market share.
http://www.kickstarter.com/projects/196017994/diaspora-the-p...
It's alpha software. It's not perfect. They're not going to get everything right on the first go, be it software bugs or maybe-too-restrictive licensing. Let's give it more than 24 hours before declaring it 'dead.'
Wasn't that kinda the entire point of diaspora, to be open, this is really just the guys ensuring that it stays that way. Sure it sucks that you need to sign a contract but in order to maintain that it remains open, it needs to be restricted.
Yes i know how that sounds.
At least, so says the FSF (and so do the IP lawyers I've talked to about it):
http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright
http://www.gnu.org/licenses/why-assign.html
I don't understand this "no way in hell I am signing a contract just to contribute to an open source project" sentiment. It is trivially easy to do (see Node.js's CLA which is an entirely electronic form,) and it gives the users all sorts of additional protections that traditional open source licenses can't otherwise provide, such as patent royalty protections.
The downside of these CLA agreements is that it allows the controllers of the project to re-release code under a less stringent license, and in some cases a commercial license. I can see someone becoming upset that code they worked on in a GPL project was later released as BSD, but that doesn't seem to be an issue with the OP.
All in all, the only reasonable take away here can be summarized in a sentence: "Diaspora may have a more limited uptake by corporations who are hesitant to open source proprietary additions to the software."
Certainly nothing to write a rant over.
For me the technical "architecture" did it.
A rails-app, of all things, to serve as some sort of "superpeer" for what cries to be a P2P system? Really?
And their answer to their stated goal of "privacy aware, personally controlled" is to store the data not in one opaque box (facebook) but to distribute it over many opaque boxes, under the control of random people, without some sort of end-to-end encryption involved?
Really?
Sorry, but not only does real P2P technology exist, there are even free and mature implementations out there for most of the primitives that a distributed facebook would require. Why not plug together what's needed and invent what's missing?
We have mature DHT impls like Kademlia (edonkey), Chord, freenet. Look at the concept of Web-of-Trust and RSA/PGP for identity management in a distributed system. Look at jabber for messaging and presence.
Something is seriously, fundamentally wrong when your answer to "distributed system" comes out as "Rails".
No. P2P networks like freenet and edonkey already distribute content over many nodes, just with different goals and priorities. It would be possible to adapt these mechanisms to ensure that data you push to the network actually stays in the network for a reasonable period of client-downtime. I could think of various ways to achieve this technically (n-copies, caching superpeers, and each of your friends would naturally hold on a copy anyways).
One important bit to realize here is that the data volume is rather small because only meta-data (friends-graph, profile, wall, messages, etc.) needs to be handled in a truly distributed fashion.
Big chunks, such as images, could and should mostly remain on centralized services for the time being.
Another important thing to realize is, that the privacy in such a network could be made to be much better than on any remotely hosted solution because you can implement end-to-end encryption. All data on the network would naturally be transmitted and stored only in encrypted form. You would reveal chosen pieces to your friends by sharing the respective keys with them.
So Rails isn't a necessarily stupid idea for a social network consisting of people like me.
People like you (the end-user) aren't even supposed to install diaspora on their machines. Instead (if I understood them right) you are supposed to sign up on someone else's diaspora installation and generally trust all diaspora nodes in the network because your data travels freely between them.
Disclaimer: If this description is wrong then someone please correct me. There's some conflicting information about what diaspora is and what it wants to be.
Rails surely has its place in many applications. But for this one it just screams "We have no clue what we're doing" to me.
If reading a person's social network communication and local friend graph requires approximately the same effort as breaking into an individual mail server or sniffing SMTP traffic on a network node, and the criminal effort is approximately proportional to the number of persons to supervise, that's OK for 1.0 for me.
I don't know the details of the protocol between Diaspora instances. But I hope that if some foreign Diaspora instance wants to read my messages to my friends on my own Diaspora instance, then it has to supply some proof that one of its users is a friend of mine.
Their prototype leaves so many basic (and hard!) questions unanswered that, to me, their architecture smells less like a conscious decision and more like a strong case of: "If all you have is a hammer then everything starts to look like a thumb."
In all honesty it looks like a non-starter to me.
Sure, "just start hacking" is what everyone tells young startups to do, and that's what they apparently did.
But that approach doesn't work very well for building a distributed system where all the components absolutely must snap into one another if you don't want the whole thing to fall apart under stress. Much less if your stated goals include terms like "privacy" and "security".
The old proverb "Weeks of coding can save you hours of planning" does not apply here, at all.
http://opensource.com/law/10/9/copyright-aggregation
That doesn't follow. Anybody can take the AGPL'd codebase and make money off of it. It's not necessary to distribute something as closed source in order to make money, ya know.
That said, I hate the AGPL, simply because I disagree with trying to redefine "providing a service using Software X" as "distributing Software X." I'd have preferred to see them go with the plain old GPL, if they wanted a "viral" license. But whatever... it's their project.
Is it better for the world for the open source community to fork left and right and ultimately risk fragmenting the market to fail to compete against facebook, or is it better for the open source community to work together as a singular voice and produce something spectacular?
I remain neutral in the answer, and I think Diaspora has a difficult path ahead of it.
It would be more interesting in my mind if the community actually worked together rather than forking to compete against Facebook. What if this was the opportunity for the open source community to rise up as a single voice and strike Facebook down? Afterall, we failed against Microsoft. Can we learn from our marketing and sales mistakes with Desktop Linux to strike a blow to closed source software? I don't know if it this project or some future project. I don't know if it is the slow march that will prevail. All I know is that the more we fragment, the easier we are to discount.
Well, I'm going to shave my beard now.
AGPL was written to address this exact issue. If it does not accomplish it (as is the case the original article is arguing for) then it's a problem with the license and not the Diaspora project.
OK that's a letdown.
The only problem I see here is site design - companies certainly won't like that their corporate style will be used freely. Hope this'll be worked around somehow (trademarking?)
About the code itself - Diaspora is a distributed system, so IMHO it's quite absurd to attract users with some proprietary installation-unique features. Diaspora is more of a network, not a product. Imagine some ISP creating their own proprietary extensions to the TCP procotol - sounds weird, right?
everyone may use and modify it, but has to disclose its modifications. (since its AGPL'ed)
contributions that find their way back into the parent project (dispora) must sign the contrib agreement so that diaspora can license it commercially under terms they pick. this allows them to potentially make some money selling commercial licenses. investors need this security because they do not want to invest in a product that everyone exploit equally.
i think the model is valid and fair. it work for the company i currently work for (zarafa.com).
jarin has the right to not like the license, sure. but if he used his patches to serve a diaspora instance from heroku to anyone besides him self he should (AGPL) disclose those patches. of course this does not mean he should sign the contrib agreement, but that would limit the impact of his work...
jarin calls diaspora dead. i think thats unfair. they did a great job and it will be nice reference material for a rails3+mongodb+haml+jquery+websocket project. good choise of technology in my eyes! (thank $DEITY for not going with php)
Therefore, we have no need for huge, scalable seeds. And despite the AGPL, profitable companies can make money out of Diaspora: contribute => make the freedom box more attractive => sell more freedom boxes. Pure software companies can be paid by hardware companies to do this job, everyone's happy. Equating profitable with "proprietarizeable" is quite a stretch.
I feel like I'm stating the obvious, here. Could I be missing something?
[1]: http://wiki.debian.org/FreedomBox
Let me put it this way. Say you have a Facebook account. Say you use it as intended: by doing most of your (semi) private communication through it.
Now, how much would I have to pay you for you to surrender a copy of your Facebook account, with your wall, your past conversations, and a copy of what your friends let you see? Promise, I won't do anything bad, but please sign this little paper that let me to, just in case.
That's the real price of using Facebook. Either you really think your price is $0, or you didn't think this through (most people don't, which is why I think Facebook is so popular). My price is $you_can't_afford_it.
(Edit: I forgot to mention advertisements, but I don't know how much they really cost me.)
"It's open source" is not going to cut it for anyone but a subset of techies. Data portability probably won't be a big incentive for most people either, considering you can't even get them to back up their hard drives. Although I think it is a pretty cool idea (and I would like to have one), I have serious doubts that "you can pay us for a thing that you plug into your wall and your profile lives on it" will be much of a sales point for most people either.
(1) Diaspora does not ask you to surrender your data to anyone. You host it yourself. At home.
Now there's still the switching busyness. As far as I know, Diaspora is shall communicate with existing social networks, and of automatic import for your remote data. So, the transition really amounts to by the FreedomBox, plug it in, and push a few buttons. From there you feel no change, except for the eye candy.
No change, no cost. Sure, Zuck will still spy on you while your friends are still at Facebook, but as they move, he progressively won't be able to. The same mechanism can apply to gmail: when you move out, you can still send and receive emails, and you are spied by Google when you communicate with a gmail user (but only then). I glossed over encryption, but that's the idea.
(2) Well, you nailed it: convenience trumps everything. It's like the Maslow's hierarchy of needs, but for the "average consumer". Concrete and immediate needs, like convenience, are at the bottom. More abstract and remote needs, like freedom, are at the top. That's not how it should be, but I'm a bit guilty of this myself.
So, I agree that if the FreedomBox isn't as convenient as services on the cloud, it won't be used. I just believe that it can be. Heck it will even do automatic distributed backup. It could even do High Availability with your mail server (and your web servers if we manage to actually change HTTP to look up srv records).
Now, I reckon the FreedomBox is like Diaspora 2 months ago: vaporware. For now, we can only wait, see, and contribute. But I'm confident. An Iphone-like success in 2 years from now as predicted by Eben Moglen seems actually quite realistic.
Their biggest challenge however isn't code but rather getting the 500+ million people who don't care about private seeds to go through some clunky prohibitive process and start all over again. That's not to mention getting the millions of websites already building on top of FB to change.