My Heroic and Lazy Stand Against IFTTT
blog.pinboard.in
blog.pinboard.in
> 17.This Agreement is personal to Licensee and may not be assigned or transferred for any reason [...]. IFTTT expressly reserves the right to assign this Agreement and to delegate any of its obligations hereunder.
Any developer signing this agreement is nuts.
Hopefully this costs them a lot of buisiness and they have to revert.
Now if the penalty is three dogs and a pony, then nuts to that.
The answer is probably no, they are merely a set of expectations they have around providing their service.
... or didn't read the TOS more likely.
I'd heard of it (I may have even signed up with it at some point), but this has to be the best explanation of IFTTT I've come across.
If you aren't familiar with his writing, you'd likely enjoy "Dabblers and Blowhards" http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm
And this, of course, is a modern classic: http://idlewords.com/talks/website_obesity.htm
Some of us care a great deal about license agreements for different reasons.
I get that your service looks bad when integrations break but you could make a different contract requiring developers to give you a heads up in advance of any API changes and then you do the work of keeping the integrations working.
Demanding someone make changes and then offering them as much time as they need is missing the point. It's not the deadline that's offensive, it's the request for free work that you benefit from.
But why did you ignore all the commentary on your TOS? Are you endorsing those terms as the company you want to be?
It's already very clear.
Having read what was posted of the Terms of Service document, the document is saying that IFTTT shall own all rights, title, and interest in my content... You stand behind that?
Also, the developer pays YOU $3000/year to write an integration for YOU? WTF?
I run a service larger than yours. Not a chance in hell I'd agree to what you're asking there. You need to reorient your thought process around mutually beneficial partnerships instead of acting like you're doing someone a favor by letting them onto your platform. It'll work out better.
I've never used IFTTT, but my understanding is that this is the biggest value IFTTT provides - tying together a set of normally incompatible services. If you're now pushing this work onto the services themselves what is the value add that IFTTT provides? And wouldn't the internet be better off if those same sites adopted a shared, open API that could be used by anyone instead?
And PLEASE don't tell me to "just fill out the form at http://ifttt.com/platform", tired of that already. We have hundreds of thousands of active users of an IoT service and you're just ignoring us.
PS: I'm grossed out by the fact that I had to resort to a HN comment to try to get someone's attention. Go ahead and downvote to the abyss.
https://news.ycombinator.com/newsguidelines.html
> Please resist commenting about being downvoted. It never does any good, and it makes boring reading
Your work should stay yours, and as current as you choose. You will have to deal with the initial npm politics, but that's better than the IFTTT contract presented...
I'm reminded of the Joel Spolsky blog post Where there's muck, there's brass: "The trouble is, the market pays for solutions to gnarly problems, not solutions to easy problems." Presumably IFTTT's value was derived from writing these sucky adapters. Now, you want the target sites to write them and your value is derived from this legal agreement, which gives you ownership of these newly outsourced sucky adapters. You have to see how that rubs people the wrong way. If it's an open standard, then at least you're competing on a level playing field and the work these target sites are doing is not all solely for your company's benefit.
I'm not so sure there is a misunderstanding.
The facts seem relatively clear:
- You want services to implement your proprietary API so that IFTTT integration with their service runs more smoothly.
- Your business success is predicated on other services providing those APIs, but you want them to do the work for no reward.
- You have license terms that protect your interests, but not theirs.
- If a service isn't interested in playing by your rules you'll remove them from IFTTT to the detriment of your own users.
- You call Pinboard a "beloved service", but not so "beloved" that you're willing to support their existing API, just "beloved" enough to graciously allow them do build an implementation of your API.
The only misunderstanding seems to be that you think that's somehow reasonable, and most of us don't.
> we've been on the receiving end of platform changes too many times to count. I want to make sure we do it better
You know that API changes are painful, so you want to push that pain onto services like Pinboard, by forcing them to maintain compatibility with your evolving API.
> The changes we are asking for are indeed more work, but we know they will lead to a better Pinboard Channel on IFTTT
Interpretation: We're expecting Maciej to put more effort in, but it will make our product so much better if he does!
It's your product - shouldn't the effort be yours?
Of course they might do so for a couple vital ones to help jumpstart the integration system, but it's not black and white.
IFTTT is a bit different because this is their value-add. But is it so different that you can make a claim that in a context-free environment sounds almost absurd?
On IFTTT I think it's kind of reasonable to expect them to do it, but at the same time the inversion does things like (for example) let me write an IFTTT integration to my own service. You could just as well have both (IFTTT writing integrations, and individuals writing integrations) I imagine.
At one point integrating with IFTTT becomes a value add for both parties, and the delegation of "who should do this" is not obvious.
I don't think it's super clearcut here.
Sure, they got bitten by platform changes, but reacting to that was under their control. Now when the services change, they're going to have to wait for the engineering teams at the service providers to prioritise getting that integration working again.
Excel isn't its plugins, Slack isn't its integrations, IFTTT is only its integrations.
I agree that IFTTT is only its integrations, and them maintaining certain channels is definitely in its interests. But on the flip-side, IFTTT is an integration multiplier for any pipe.
So you can make the pitch that your startup should write an IFTTT integration, because that really gets you 100 integrations (the truth is a bit more delicate of course).
Another advantage is someone asks you "why isn't X inside IFTTT?" You can now actually fix the problem.
I definitely understand repositioning to "IFTTT provides pipes, but you provide the data." It's much more scalable (helping to ensure that it'll be around for a while) and offers advantages on both side of the fence. 100 companies maintaining 1 integration is more straightforward than 1 company maintaining 100 integrations. And that means IFTTT can concentrate on making the pipes (the real value-add, because "consume this webhook" isn't interesting in isolation).
Why they didn't do this and work for a way for their legacy (if unmaintained) channels to keep on working is a mystery to me though....
I think I disagree. Integrations are a big part of Slack for tech companies, but Slack is doing well not because lots of small tech companies are using it, but because lots of bigger less-technical companies are. With them, I think it's transformational to have good instant messaging, not integrations.
> I definitely understand repositioning to "IFTTT provides pipes, but you provide the data." It's much more scalable (helping to ensure that it'll be around for a while) and offers advantages on both side of the fence. 100 companies maintaining 1 integration is more straightforward than 1 company maintaining 100 integrations. And that means IFTTT can concentrate on making the pipes (the real value-add, because "consume this webhook" isn't interesting in isolation).
But this is exactly my point, there isn't anything in those pipes, it's just an integration at each end. Sure there might be some tricky technical stuff to scale it (I don't know), but that's not the product.
And I think 1 company having a core-competency of "plugging webhooks together" is simpler than 100 companies a) knowing another 3rd party API, and b) having to prioritise maintaining that integration highly enough that it matches the release cycle of IFTTT.
No. Because the situations are different.
Here, Pinboard did essentially nothing to get IFTTT to work the first time. IFTTT wrote the integration code, and has been maintaining it. They're now trying to push that effort onto other people.
i.e. They're trying to make YOU maintain code THEY wrote. Or worse, they're trying to make YOU write code which has no value for you, but value for THEM.
If you refuse to work for free, they will remove you from IFTTT integration... to the detriment of their own users.
> Of course they might do so for a couple vital ones to help jumpstart the integration system, but it's not black and white.
It is. Given their ToS, it's pretty damned black and white. IFTTT is pushing their development costs onto the platforms they pull data from. And then claiming that those platforms have to continue working for free, and that IFTTT owns the results of that work.
If you can't see a problem with that, I'm going to make you work for my company, for free, forever.
What? You don't like that?
Well... the same applies here.
It's as if you've gotten a lot of business to your small coffee shop because I've chosen to shuttle potential customers to and back from your shop. If one day I tell you I'm going to stop doing this, but you're welcome to pick up the slack, am I truly being unreasonable?
Well, if you (dishonestly) tell the customers that the shuttle is stopping because the coffee shop refused to work with you then you're absolutely being unreasonable.
And if you tell the coffee shop that they can pick up the slack, but they need to sign this one-sided, ridiculous contract that requires that you only use their approved bus company, and don't pick up customers from any unapproved stops, and accept all liability if something goes wrong, and pay for all maintenance and repairs on the bus, (including repainting it if/when the bus company changes their branding) and agree that all passengers are customers of the bus company not the coffee shop, and the bus service can chose to take them to a different coffee shop, and the bus company can discontinue the service at any time without notice, and you can't disclose the terms of this agreement..
Well, then you're truly being unreasonable. You're welcome to try it of course, but you can expect to be publicly called out on it.
Maybe IFTTT has good reasons for turning off the working integration. I haven't seen where they list them.
But this is the value you provide, this is your raison d'etre.
This is a legal, future setting precedent for ifttt and they're gambling on weaker websites to get squeezed.
---
I am [not] the CEO over at IFTTT. We messed up. Big time.
Pinboard -- and other services developers love -- played an important role in our success thus far and we dropped the ball with the roll-out of our new platform. We have a shared incentive: to make channels work reliably for our end-users. To both stabilize existing channels and to allow new services to connect to IFTTT, we are publishing documention for a standard API that any new channels will need to conform to.
Going forward, we will be allowing existing channels to run on the legacy platform. Additionally, we will be reviewing our ToS to clarify out intent. We're not keen on legalese, but it is part of the game when doing integrations between third parties.
To maciej, I've reached out personally via email to apologize for the unclear messaging to our users. If you would like to give us a chance to make things right, we would be grateful and happy to help resolve any other outstanding issues.
Is there a reason legacy support cannot occur? I haven't seen it addressed.
(If you act fast, Theranos could be your first Enterprise customer.)
Well, reading Maciej writing it sounds like you will no longer be connecting to his backend while Botize will. These things happen. Sometimes it's best just to move on.
The sum of your comments on here mean that I'll be looking to reimplement all of the IFTTT recipes I use on Botize.
You've stood by your legal team and defended the ToC, in addition to how this has been communicated and handled, and what it is you're trying to do.
Are you really trying to assert ownership of content as it passes through the APIs on your site? If not... why is that even in there? If you are, then there is no way I can keeping being a user of IFTTT.
It seems to me, that when these HN episodes happen that it would be a good time to pause and wonder if the internal bubble at IFTTT in which this was thought a good idea, actually produced an externally viable good idea. I think in this case, it did not.
Joking aside, Maciej isn't asking for "more time", he's asking for:
1. Money, if he has to do your work for you
2. Some kind of guaranty that your undocumented, private API won't change without notice in the future, rendering all this work useless
3. Legal terms that would be acceptable, ie that would not attempt to rob him blind of all intellectual property regarding any work in relation to your service (from which he derives exactly zero money!) and that would not prevent him from competing with you.
Your answer so far does not even attempt to address any of those points.
I am fine with IFTTT discontinuing support for my site because of our diverging views on whether a service like IFTTT should be a platform or a roll of duct tape, but the stuff people have duct-taped together should stay duct-taped together.
IFTTT to users: Weeeeelllll, we had great integration with X service, but they refuse to play ball with us any more. And now, their connector broke, and they refuse to fix it!
It makes you look bad to the users. And if you refuse this faustian 'deal', you're slandered and stuff breaks. And that break isn't because software rot, but because they broke it. And then blame you for it.
Yeah, blackmail is the right word.
You shall not...use the Developer Tool or Service in conjunction with a product or service that competes with products or services offered by IFTTT
IFTTT shall own all right, title, and interest (and all related moral rights and intellectual property rights) in and to the Developer Tool, Service, and Content.
Perhaps Pinboard should come up with some equally crazy terms and ask you to sign it in order to use their service.
Isn't that the entire premise of your service, providing this glue? Yeah, it's painful work. That's why people like your service! Sure, it would be great for you if the other services would do some of the work. But I'm guessing that you would not go along with Twitter requesting all intellectual property rights to your integration code for the right to use their API. Why would you request it of the services that integrate with you?
But the biggest problem here is that you changed the game. You created and maintained the Pinboard integration. You should own up to not wanting to maintain it. The message you sent to Pinboard users about your decision was... "misleading" is the nicest way to put it.
All of my further work will be done purely with local instances of Node-Red and Apache NiFi. It may not support everything IFTTT does (and I know that), but what I will have will just work.
And in all honesty, all "* as a Service" companies give me the heebie-jeebies, because I know you (collectively) can do the stunts shown here.
Edit: account deleted on IFTTT as well. The less I am a serf on anothers' system and the master on my own (Node-Red), the better. Enough of lock-me-in closed APIs.
This struck me as remarkably hollow. It doesn't even go into the issues of the strong Terms of Service conditions. Maybe, it's the juxtaposition of having just read a reddit thread about CEO interaction [1], but, to me, this kind of message is worse than silence. It's bad enough to get those fake "warm", "friendly" emails from startups trying to stop churn, but at least those are automated.
I like Maciej's style because there's no mediation of business-speak, it's just the message plus some eccentric local color/flourish. Shoot straight or just step aside. Silence is an option.
[1] reddit discussion about CEO interaction, interesting tangent https://www.reddit.com/r/oculus/comments/4cfd2h/im_founder_o...
But I am all in favor of a 'recipe' that consists of "startup does dumb stuff=>Maciej writes a hilarious takedown=>I LOL so hard people ask me what's going on from two rooms away". Can someone implement the API for that, please?
Botize apparently has no Reddit integration.
There's a definite opportunity here. I'd even pay more money for Pinboard (on top of the archival fee) for more Pinboard-specific integrations for things like this. It is too convenient.
I doubt I'm alone in thinking this way.
First we strong arm current implementations, forcing them into a Private API that we 'intend' to make public. Sort of how we intend to go to the gym, intend to drink less and intend to think about how our actions affect others in order to be better people this year.
Wait. Why would we believe this statement? Why would the people who willingly implement your private API care about it going public?
This "intend" is as much worth as the intent to build a comprehensive test suite and intent to document the code later.
What I'm hearing is you want partners to trust your intents but you don't trust any of theirs—as evidenced by the terms of service that is required and binding. The "not throwing legal threats" part comes off very hollow in that context.
If you did trust your partners, you'd make a new API alongside the current setup, and it would be so awesome that people would switch on their own. But as others already pointed out, it seems the value in the new API is self-serving and is inexistent for your partners.
I'm all for collaboration but I suspect you are trying to build a moat around your business and make a ubiquitous platform. I sincerely hope this backfires.
https://blog.pinboard.in/2014/11/new_pricing_policy/ - "Should I be worried? -> Only in the broadest, existential sense."
I think its an interesting train-wreck to take note of. And it is clearly a reflection of the CEO, who has consistently misunderstood or ignored the true complaints people have about this new direction, while half-apologizing for terms and blaming "communication" on terms that place absurd expectations on companies that IFTTT chose to integrate with, and now wants to reverse the roles of.
Meanwhile, maciej is doing everything right. Communicating with his users about what is actually going on (instead of lying to them as IFTTT has done), and doing so in a thoughtful and playful piece of writing.
Time will tell how this plays out. But I think if IFTTT's moral compass is willing to let this go public, if they think this is/was an actual good idea, their days are numbered. The PR around this change alone was horribly executed, in addition to the change itself being a big middle finger. Neither speaks to an understanding of their users or sites they depend on to integrate with.
IFTTT would be NOTHING without any other services to integrate with, and they chose to throw them under the bus.
You had a chance, IFTTT. But you revealed your colors, and now you don't.
Did anyone seriously think this through? What about companies that have among their "most confidential information" data, like passwords, crypto keys, confidential memos, etc., that they'd never store on an Internet-connected machine?
When IFTTT released the developer platform, they were solving two needs: 1) creating a consistent channel infrastructure, and 2) providing a tool for developers to write channels so they don't have to.
It seems like they are shutting down some of their legacy services, which is probably a good plan for a company with no revenue stream. Not a good plan, however, to make it look like it is the developers' fault.
When I first got contacted about the IFTTT channel, I was excited. After realizing how much of my application endpoint I was going to need to rewrite, it became a task I kept putting on the back burner.
In my mind, the process of integration is being done well. It just requires a lot of lift for individuals who are the only developer on a project that already feels like it has a never ending list of tasks.
It's funny - nowadays people don't go along with stupidity like this. They just call the bluff of the business doing the strong arming and drop their support for their platform.
Seriously, if IFTTT want to force people do craploads of work for no real payoff, best of luck to them. I do hope most folks won't play along though. And those license terms? Yeah, best of luck with that. I wouldn't use them either!
Running that endpoint is not easy. Once it's live, you're dealing with an entangled system of API, user, network, database, server, full moon, voodoo curse, and God knows what else. It's a giant flaming tumbleweed of pain.
Clearly IFTTT agrees, and that's why they're trying to make us do it for them.
Fun fact: legal language is not protected by copyright and can be copied, modified, republished, or reused.
With respect: are you a lawyer?
I'm not, but all the sources I can find written by actual lawyers put this claim somewhere between 'wildly oversimplified' and 'false', depending on jurisdiction and the kind of legal language (contracts vs legislation, etc.).
Eg for US law, [0] quotes Nimmer on Copyrights § 2.18[E] as stating that ‘There appear to be no valid grounds why legal forms such as contracts, insurance policies, pleadings and other legal documents should not be protected under the law of copyright.’
[0] http://www.adamsdrafting.com/downloads/Copyright-NYLJ-8.23.0...
Of course, your mileage may vary and my comments on the Internet should not be construed as legal advice for your specific situation.
Edit to add: The advice I received was in the context of contracts, privacy policies, and terms of service. I don't know about, and didn't mean to include, legal language in legislation or court filings. Important clarification--thanks.
Common interchange of what, though? IFTTT's utility came through connecting disparate services - Reddit to Pinboard, Twitter to Facebook and so on.
Common interchange of schemeless data. Take data from here, put there.
Pushing JSON blobs around, essentially.
I would like to convert a script I have which polls from my Gmail for credit card charge notifications and publishes to Airtable (which works great for this task!) to a more-general Gmail listener which publishes, and a more-general Airtable publisher which can be setup to record certain messages.
How do you encode "Oh, this service lets you tweet, but this one lets you only share links?"
How do you have a protocol that lets you handle both Twitter and Google Calendar?
At one point you're basically making a protocol that's a programming language, and we already have JSON + most languages.
So the answer to this is "JSON, or whatever other dictionary serializer you like".
I feel conflicted in some ways but pragmatism wins. Anyone know a non-IFTTT way to set this up?
https://zapier.com/zapbook/zaps/39/share-new-blog-posts-to-y...
I offer no personal endorsement, and have no idea whether it would work for you.
So not only are they trying to get people to do IFTTT's work for them, they're trying to get people to pay for the privilege of doing IFTTT's work for them. I'm, er, impressed.
> And they assert the right to patent any clever ideas I have while doing that free work for them, even though I hate software patents:
The relevant bit of the IFTTT TOS:
> 12. Patent License. Licensee hereby grants IFTTT a nonexclusive, sublicensable, perpetual, fully-paid, worldwide license to fully exercise and exploit all patent rights with respect to improvements or extensions created by or for Licensee to the API
They're not trying to patent your work, they're saying that you grant them a license to any patents you might get that relate to your IFTTT integration. In other words, a developer cannot create an integration for IFTTT, patent something in there, then turn around and sue IFTTT for patent infringement. This is pretty standard language in software licenses/contracts/terms of service.
How it worked until now:
1) IFTTT wrote glue code to interface with a site's published API, and IFTTT could then write recipes to use the site. IFTTT thus stitched together other sites published APIs as a service.
How IFTTT has decided it will work from now on:
1) IFTTT comes to you and orders you to write private endpoint(s) that do X, Y, and Z. They reserve the right to ask for additional endpoints, different call results, or anything else they dream up down the road. You sign a legal agreement promising to ask "how high?" any time they say "jump". You will not be compensated for this privilege.
Nobody is arguing that IFTTT can't change their service as they see fit. They can, as they've chosen to here, move from a model in which they write client code for other sites APIs, to a model where other sites write client code for their API. It's obviously beneficial to IFTTT if they can offload this work to other sites for free.
What's shitty and rude and presumptuous about their behaviour is going to other sites who never asked to be part of IFTTT (IFTTT was just a consumer of pinboard's public API) and saying "here sign this and get cracking on implementing our specs".
And when a site owner refuses such a "request", IFTTT is basically lying to its customers when it says that Pinboard has chosen to leave the service, rather than "IFTTT has chosen to shut down their working pinboard API client code".
To reuse your analogy, it's as though Google themselves built an App client for my site, then decided to move to a model where Android apps were responsible for hosting and bandwidth of their own app (their right) and disable all apps in the store who didn't specify a hosting location (their right), deleted the app they built (their right), mailed me the specs for their app and a deadline to reimplement it myself and host it at my cost (why would I be interested in this? I never asked for any of this), and then when I told them to get bent emailed customers "Sadly, beloved app $APP has chosen to take themselves out of the Android store" (lying).
Later, after putting a bizarre legal agreement in front of him to sign, IFTTT announced that Pinboard would stop working on their service in a manner that made it sound an awful lot like Maciej had just decided to stop supporting IFTTT. In reality, all the agency in this relationship belonged to IFTTT.
It's essentially the "protection/promotion" model.
Many business owners have claimed yelp salespeople have called them and tried to sell them the ability to bring down unfavorable reviews or that they would highlight them.
One google search away: yelp wins lawsuit that says they are perfectly within their rights to manipulate their ratings: http://www.dailydot.com/opinion/yelp-extortion-lawsuit/
"Yelp is pay-for-play, and the court says that’s just fine."
The ruling was that if yelp manipulated ratings, that's fine, but there's no evidence they did. I don't know whether to believe they've done it or not. There's a lot of business owners over the years who report having gotten shady calls, but it'd be really hard to prove those calls are from yelp and not from fly-by-night scammers. I get calls from "Cardholder Services" and "Microsoft" pretty regularly, so it shouldn't be surprising if there are extortive yelp scammers.
That is surely how IFTTT will pitch it to 3rd parties... but, really, probably not. Being accessible in the Recipe list isn't great advertising, anyone not using your site already probably isn't going to sign up due to seeing your name on IFTTT.
Framed another way, there is a famous saying in the design industry: "I can't pay you, but it would be great for your portfolio". Classic exploitation tactic; manipulative and predatory.
This is the clincher for me. I spent about 15 minutes looking around IFTTT before figuring out that there were no developer docs because this is a service for enterprise customers, not for us.
If you don't pay for the product, you are the product.
Nope...?
@idlewords: http://charlieharvey.org.uk/page/gandi_sha2_intermediate_cer...
Are you putting the chain certs in the SSLCertificateChainFile file, and not concating them to the SSLCertificateFile?
Most of the issues Qualys points out on blog.pinboard.in are not present on pinboard.in itself, so I presume there's a difference in config there that would be a good place to start. They're also running on different versions of Debian (squeeze v. wheezy, which ship different OpenSSLs) which accounts for some of the variance.
Also, as Qualys notes, disable RC4 ciphers on pinboard.in and you're in pretty good shape.
Obviously, what Linden is saying in this case is probably not helping his business case. It's clear to me that he either does not understand why Maciej doesn't want to implement a private API, or does not wish to understand it.
On the other hand, neither of those things are grounds for a downvote, I think. A downvote says "this content shouldn't be on HN" -- that there's something about a comment that detracts from how the community operates. Linden has been completely respectful in what he says and how he says it. Maybe that's not the case in what he's asking his users to do, but we may as well let him ask.
Ehh, I'm not sure that's generally accepted. A few years back pg himself did say downvotes could be used for showing simple disagreement, and many people seem to agree even today.
For example, the bit about owning content. Do they really want your content? Is content on the internet worth anything these days? If your content is worth something, it's likely the Google ranking which gives it value rather than the content itself.
I imagine that's just an attempt to keep people from suing over reproducing content to go over the pipes.
PEDRAGOSA V. GOOGLE SPAIN, S.L. - Google got sued for reproducing content in various ways in search results. The case went in Google's favor but the legal costs for this sort of thing is probably a killer for services which don't have that GOOG ticker symbol.
The "no competition" bit seems like it's meant to keep people from using IFTTT developer tools as part of their own competing service.
Why bother reading the legal stuff? It likely won't ever come up to affect you. There is some risk, but the opportunity cost of taking the time to go through it is probably greater. I imagine most of the world population doesn't have the comprehension ability to understand what they are reading anyways. You might as well just stop using the internet rather than trying to make sense of the legal stuff.
Sure, but most of it puts your tail on the line instead. They've decided that they somehow have enough power to make you do their job, and make sure you do it in a way that protects their legal interests over yours. You'd be a fool to agree to it.
> Do they really want your content?
Yes. Their lawyer told them that it was a good idea to make sure their license agreement gave them (and I quote) all right, title, and interest (section 3) to any materials displayed or performed on the Service (definition of "Content" in section 1). They thought it was a good idea to follow said lawyers advice, because it was easier for them if they could just do whatever they wanted with your content. So, yes, they want it. That's probably not because they want to run off with it, but because it's easier (for them) that way and they don't care about you. It's much easier for a business to evolve and grow when they know that they can just do whatever they feel like and don't have to stick within the narrow terms of an existing agreement. Open "give me all your stuff" agreements are much simpler to use.
> Why bother reading the legal stuff?
Because they could be bothered writing it, so they obviously think it's important. And it gives them all the rights that they could possibly want for nothing in return.
If it's not important, then it didn't need to exist in the first place. If it needs to exist, then it's worth reading.
We're not talking about a simple end-user here, this is Maciej's company and full time job, and IFTTT seems to want to use this license for B2B integrations. Crazy!
I don't think either side is right or wrong. I see people like RMS as being on the extreme end of the ideal side. He may be right. His tech usage habits from his beliefs may work for him. But I'm not willing to go that far.
I think leverage may be a silent force in this case. If X service has terms I hate but I feel like I really need the traffic I can generate from that service (so that I can eat) then I'm probably going to jump on it. If I feel like I don't need the service, then I may not bother. I may complain about the terms, but being unwilling to put in the effort for something I feel I don't need might be the greatest force.
In the Philippines, all businesses are on Facebook because Facebook is the internet. Facebook plays similar games with their terms (as does a long list of services). But if you want to advertise to locals, you don't have much choice but to give in.
I would like to see someone who is expert in this area weigh in on why these services come up with these terms. IFTTT isn't going to be selling or using user generated content. I don't see that Pinboard has any content to lose of their own (all of their content is user generated?)
I'm sure I'm wrong, but the only reason I can come up with is to cover your ass if someone sues you for content which goes through your wires and potentially gets displayed on your site. Covering your ass isn't evil. Attempting to remove the right for one side to sue in the normal operation of the service is attempting to create a lopsided relationship (one side gains powers while the other side loses powers.) But they may be necessary for a service which has received funding and could be a target for court battles.
I don't agree with much of your logic.
> If it's not important, then it didn't need to exist in the first place. If it needs to exist, then it's worth reading.
I have a spam folder in my email which I would submit as evidence to refute this point. I could also submit my Facebook feed, Twitter feed and a whole bunch of other sources.
Obligatory IANAL. But I don't need to be.
IFTTT came up with these terms because they believe the terms to be beneficial to them. It's that simple.
They could have put terms in which said "integration with IFTTT means you're giving us permission to connect to your service, and to copy and redistribute the data without limit". After all, that's what they do, technically.
Instead, they're claiming ownership over the data. Your data.
That's something very different.
Then there are lawyers who write contracts to see what the other side will stupidly agree to. (And bill additional hours for all the rewrite they need to do.)
You can choose either kind of lawyer for your business, but be aware that the people with whom you do business will judge you for it.