All right.
So we've heard from the community, we've heard from policy makers and I think it's time for
you to be able to ask questions because that must have been a bit frustrating to not hear
specifically when I hear your laughter about the specific Apple stuff that I'm not going
to comment specifically.
So it's time for questions.
I'm going to ask a few of them, the dumb one, and I'll let you ask the smart one.
My first question is actually to you, Alex.
Here we have a lot of developers that are developing the app, open source app, they
build their businesses, but sometimes they're hobbyists as well.
They just like to develop apps because they're training themselves because they're curious
because they like it.
So when I hear your presentation about interoperability of messaging services, what I'm dreaming
of is a kid one day or a hobbyist that is just able to build an app that is interoperable
with every single messaging service, it's just for himself.
He's not selling it to anyone, it's not a business, it's just him or her or them and
wants to be able to just interoperate and create something to exchange with his friends.
Do you think that's something that the DMA will be able to create and that's what we're
talking about or it's just impossible?
No, I mean, overall the DMAs of the DMAs to create opportunities.
So if you're a software developer and you see, well, I need, for example, access to
these APIs and all this, then you can go to the obligations of the DMA, you can say,
how can the DMA can help?
And so the idea is to create some room for developers to develop their software.
Now when it comes to the specific question of messaging services, Article 7, if you want
to go and take a look, which is the one that deals with this, is quite specific in the
sense that, for example, it says that the level of security and end-to-end encryption
provided by the gatekeeper has to be preserved.
So I can imagine that if you are a software developer, then you have to, and you're starting
from scratch, somehow you have to work towards that.
So it's not that I do something and that's it and that would work, but you have to make
sure that that level of security and encryption is going to be preserved.
And that I suppose that requires some manpower.
But the idea, anyways, is that as far as you are providing a messaging service that you
intend to provide in the European Union or are already providing in the European Union,
then Article 7 is for you as well.
Does anyone have a question to this or to something else?
Okay, many.
Let's start from you.
So actually I have a question from one of our livestream viewers for the Matrix Channel
for Interoperability.
The Data Act mentions harmonized European standards.
Is there some work underway in that respect now?
Thank you.
I guess that is for you, Lede.
Here you are.
Yeah.
So the work is actually starting now.
So it has not yet started.
We are now starting with the inventory of standards that facilitate interoperability.
And the creation of this, the creation of an inventory with all the different standards
and protocols that would help facilitate this interoperability among the different cloud
services.
So it's not there yet, but it will be hopefully soon.
And if needed, we might need to define our own standards.
Thank you very much.
I have a follow-up question for this.
So here again, I'm going to ask you pretty much the same question I asked, Alex.
What do you think the open source community can do if they leverage that specification
in order to create new solutions that could be open source or other type of solutions?
Do you think that's something that they'd be able to leverage?
Yes, of course.
Also because we want to have open specification, open APIs so that these people can change,
you know, you're not logged in into one service provider, you can change from one service
to another.
And this will open up also new business opportunities, new application developments, etc., etc.,
new cloud services.
Who knows?
So it's also another opportunity for innovation.
Okay, I've seen hands raising.
So I'll let you go for it because you're closing on anyone.
So you've got that for me.
Thank you.
I'm an independent lawyer and political scientist.
Okay, okay, I'm an independent lawyer and political scientist.
So I have three questions here.
First about the DMA with question with Apple how they will integrate or not.
It seems they don't want to.
And the thing is if we look at the Microsoft case that has been opened in 2006 from Commission
against Microsoft, one of the problems was interoperability from the Samba project.
So afterward, as the court ruled that Microsoft should provide for free the documentation for
interoperability, Samba get access.
But there was some problems still about some clause that should still be secret.
So that can end there and maybe Apple would like to do something like that.
Secondly, about the messaging things, about the interoperability messaging.
One of the problems about that is what about the quality of the end users?
What I mean is, for example, if there is a WhatsApp user, one of my friends WhatsApp users,
and for example, I am a signal user, I cannot interpret with them.
But on the question of security and privacy, one of the reasons why I use signal is because
of the privacy and the security concern.
And the problem is if there is interoperability between WhatsApp and signal, does it mean
that my message will go to a lower level of security and privacy because my friend use
WhatsApp?
Do you see the problem?
It's a problem of quality.
We will go down on the quality of privacy and security or we will up it.
It's an open question.
And the third one I forgot, I think it was, it's much more larger question.
It's about the question of anti-competition law.
So how do you see DMA will articulate with anti-competition law that is very useful for
open source community as we've seen in my case and various cases?
Thank you.
Right.
I'd be lying if I'd say that you got the easy questions.
So good luck.
Yeah, now these are very interesting questions.
And I come actually from the field of competition law and I'm glad you're asking this.
It's just my hobby.
So now about the, I'm actually happy that you mentioned the Microsoft cases because those
are quite important in history of antitrust when it comes to applying competition law
to digital cases, right?
And as you say, it's very important for the open source community.
Now one of the, and I think this speaks about the importance of the DMA and how powerful
the DMA is because when it comes to these cases, first of all, they run for a long period
of time because they take time to, you know, first of all, identify what's the issue, what's
the anti-competitive behavior of that company, identify that the company is dominant in the
market and then implement remedies say, okay, that was illegal.
Then you have probably an appeal and then that appeal will go forever.
And then finally you have your solution.
And by that time, then you just gave up.
Now with the DMA, actually enforcement is, it's actually really quick because as I was
saying in the presentation, once you've been designated as a key keeper, all the obligations
that we have in the map, these ones, they apply in six months.
So you have six months to adapt your business and comply with all of them.
Also another difference with competition law cases like these Microsoft cases is that
there is no, there's no like exception.
So for example, when it comes to competition law, you can say, well, I'm doing this because
this is efficient for the market.
And then you have a whole argumentation about how that was good for the market in the end.
And that takes some time also to figure out, right?
In the DMA, there are no exceptions.
So what you have is like in some of these obligations, you have very minor targeted kind of safeguards,
so to speak, where you can say, well, you know, I'm going, I have to, I'm the key keeper,
I have to comply with this obligation.
And what I can do is I can take, I can implement some measures to preserve integrity and security
of for example, the device.
But that doesn't mean that you don't have to comply with the obligation.
That means that you still have to comply and you're allowed to implement just some proportionate
justified measures to ensure that the device will keep that integrity.
But that will be it.
So with you coming back to your example about saying, well, what if the key keeper says,
I'm not going to open that API because of, well, they need to really justify that on
that, within that particular exception that we have there.
But it's not really an exception because they still have to comply with the obligation.
So there you can see, you know, a big difference with these anti-competition law cases that
take ages.
And you know, sometimes compliance is not as effective as we would like to.
Now moving quickly then about, for example, your last question about competition law and
the DMA, we have actually at the beginning of the DMA, we have some legal provisions
saying how actually both interact.
So for example, when it comes to the DMA, and this is an important aspect, the DMA is
not like something that is just really rigid.
We have some mechanisms to adapt the DMA, have more obligations or amend the obligations
that we have is if the practice, for example, in the software development community changes
and we identify more issues, we can include those.
And one way of including those is, well, if we have been running an anti-trust case, a
competition law case, and we have discovered that there are some things that would need
to be in the DMA so that we can actually act quickly, then that's a way of the DMA informing
from the competition law.
So there's a lot of synergies between the two RAs.
And then finally, very quickly, on the quality of use and messaging services, you're right.
So one of the concerns would be, well, you know, what service is provided, is a service
provided by Meta, you know, what about my Meta data going to the service of Meta, right?
One important safeguard that Article 7 has is that users have an opt-in option.
So if you, for example, are using, say, Signal, and Signal says suddenly, oh, we want to
interweb with WhatsApp, then you're still, as I use it, you can say, well, but I don't.
So then you can just opt out from that option and you can deactivate the interoperability
option from there.
And that's a way of calibrating that concern.
In any case, if you think about the way that Article 7 is constructed and interoperability
for messaging services is constructed, it's a request from the alternative messaging services.
So in this case, it would be Signal that has to evaluate, okay, this is the privacy that
I value for my users.
And you know, it's a business decision that I go to WhatsApp or to Meta and request interoperability.
Now if we are a very privacy-conscious service, maybe it's not in your interest to do that.
So in any case, privacy has to be preserved.
That's also in the law.
And still users, ultimately, you can choose and say, well, I'm still in Signal, for example,
and I don't want to have anything to do with WhatsApp.
Thank you very much.
Questions?
Yeah.
I remember you raising your hand from the very beginning.
I'll come to you too, don't worry.
Here you are.
I had a question regarding the long fight for getting refunded from Microsoft Windows.
So when you buy a laptop at the store, you can only find laptops with Microsoft Windows.
And when you refuse a license, you basically cannot get refunded.
That's a very long demand from the open source community that for software that you don't
use, you should be refunded.
So there is the monopoly of Microsoft's still Windows on laptops.
And I don't see how the side loading of apps is going to help to tackle that problem.
I think there was a missed opportunity in the DMA to say instead of allowing the user
to have this right to sideload apps, we should also have the freedom to load anything we
want, including alternative Linux distributions.
At the moment, I see that this sideloading apps is only tackling the problem of the user
space, the applications, but not the operating system.
So it will help, but I don't think it's enough because you're also strengthening, but by
doing apps for those platforms, you're also strengthening those platforms.
You're strengthening this oligopoly by doing that.
And also the sideloading apps, I was expecting that the OS manufacturers would put a lot of
restrictions using any kind of excuses to not have full access to the hardware, try to
obfuscate certain APIs, don't provide documentation on how the hardware works and so on.
And it's the first step, but I don't think it's enough.
I don't know if you want to answer to this because it was as much as a comment, as a
question.
Yes, several questions?
Yeah, all right, let's get several questions then.
No?
You were asking for the whiteboard.
I think two, so one, two, and then a third one.
Craig Russell, and I'm a software developer.
It seems that if you're going to allow developers to access these services, then instead of making
them petition the gatekeeper and go through a list of, I don't know, how many thousand
applications they're going to process and then say, well, it'll be sometime in 2036 before
we get to the ten thousandth application.
Why shouldn't you require the interoperability APIs to be open source and put it in the public
domain, then there's no argument about who can use it because everybody can use it,
whether you're open source or commercial.
Thank you very much.
That's my favorite question so far.
Thanks very much.
I've got a question actually back to the application specific.
Some of us will have seen what Apple have published and what their proposal is, and it's very
obvious from their proposal that essentially every time there's a safeguard, every time
there's anything that could lower the amount of things they have to do, anything that could
help them restrict the amount of freedom users have, they're exploiting it and they're going
to keep exploiting it.
My question really is how is the commission going to manage to make sure that basically
Apple dragging their heels isn't going to stop this from happening because right now
what it seems like is they're going to charge developers in a way even if they're not using
Apple services and so on and so forth.
How are the commission going to stop Apple from dragging their heels because clearly
they're very much willing to take this to the courts.
All right so I'll leave you answering the questions.
If anyone has a question for Lere, if not I will ask the next one.
Here you are.
Yeah, no actually I can tackle the, well in a way the way I see them, the three questions
I cannot relate it.
I see the relationship in this way.
So for example the first two questions, two minutes, okay.
Now the first two questions, I think so for example about refunding licenses and then
also why is Apple doing this about having the request and not really just giving all
the APIs open.
Well this is actually the type of feedback that we are looking for.
This is the type of feedback that we need from stakeholders because in a way one of
the things of the DMA is that this is also an important aspect is that gatekeepers once
they've been designated they have to comply with this within six months and it's for them,
the burden is on them so they have to come to us and put on the table solutions to comply
with this and they have to explain well we're going to comply with the vertical interpretable
ligation in this way and then it's for the commission and this I can go to the third
question, for the commission to evaluate if whatever they are doing is actually within
the law.
So for example when it comes to giving the open, the API, sorry, giving the APIs directly
open instead of having like a process request that can look more than some then it would
be asked to evaluate if that compliance solution that they are putting on the table is actually
compliant with the law and then we will see with all the procedural tools that we have
and we can actually have a case in this case against Apple and then this leads me to the
third question which is what can we do?
Well the DMA gives the commission a lot of powers to investigate and enforce all the
obligations not only vertical interpretable but all of them so for example one option
would be to, the commission can have specification decisions, we can tell Apple and say well
you have been proposing this, this doesn't work, you have to comply with this specific
solution that we are putting on the table now and that's something that in competition
law for example cases that doesn't really exist, competition law cases you have a remedy
in the case and that would be it but as here we can go to Apple and we can say in this
case, we can say well this is our specification decision, this is how you should comply with
this article and then we can also open infringement procedures that are actually pretty quick
and in those non infringement decisions we can say well you have not complied with this
obligation and here's your fine, this is how you should comply with that and then if
they still don't comply with that we can impose daily fines on a daily basis and then if they
get three strikes like three non-compliance decisions that would be systematic non-compliance
and there the commission has a lot of powers even to impose structural measures.
Thank you very much, then I will get two more questions, there is one from each one from
each and then after that anyway we have the workshop session as well where everybody can
ask questions and make comments directly on the tables but I'll let Amandine explain this.
The question I have for Leire in the meantime is that open specification we just mentioned
and you mentioned open specifications as well and it seems that you are trying to achieve
interoperability with your open specifications as well so I'm wondering is there some sort
of bridge between the two regulations in sense that the commission could be leveraging an
open specification developed in another through another piece of legislation in order to enforce
interoperability requirements to gatekeepers for instance one day and something I wonder
whether or not you see also something similar but I shut up and I'll let Haas give the question.
Are you a mind reader? So this was a question from online, so I'm just a messenger for interoperability
the data act mentions harmonized European standards is there anything in preparation?
Thank you, thank you indeed I am a mind reader and the question was that way.
Thank you, my question is about the cloud interoperability is it only about the data or
it's also about the workloads and if yes on what level is it on like yes.
All right so I give you the mic later and Alex if you want to add something because I think
it's connected to what you do as well and then after that we'll have to wrap up.
Okay so the first one with respect to the open specifications and the relationship with the
data markets act I think that somehow they are related but for the time being as far as I know
in the data markets act there are no gate keep there are no cloud service providers named as
gatekeepers. So okay okay sorry sorry so that currently in the data markets act there is no
gatekeepers there's no cloud service providers named as gatekeepers but eventually the open
specifications for interoperability should also apply in that respect. With respect to the question
online I think everybody answered it so this now a process in which we're actually
analyzing the existing standards and if there aren't any on interoperability we will define them
there's going to be a study allowance on that and what was the last one? The last question?
Oh yeah the data the data and the workloads so in principle in principle the data act is for data
at infrastructure level and also at platform and software as a service level but not so much
for workloads so but that's something to think about thank you. Okay so I think we're gonna wrap
up the panel but then we're gonna open the workshop when you're gonna be able to be more
interactive and then I will finish your question to the audience as well. Alex mentioned the fact
that now specification has to be open maybe they will have to require the user specification and
you ask a question very clearly why not open sources so I wonder if any of you see anything that
could stop a regulator to say no no you have to use that specification and you have to open source
those specific APIs and open standards I just wonder because that's one of the question that is on
the table of Amandine but I will let Amandine and give you a round of applause for the panelists.
And I will let Amandine give you the details about how the workshop will be going where you can
actually give your inputs on how to enforce the two different pieces of legislation.