All right. Thank you, everyone. So we are moving on with the next talk. We're going
to talk about API Terms of Service. Unfortunately, Celia couldn't join us. She's ill at home,
but maybe offer. Can you offer yourself to give the talk? So, yeah, the floor is yours.
Thank you.
Actually, it was a joint talk between Celia and I, so you only had half of the talk, but
100% of the content, right? So, yeah, my name is Medimej Javier. I did many things in API
Space, wrote books, organized conferences, and one of the projects I've been working
on is this one that I'm actually really proud to have started, and I would love to have
your feedback after the session on this. So first, who in the room had issues with Term
of Services of APIs, you know, application breaking or business model changing or stuff
like that, you know, some of people here? Was it Twitter? Google Maps? Other, no, MongoDB
API versus, no? Okay, so we'll explore that together. So the idea was to try to be inspired.
We've been actually highly inspired by a project called Term of Service Didn't Read. I don't
know if you know this project. It's a group of people who read Term of Services because
nobody reads them, right? Except lawyers. But nobody reads them and say, we will read
them and we will tag them and we will show simply if they are risky or not for your data
or if they respect you as a user, right? It's a really hard work. They have been doing
that over the last 10 years and we say, okay, but for APIs actually, there is, for software,
there is also a big risk, you know, when you don't read what will happen to the software,
right? And the policy around the software. So we kind of forked philosophically their
project to do API Term of Service Didn't Read, right? And actually, you can see Celia here,
Benjamin III, owner of the project who is an open source lawyer, as you can call it,
it's like that, right? So just to say the project has been supported by the Ford Foundation,
the Modula Foundation, the Open Society Foundation as part of a grant to make more, the digital
infrastructure more open source and more safe and trustworthy. So just to mention that.
So where does the problem come from? We can take the example of Twitter, but we can take
so many others, right? But just an example of Twitter. 2012, actually it's 2012, 2012,
Twitter has a vibrant ecosystem, you know, thanks to their API, a lot of developers are able to
resendicate Twitter content and make great client applications on web and mobile. But Twitter now
has some investors who say we want to keep the money, we want to keep the ads, right? We want
to keep the ads. So if we resendicate the data to others, we can't push the ads and get money. So
we will kill the Twitter ecosystem by changing abruptly the amount of services. It was re-abrupt.
Many, many, we estimate that more than 300,000 applications died from developers who invested
their time and energy and stuff. So really a big, a big, a big, a big fiasco in the Twitter
ecosystem. But a platform is good as its ecosystem, right? So in 2015, oh my God, like we killed all
their ecosystem, developers are unhappy. The CEO of Twitter said, oh, sorry, developers, right? We
reopen the time of services, right? We'll reopen, please come back. We want to reset relations. Okay,
okay, let's reset relations, right? We, they updated time of services, make it more open, right?
2018, boom, they destroy apps again by killing the API that most of them use, claiming to,
they have to update the backend, right? You know, so that was their claim, say, oh, it's a legacy API,
you know, but we will not offer new versions, right? And 2023, after the long-nest acquisition,
now APIs are extremely costly. And some research, for example, who are used to have an API for free,
now they have, last year they had to pay $100 and now it's more than $40,000 to access Twitter API
for research. So just to give you like how unstable it can be when you rely on someone else.
As for software open source, as for companies opening their digital infrastructure APIs,
when there is not stability trust, you know, it's really hard to trust each other, right?
When an API is not stable, when people break API all the time, you may have known how Facebook was
breaking some of the APIs, how Google has shut down many, many other APIs, how Netflix stopped
their API to developers, you know, so many different ideas, so many different stories
behind that. So we thought how we can be inspired by someone who can claim promises and keep these
promises in the future. Actually, we have been inspired by Creative Commons, so I'm, you're
familiar with Creative Commons, right, you know, CC by, you know, all these licenses. It's really
easy to produce and really easy to understand. So this is where we started, we say, okay, can we
build a Creative Commons pattern for APIs, right? You know, so that's the idea. Of course, it has,
it's not just for copyright, it has more degrees of liberty, but let's see how the
research has been made and what's the result, right? Yeah, and as I said, for research,
now it's really like $40,000 a month, right? Of course, claiming that they don't want,
they want to avoid the AI, the AI to learn from the Twitter data, but still, $42,000 when you're
a researcher doing great stuff on social media information, that begins to be expensive, right?
But it will not be the academics or we'll pay the $44 billion, a little bit of space, right? You know,
so yeah, it's not the academics to pay, in my opinion, at least this amount.
So yeah, how we can leverage API terms of services for more trustworthy digital ecosystem.
So, you know, here I would mostly talk about web APIs, you know, we have the software API, Linux
API, Android APIs, whatever, it has also the same idea that APIs needs to be stable over time and
trustworthy, but let's say this one, there is also the infrastructure behind it. So, when you
rely on it, you want it to be real time, you want to access the data directly. So, I'm talking of
these ones which are, let's say, more tight to instant feedbacks and issues, right?
And the term of services just for the definition, the term of services are the legal contract attached
to the consumptions of these APIs. So, if I consume one API from a software provider, as a service,
you know, that he owes actually the service behind the APIs, he will attach a legal document who say,
you can use this API this number of time, this number of time per day, per month,
this is what you are allowed to do with my API. You know, some people consider
not like an open source, but that APIs can have limited use. You know, for example, Google Maps
does not allow you to consume Google Maps to do another map services, right? Just an example,
right? Can be obvious for business reasons, but this is not freedom, right? This is not the freedom
to consume the data the way we want, right? We have the open data movement that allows that,
but let's say this term of services is really a contract attached to the consumption of an API,
and you should read it. I really advise you to read it. So, this is what we call the term of services.
It has many degrees of liberty on the reuse, on the license, on the specs, on so many, so many things.
And so, the idea is to, and one of our other assumptions is that I've read the API term of
services is the biggest lie of the programmable web, right? Nobody reads them, and it's really
the worst when you know something is wrong by your users and not by your provider.
So, we made a survey across 200 experts in the API industry, you know. As a side thing,
I organize API days conferences, which is the main series of conferences on APIs worldwide.
And so, yeah, 40% believe that 40%, 42% never check if the API changes, you know. They never
check in their code or whatever. They just learn it when it's down, right? So, 42% that's just to say
it's quite a lot. 25% say they have a read approximately the term of services, you know.
It's okay, I have proxy, I read them in 23% like a little bit more, you know, when they have business
constraints in bank or whatever. And 30% consider they never have interactions with the provider of
the API. So, I just want to go there, look at the developer portal, read the docs, sign up, get my
key or my token and integrate, right? I don't want to spend more time on this.
And so, the most of the time when they know when API is broken or doesn't work is by email. 70%
of people just learn that by email. So, there's really this issue, this promise and this constant
communication that's really a problem in these things, right? We also tried a new idea in the
API space, which is the idea of copy left. Of course, copy left is not new in the Apprentice
world, but in the API space it's quite new. Imagine if you consume an API that has a specific license,
all the API you provide should have the same license, you know. So, that's something new in the
API space. Everybody believe that it's digital infrastructure, you know, it's not like text or
software like cold software. Now, it's hot, we have running software on servers. But imagine if you
consume an API from an academic institution, because they have great data, you have to,
all your APIs, even for business reasons, will have, we need to have the same license. So,
it's something we tried. Didn't convince the majority of people, but at least we tried to
explore that idea, right? And just to finish on the context, with all the interviews and surveys,
we've seen that there's a lot of pressure, a lot of pressure from the providers,
because of business and strategic decisions. Actually, when an API product manager and
developers publish APIs in a business environment, the lawyers come and say, look, what did you expose?
What's the license on this? And then they write this really huge and long and boring
Temur service contract. And actually, the lawyers don't understand so much the tech. So, there is
this miscommunication between the two that makes the text really complex with many, many
protections, which is not good when you want to consume something to generate a nice application.
So, we've seen also about how people can be completely dependent. If you build something on
Twitter or x.com, they're the only provider of Twitter.com data or x.com data. It's really hard
for you to compete to go to someone else. Imagine you want an SMS, do you want an API for SMS?
There are Twilio, there are like their Vonage, there are many, many others. There are plenty,
plenty, plenty of them, right? There's also a really important aspect when someone has a monopoly
of their content or data or infrastructure. It's really hard, right? But the only opposite,
I just want to show you also that when you have a stable API over time, it can be part of your
success too. Just example of Amazon Web Services, you know, so Verne Vogels, the CTO of Amazon Web
Services used to say, we had only chance to make it right, so we spent a lot of time designing our
APIs and the APIs actually never really changed deeply. Of course, they're adding more stuff
because they knew people will rely on them. So, this trustworthiness in the digital infrastructure
space is extremely important, you know? So, yeah, but how we can make more people aware of,
of making this more transparent. So, we interviewed like API providers, you know,
when their, the API's product is being developed, when they reach the contact
legal department, when they're, they're reviewed by industry standards, when the thermal service
are documented, when the need, thermal service needs to be updated, you know, there's a full
life cycle, right? So, how we do, how we tell people, so, so we did all these interviews
and then we, based on this, the final result was that 69% people wanted to make more trust,
enhance the trust between the providers and the consumer, right? 65% wanted to simplify it,
mostly to simplify it and 42% believed that it enabled, it's a promise that enabled to have larger
ecosystem, right? And just to give you another hint, Gartner, you know, the consulting company,
really expensive one, but say that company who are able to demonstrate a safe and trustworthy
ecosystem have 50% more chance to attract application developer, right? So, we see
approximate, approximate these numbers. And so, we, based on that, we also, as I say,
was inspired by Creative Commons, you know? Did you already use this, this quick, this quick,
wow, it's not a form, but it's a quick wizard. You know, just check, do you allow adaptation of
your work? Yes, no, yes, it's not sure like, do you allow commercial use? Yes or no? Boom,
you have your license. So, actually, it's really two clicks to generate your license.
Two clicks, just simple. And you have a license for copyright that everybody can understand,
right? You have the logos on the right and everything. So, based on that, based on the
conclusion I shared with you, based also on some other projects like Scriptaminant, OpenEthics,
TOSDR, API Commons from Kinline, a specific expert of the industry, we decided to do the same,
right? We decided to do the same, and this is the framework at the end. It's more complex
than Creative Commons, because Creative Commons has less degrees of liberty about copyright.
We actually, we went at the beginning for 18 degrees of decisions, right? And we reduced it,
we reduced it to actually five, which are, do you access, do I allow access to my API to
some people or to everyone, like what we call API neutrality? You know, like the no-gate-keeper
policy. Do I allow my competitors to use my API, right? Amazon Web Services, they allow
competitors to use Amazon Web Services. Competitors don't want to go there, but they would allow it,
right? Just to give you an idea, right? There is also the specification, you know, the design
and specification, my OpenEpi document, right? Or a PDPS specification. Do I allow it to be
reused, re-consumed, copied, whatever? Another one is what we call the ethical data policy. Yeah.
Oh, I think it's less than that, but okay. The ethical data policy, do I allow reuse of the
content in what context? I allow the reuse of the content. The loyal output policy is mostly
about the breaking change. You know, how do I pre-warn you before I do a change, a deprecator
version? It's important. Most of the company who are fair give three months to warn when something
can change some company go up to one year by contract to tell you, you know, when we make a
breaking change, we will tell you one year in advance. Well, at least we will keep the existing
version for one year. That's better, right? That's better than no notice, right? And the last one
is reference and attribution. You will see some people allow you to consume their API as long as
you say, okay, this data was provided by the University of Brussels, or this data has been
provided by this academia or this company. I offer you kind of the data and the API and the
service for free, do you allow attribution, right? And we believe it's always better when there is
attribution. So we said the type of logo in this. Now, just so you demo about height work.
So you can go on api-tos.org when it's the page of the project. We have a really,
really long report because we have been, the funders wanted reports, but you can start the wizard.
Okay. And then this is the wizard you have. Again, we really try to reduce to five questions.
At the beginning it was 18 questions, so that was too much. So the first, the fair use policy,
the fair use policy and the fair loyal change policy, you can go further, but this one you're
obliged, we consider to be a fair API, to be a fair API, which will fact the fair API commitment
trust, you have to accept these two. You can't decide anything, right? It has the fair use policy
and the loyal change policy, which we consider three months, three months change,
three months warning and notification for API change, right? So this is a yes, right?
Then API access. Do you agree? I'll just go full screen. Do you allow a full API neutrality?
Everyone can consume my API. Everyone can access to it. I will not gate, gate, not gate anyone, right?
Do you oblige for share or like? You know, say, look, if you, you will be obliged to do it for,
with the same license, you know, so it's not just, just consumption. You have to do it with the same
license. So we, we tried to, to push to share or like, right? And restrictive rights, which is
low rights, you know, we could, the, the person consider that they can limit the reuse, right?
So let's say I do share or like, right?
API specification, what are the conditions to access and reuse the specification?
Is it a C0 license, which is actually a fork of Kinlain API commands project, you know, putting
the copyright of API's public? Or is it a share like license, you know, like, you have to publish
under the same license? Let's put it CC0, for example. The ethical data policy, what are the
condition, the condition to reuse the data exposed by API? Is it a large data reuse,
but with some restrictions? No, no, non-compete, whatever.
Is it an open, full day, open data contract? Like, no, you can do whatever you want. I will,
this is, this is good for me. Is it a commercial data contract? Anything can be used except for
commercial reasons. So let's go for open data contract here. And the last one,
before the last one, the loyal output policy, what are the conditions to reuse the outputs from
the API usage? If you accept the commercial reuse, you have all commercial reuse, non-direct
competition on non-commercial reuse. So this is really the commercial aspect above, let's say
all commercial reuse allowed. And that's better at least. Reference and attribution,
is it a requirement? Is it no attribution needed? Or is it trademark enforcement?
Just to let you know also about the, some people here may think that attribution requirement would
be green, because this is the right way to do. We also tried these colors to the, to the people
in the community, right? They consider limitation or they consider no obligation, right? So it's not
moral, but it is about like constraints versus freedom, right? But it goes against the, what we
call free software. It's just to say like, this is what people understood. So we try to adapt to that.
Attribution requirement, no attribution, trademark enforcement. So you oblige to put the logo,
you oblige to say it comes from this company, this academia. Let's make some attribution requirement.
And then here, you can click here and then you have your pictograms. Sorry, I don't want to.
And you have the PDF of the license here. So I'll just go there. That actually take,
retake all the selection you got, right? So this is more the lawyer stuff. We tried to make it
simpler with all the exact duration and time and, and, and, and limitation, right? And that you can
attach to your current, it's not a full term of services, but this is a fair API commitment terms
that you can claim to show that for the things that are the more important for the community and
for your users, these are the one you claim and you write and you engage to respect, you know, for
what matters. It doesn't have the exact pricing or exact stuff. So this is a contract as an
addendum that you attached to an existing contract that overrides the existing contract on these,
on these five elements, right? So, yeah, I'll go back. I'll go back to, no, it's not this one. Sorry.
So the fact license, as we call it, it's for fair, fair API commitment terms is to make
API terms fair, transparent, trustworthy. And we think it's a fact, right?
It's, this is why we are now an API task project. So we made this first thing where we have
approximately a few dozens of companies who will begin to attach this to their, to their API.
We're still looking for feedbacks for improvement. The next steps would be to, to make it even more
simpler, put a little bit more degrees on, on the, to be able to write the full license, not just
an addendum to the license on just the fair terms. And the next step afterwards is to even make it
match in readable. So like this, we would love to attach it to open API specification or API
documents as a specific section, you know, but like, if we take a little bit more time,
and there are some, some discussions that needs to be taken. But just to let you know, we would
love at some point it to be machine readable. So when you consume an API, automatically, you will
know what you are allowed to do or not. And that will be a little bit more helpful for the developer
community. Thank you very much. And if you have any questions, we'd love to answer them.
Yes. Thanks for the presentation.
Um, is it the scenario that someone or a company would agree with all of the conditions, but in the
end would not respect the conditions, such as the data policy, for example, or it would change the,
and if yes, who or what would make sure that they are compliance?
There is a saying in, in French, actually.
Can I repeat the question?
Oh, can I repeat the question? So your, the question is, I tried to reframinate correctly,
the question is that it's great that if we write it and we try to put them on the,
on their API, thermo services, but will they really be enforced, right? You know, like at some point.
So there are two answers. The first one, as I say, we come from French, promises are only good
for the one who believes them, right? No. So this is a French thing. So I, I understand. I
understand where you come from, but it's the same for the existing thermo services, you know,
but at least it's what we believe it's like the nudge, right? You know, it is exactly like
creative commons. Creative commons, you can still put a photo and PowerPoint and steal it
without respecting creative commons. But if one day when people come and say, look, yeah,
in this presentation, this is my photo, you didn't pay a license, it was not allowed for commercial
use, or you are this big corporation, this is, this is how much you need to be fine, right?
So it gives a nudge of people respecting more, right? So that's the first thing. When it's easy
to respect, I believe people respect, right? We just make it need to be more easy. So if it's easy
to produce and easy to understand, you know, it's easier as a personal to look, I will make the right
choice, right? Because it's, when it's not known, like, like with pictures, for example, when we,
we didn't know that we were, we had no chance to know the license, it was okay to copy and paste.
Now we see the license say, okay, I take the risk now. And I take the risk of my company,
if it's okay to pay five, six, 10 bucks or more on the non-project or whatever to actually pay
and say, okay, so I'm good, right? So that's the, that's the first thing. The second thing,
which may be later, but, and we, we tried to promote that, but they stopped, they didn't want to do it.
We tried at some point to do exactly like they do on SLA, service of agreements, you know,
if an infrastructure provider does not respect their SLA, actually they have to give you back
money. In many, many contracts, they have to give you back money if they don't respect the SLA.
So now it becomes more contractual. We try to put that in this, but it's a, it's a, it's a practice
that really few companies do and respect, especially I've experienced that many times with the cloud
providers say, you did not respect the SLA, you have to give us money, say prove it. You know,
come on. It was slow. Now it was slow on your application, not on our, our infrastructure.
So, so that's, that's, but we tried, we tried. Like SLA.
Yeah.
Yeah.
So, you say, I'm trying to reformulate you say are two different concepts, the data and the
license with the data and the API itself. I agree with you. Just a example. I was
considering at some point for the French open data government. And I said, look, you can even,
you can give an Excel part, not an Excel file because they tried, but a CSV file, whatever,
as free because it's paid by public money. But if you put it on API, there's no instance.
There's no service. There's no ubiquity, maintenance, API access, security, whatever,
now it's, your data is now a service and you can find a model depending on what you want.
But you have to attach the API to more services with, so I agree with you.
There is the data aspect. This, we talk about the reuse of the API, but as I said, we attach that
to an existing contract where that should include the data license. Again, it's, it's a,
it's a lawyer stuff. There is a law room there with people we worked with who are part of the,
of the feedback. It's, it was really hard at least even for us to come understand that there is the
data, there is the license of the data, the reuse of the data. And there is the API, which has a,
it's another type of software who has another type of license realm where the data can transit.
But if it's transit by API, the license can be arding to each other. So it's not easy to
understand. And this is why we tried to make it simpler for developers. But thank you for
his feedback. And if it's not yet enough clear, yeah, we have to work on it. Thank you.
Yes.
It's based on the, mostly based on the interview. This is why I put some time at the beginning
of the presentation to explain all the people who were interviewed. We've considered the,
it's called FACT for fair API commitment terms. So we, we listen to everyone. We, we know, we
also have our own culture comes from open source, open, open, open digital infrastructure. And we
said, we can't call it fair if it has at least these two conditions, these two conditions are
obligated, are an obligation. And most of the people agreed with that. So the first two one,
which is the fair use and the lawyer, lawyer output policy, we consider this one with no choice,
right? If you were not, not have these bricks, you right. And the question was that there are some
choices that are mandatory and why they are mandatory.
Oh, no, no, it's a, the one that is selected by default is a, an implement, a bug implementation.
No, no, no, it's not, it's a bug, not a feature.
But I agree with you, it can, it can push the choice, right? It could push the choice, right?
But if, when people come to the website, they're, they have already a good vision about what they
want. So they are not tricked by that, but yeah, thank you very much.
Thank you.