hpr-knowledge-base/hpr_transcripts/hpr0341.txt

Episode: 341
Title: HPR0341: Libre Planet 2009 Conference Episode 2 of 5
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0341/hpr0341.mp3
Transcribed: 2025-10-07 16:47:01

---

Do it!
Thank you very much.
Next up we have, well let me actually make a couple quick comments which we didn't get
out this morning.
For people that want to follow along online on the back channel, we have the Libra Planet
IRC channel on free note and we also have, of course, the Libra Planet dot org wiki and
for anybody that feels so inclined if you want to keep any of your notes about any of
these talks right up on the wiki on your user page or anywhere else, that would be great
and helps us build something lasting that comes out of this conference.
Next, I want to welcome Benjamin Mako Hill, who is a board member of the Free Software
Foundation, has been an important part of the autonomous working group that's been
looking at free network services and has been a really key influence for Free Software
on a lot of projects like Davien and Ubuntu and the free culture community.
So let me welcome Mako's talk about free network services.
Okay, all right, well Matt's setting that up, I'll just say that when we apologize
and advance from my voice and maybe any sluggishness, I managed to, of course, come down
with a cold, a pretty bad cold from the last couple of days and assign its infections.
So I'm a little off, but I'll try my best.
All right, so in any case, last year, I mean, so it might be good for me to get an idea.
Who here was at the FSF members being last year and saw that?
Okay, so, actually, most, maybe most, but not everyone, maybe a little more than half.
So last year, I gave a talk about software freedom and network services and I did it the
day before the FSF can be in the meeting of a handful of people, who here was at that
the meeting the next day, a few people, I see two, three, four, a few people who were
there to talk about the sort of software freedom and network services and sort of what
it means.
So what I'm going to do first is for those of you who weren't here last year, I haven't
been following this, I'm going to try to pretty quickly sort of summarize that process
and how we sort of went through it and talk a little bit about sort of why this is something
that the FSF is interested in, at least sort of to make sure we all have that sort of
sort of grounding.
Then what I'll do is I'll sort of introduce basically our activities in the last year.
So what the FSF and the sort of group of people who are around the FSF have been working
on and thinking about freedom and network services.
So I'll talk about it and I'll talk in particular about this, a document called the Franklin
Street Statement on Software Freedom and Network Services, which is not an FSF document,
but it is an attempt at sort of getting a first, making a first stab at describing what
we think might be qualities or guidelines to think about in terms of software freedom
and network services.
And then what I'll do is I'll talk a little bit about an ongoing conversation that we've
been having inside the FSF about the Franklin Street Statement, about freedom and network
services and about what we think, where we think we're going.
So this is a little bit, it's a little bit premature in the sense that the FSF hasn't sort
of made an explicit statement on this.
So this is stuff that could change and stuff that we're still thinking through.
And hopefully by talking to all of you today and then tomorrow as we sort of move into
sort of the more uncomfortable space, we can actually move forward to some of these conversations
and we can actually help refine our thinking on this topic and help make real progress.
So first things first, you guys support, all right, you keep going, it's fine, so I don't
need it for a while, probably.
In any case, so the first to sort of throw down some sort of context here, of course there's been a lot of talk in the free software community around network service.
And this is in part because there's been rapid, and I won't say unprecedented growth, but there's been a rapid growth in the use of network services in general.
And a shift towards centralized computing now.
Now, we might say this is unprecedented because certainly these types of network applications are, but
Craig and Senator describes this great pendulum of computing with the idea was you work as first mainframes and then you move to many computers,
and then you had like terminals or this is back and forth, but we're moving into a place where an increasingly large number of
applications that we use do not run on our computers.
And you don't have to look far to see this.
If you look at what people, I mean, there are some of these, I guess they're kind of spyware companies that sort of like monitor everything that people do on their computers,
and then they can tell us with some degree of accuracy what people are doing, what people are doing when they use their computers these days,
frequently is interacting with web applications and frequently with a very small number of applications where people spend a lot of time on
Google and a bunch of its products.
People spend a huge amount of time on Facebook and MySpace, eBay, when I think around 4% Wikipedia with about half a percent of all time spent online.
And this time spent online is an increasing large fraction of the time that people spend with their computers, right?
So when people are computing, right, when they're using software, they increasingly frequently are using network software.
They're using software that they don't have access to.
They're using software that doesn't run on their computer.
They're using software that they can't change, that they can't use, that they can't control.
And of course, that's a relevant point for people that care about software freedom.
Because it marks an important shift in the power relationships that users have with their computers and with their software.
So the other thing that's worth noting is that there's a shift between a bunch of applications,
which have historically been done offline, right?
So sometimes this is called software as a service, right?
This idea that a lot of software that people used to run on their own computers,
they're now able to connect to a website and run the same application.
So for example, people are using instant messaging systems.
They used to install clients on their own computer.
And now they just go to mebo.com or one of these websites and use it that way.
And this is an increasingly common way for a lot of people to use it.
So I mean, Google Docs that people have used that as another example of something that does this,
although it also offers some collaboration features and collaboration features that aren't in existing systems.
So in any case, this represents an important shift in power relationships and
users in their software for a variety of reasons.
A shift towards more centralized services for software represents a shift in control over software in some important ways.
It represents a shift in control of one's private data.
If one is running software that runs on their own computer, they have control of their own data.
Right now, it has access to their data.
If you're running software that runs on someone else's computer,
then that person controls your data in ways that you don't even.
In many cases, when people are using network services,
their data is often data that they don't even have access to all the time.
And as we use these services for more variety of services,
one sort of democratic processes, one's market environment,
one sort of technological environment, all control over all of these aspects
insofar as they're mediated by the technology that we're using,
become controlled by the people who are running that software.
And as that software is increasingly not run by us,
we, the users of software, are increasingly disempowered.
So, this, of course, is where free software comes in,
because from my perspective, and I say this almost every time I talk about free software,
but I think it's important to remember.
It's important for me to remember.
I think it's important for a lot of us to remember that free software
is about, and the reason it's different than open source, for example,
is because it's about power and it's about control,
and it's about autonomy, right?
It's the example I like to give is this idea of sort of a communication technology
that all technology has particular affordances,
that all technology works in particular ways.
If I want to send a message to someone, and I want to use my phone,
I'm maybe able to send a particular message.
If I can type a text message, it's going to be short.
If I can send a picture, it's going to involve a different message,
right, that every technology that we use has particular affordances,
and those affordances determine, really quite explicitly, what we can say,
who we can say, how we can say it, who we can say it to, right?
It's technological control is hugely important to determining the way that we can communicate,
and so far as our lives are increasing and mediated by technology,
our experience is under control of people who control us,
and that's why control is important, and that's why this is an important question.
Now, in the context of network services, and the context of network services,
what's interesting is that in some cases, it seems like we,
as we use the software very differently, even though we may continue to have access to source code,
things are more complicated because the issues of control haven't changed,
so, excuse me, all right, so in any case, the, what's going on up here,
but in any case, the first thing that the FSF did,
and I'm still working through, sorry, giving a little bit of background in context,
the first thing that the FSF sort of noticed that this issue,
this issue that I've talked about in terms of user control,
wasn't even our only problem, and in some cases it wasn't the most obvious,
or at least not the most obvious to fix,
this problem in relation to user control over network services.
The first and most obvious issue, as people increasingly began to use free software
to take free software, especially software under the GPL,
and use it under, and use it in these network services,
was that copy left, right, this thing which has this concept,
and a very important part of the GPL, which has led to a really thriving free software community,
kind of stopped working in the context of lots of network services.
And the reason this happened was, was pretty simple,
it was that the GPL requires that source for software is distributed with software,
but that implies that the software is itself distributed, right?
So people can download and modify it, and people can download and modify pieces of free software,
and if they never distribute the software, then they never have to distribute,
then they never have to distribute the changes to their software.
Now this, now early on, up until reasonably recently,
this was a, this was a sort of, there was a convenient,
it was convenient that using software, in almost all cases,
meant that if you were able to use software, it's because you had the software,
but as people move towards sort of network services,
people become more connected, then it's no longer necessary to necessarily have the piece of software
that you want in order to run it.
You just, all you need is a web browser, you go somewhere,
and you never need to have the software.
The result was that people, that people who wanted to, could take pieces of free software,
they, GPL software, they could download them, they could modify them,
and then they could just, and then they could set them up on a website,
and they would never have to provide modified versions of the source code to the users
or to the larger sort of community of users and developers, right?
So this was the first, this was a problem that was recognized must have been six or seven years ago,
I guess in the first, in the first version, the first time.
And initially, Henry Poole and Bradley Koon,
worked to release a version of, I guess we can go back, yeah.
So, to release a version of the, of a license called the,
the Aferro General Public License, in 2002, so I guess it was six years ago,
and which basically said that any modified, a GPL web service,
that any user of one of these modified applications should have access to the source code.
So, simple enough, this was eventually sort of,
there were plans to sort of incorporate it into the GPL V3,
eventually the decision was made to incorporate it into a,
basically to continue keeping it in a separate license,
the Aferro General Public License, but the FSF sort of took over stewardship of the license,
and released this, I guess I talked about this in the last number's meeting,
so it must have been within about two years ago,
released the license, and then also when the GPL V3 was released,
it involved compatibility clause, so the people who had released applications
under the GPL V3 would be able to take code and either put it under the AGPL,
or they were able to use GPL libraries from, from, from AGPL applications.
That's, this has been, this has been successful for a whole set of reasons.
It solved this problem that developers, desires are respected,
so when people release code and expect people to contribute back,
that's respected, it meant that the community gets to improve their,
that the community gets to improve their software,
and it means that people aren't discouraged from releasing code
with the idea that someone can just take it and put it into a proprietary network service.
So these are all very good things, but unfortunately,
and this is sort of worth reiterating.
It became increasingly clear to people in the,
a number of people in the free software community, and in the FSF,
that the GPL and similar approaches only addressed sort of the,
the, the, the smaller, and in, in, in some cases, the, the,
the least important, the, the least, the, the, the less important
half of the problem of, of, of, of network services.
Um, this goes back to sort of how I introduced this, right?
Because even, even with accessible source code, right?
The users of, many network services remain far from free.
Um, users can still control their computing in,
um, uh, can still, may still not control their computing in many situations.
But having access to the sort, and a couple of examples can illustrate,
it can illustrate this, right?
Um, um, if I, having access to the source code for Google or Facebook,
doesn't actually help anyone very much.
Um, uh, because, because you don't have access to the server farm system,
you don't have access to the data necessary to, to make it work.
And even if you did have access to the data necessary to make something like,
certainly something like Facebook work, your friends would all,
um, would, would not be using it.
Um, so, so, so there's a whole set of complicated issues around,
um, um, um, or what freedom might mean in this situation.
It's because the typical methods that we've used,
the sort of, release of source code in will be free,
seem to not work or at least not work as cleanly,
at least some of these situations.
And the, and the, and the, and the, the, the, the situation is sort of complex.
We've sort of taken this idea that users should be able to control their computing, right?
It's a, it's a nice, it's a nice statement.
Um, but, but, but it ends up being complicated in the world of network services, right?
So, so, sure, one can control one's computing if it's on one system.
All right, that makes sense.
But, but, but, what does it mean for Wikipedia's to control Wikipedia's computing, right?
What, what is, uh, one's computing in the context of a large aggregate sort of work?
What is the, um, um, in, in services where, where the whole,
the whole benefit is that you have the sort of network effect.
What does it mean for an individual user to have control over that service, right?
Um, what does it mean in terms of everyone, in terms of everyone else?
Who does Facebook along to?
Who does Wikipedia belong to?
Is the source enough, source and data, et cetera, et cetera, right?
And so, it's, it's kind of, it's a, it's a funny situation because, um,
in a weird sense, although we're sort of, the, the free software community is, is sort of famous as this, for,
it's the sort of archetypical example of, of, of, uh,
a sort of collaborative community, right?
Um, our methods have been very sort of highly individualistic.
And when it comes to works that don't belong to a single person, maybe, but belong to everyone else,
we actually don't really know what to do, um, in some situations.
So, that sort of, that, that sort of, that's sort of where I left off last year.
I guess it was kind of a, uh, uh, funny place to leave off.
Uh, it's like, yeah, there was a big problem.
Um, uh, yeah, it would be nice if we could solve that.
So, um, uh, and, uh, and I wish I could report that we'd solved it all,
but I think that I can report that we've made some progress.
Um, um, so, so the day after, I mean, it was kind of funny, uh,
I gave, I gave the talk sort of 24 hours early, uh, on, on network services last year,
because the day after we took a bunch of people who'd come here for the members meeting,
um, and who'd sort of, it was the people who'd been, uh, uh,
uh, uh, writing about or thinking about network services and sort of, um,
um, um, spending a lot of time in this space.
Um, and, and, and who were sort of free, free software advocates,
and who were interested in software freedom thinking about these issues.
Uh, um, when we brought them together, we sort of, we sort of said,
all right, let's, let's think through these issues.
And one of the things that we did was we actually took a big, um,
a big list of, uh, of examples of applications.
Examples of examples that we thought were pretty good examples like, uh,
so like Wikipedia, that's a good, uh, or Facebook or Gmail or something.
And we sort of talked through what we thought the issues were,
why we thought those issues existed, and sort of worked, um, work from there.
Um, uh, uh, the group is called Autonomous, um,
and, uh, I guess it's up there you can see it.
It's spelled with a dot, it's a URL.
It's kind of like, uh, uh, I don't know, like a web 20 thing.
Uh, but, uh, but, uh, uh, uh, but Autonomous because we wanted to focus,
uh, start talking about what it meant to, to what Autonomy meant in this space.
What Autonomy for a group means, what Autonomy for a network service means, um,
um, how can we sort of think through these sort of issues?
And, um, what's important, what's important to sort of point out,
and I think that, uh, uh, um, is that, uh, is that, is that,
uh, it's worth pointing out that this, this is sort of a group of people, um,
um, um, who are all sort of very sympathetic to the idea of software freedom
in network services, but who are not, um, I mean,
there were, uh, uh, Henry Paul and I were sort of involved.
We're on the board of the FSF.
Um, but it wasn't, it's not an, it's, it's not an FSF project percent.
I should say that also because I'm sort of standing up here and, as, uh, at least,
in whatever capacity I, I, I can represent the, the FSF.
Um, you know, I should make, make it clear that Autonomous is not,
is not the FSF, but it's an interesting model, um, of, of, of one of the ways
that the FSF is trying to approach, uh, approach, sort of, this difficult issue.
And I think it's, it's kind of an interesting idea there as well,
because the FSF is, of course, traditionally been this organization that sort of speaks,
uh, very, uh, things along, uh, uh, at, you know, internally talk out
and thinks about, uh, very difficult, um, and issues related to sort of freedom
and then sort of speaks and says, yes, this is, I mean, like, defines.
This is what free software is, right?
Successfully, and I think with, um, uh, pretty important sort of results
and says, these are the licenses that people should use.
So, um, uh, Autonomous was an organization which was sort of created
outside the FSF, although sort of with, um, FSF support,
because the idea was that we didn't feel that we had, um, uh, unlike, uh,
issues of software freedom, what software freedom means,
where the FSF thinks we actually have a pretty good idea of what that means.
Like, we made the term off, so, uh, uh, uh, but, uh, I have a pretty good idea of what it means.
We don't, um, because we weren't sure we decided to work outside
to work with a broader community than usually works on these things
and to sort of, um, provide a space, um, on, on a different website,
autonomous.autonomous.us, where, um, which is a blog where people have, uh,
posted, uh, uh, basically articles, um, uh, and a couple podcasts thinking,
and talking about network services, um, all of which I think informed the FSF
sort of decision making on this issue.
But, um, some of which, even, I mean, there were just important disagreements
among, among the group of people who are sort of posting there, um,
uh, which I think is sort of an interesting model for the FSF to pursue,
because it's a way of sort of, uh, uh, thinking out loud outside of the organization,
with the idea being that it can inform those sort of decision making.
So, we're going to sort of, uh, uh, so, I'll talk a little bit about what
autonomous, uh, uh, has done first, and then I'll come back and, uh,
give you a preview of, uh, what the FSF is doing with what autonomous has been doing.
So, um, uh, the first, uh, the first, and the, the,
the most important outcome of the autonomous meeting,
and I think of, uh, autonomous in the first year was this document called
Franklin Street Declaration, uh, on Freedom and Network Services,
and the belief is that it's on there.
Um, and I've sort of put it up here.
We can go through it, uh, uh, pretty quickly.
Um, uh, the idea was basically a set of guidelines.
Um, and of course, these are, these are not FSF policy,
FSF is not endorsed of the Franklin Street statement, um,
uh, but has, uh, certainly, uh, uh, thought a lot about it,
and, uh, I can see, I'll show you where that sort of gone.
But the basic idea was, was, uh, uh, this is,
I've got the whole document up here, it's, it's, uh,
uh, a set of guidelines for developers, service providers,
and users of network services that sort of, uh,
is supposed to give, uh, uh, a set of ideas of what we think
good practices are.
This is sort of the consensus of the group.
We didn't agree on everything,
but these are the things we did agree on.
Um, one was, the, the, the, the, the,
the first group we sort of spoke to was developers,
and we suggested that developers use the, um, uh,
a GPL, the, the FRRG, uh, general public license.
Um, and I think we could probably change that to be,
or, uh, another license that, uh, has the same effect.
I don't, I don't know of one.
But, um, a, a, a license designed specifically for network service
software to ensure that users of services have the ability
to examine the source and implement their own services.
Um, uh, developers, we also encouraged, uh,
um, uh, to, to, to develop, to make freely license alternative
to existing popular non-free network services, right?
Um, and then, uh, um,
uh, also very important to develop software that can replace
centralized services and data storage with distributed software
and data deployment, giving control back users.
This idea being that even in a world that, that, that, with
many network services, if you're still dependent on someone else to run
your application for you, you are inherently in less control of your own,
excuse me, of your own computing than if, than if you,
you are running your software.
So, um, in many cases, uh, how do we, you know, uh,
we, we can say, you might want to run, uh,
uh, you might want to run, uh, an alternative to a network service.
Uh, we, we can tell the user that they might want to consider
running an alternative to a network service.
So, for example, if they're, uh,
running Miibo as their IAM client, we say,
maybe you want to download Pigeon and use that instead, uh,
really available, um, alternative, which does,
the same, uh, which does the same thing, uh, hard to do for,
you know, we can't say download the Facebook application and use that
instead of having to use the website, right?
Uh, but, but maybe if we think about how one might develop an application that,
that does that, and there'll be some, some discussion about that later this afternoon,
um, then we can, uh, then we can make that statement.
So, that's an important, um, way forward.
Uh, we asked service providers, we also spoke to service providers,
the second group, um, we asked them to choose free software for their service,
um, uh, fair enough, to release customizations of their software under,
uh, under a free software license, um, again, uh,
sort of, uh, just being good community members to make,
and, and also to make data and works of authorship available to the services
users under terms, uh, and informats that,
allow users to move and use their data outside the service.
Basically, this means that users should, um, have control of their private data,
and that, um, uh, data that's available to everyone should be available to everyone
under terms that allow them to use it and reuse it.
Um, uh, what this means is, of course, that, uh,
uh, is that, is that a service provider who releases a service in this way
will allow any user of the service to sort of fork in a sense, right?
If they become bad, or if they decide to change or if they just,
just, can no longer run the service, then presumably, uh,
uh, anyone, any, any, any user or, uh, could,
could become a service provider themselves.
They'd be able to take their own data, um, and,
and publicly available data and reproduce it elsewhere.
So, uh, these were our recommendations to service providers,
and then finally our recommendations for users were to,
first, consider very carefully whether to use software on someone else's computer at all, right?
So this is what I was, uh, uh,
uh, uh, alluding to earlier, that the choice of whether to use
a network service is an important one, and if it's possible,
um, you should use a free software equivalent to runs on your own computer.
Um, uh, and then, uh, also, uh, pointed out that, uh,
in deciding to use a network service, look for services to sort of, uh,
try to use services that are working more towards supporting the free software
community, uh, and, uh, uh, respecting user freedom in these sorts of ideas.
So, that, that was the Franklin Street statement.
Um, it was endorsed by, uh, quite a number of people, um,
and, and, uh, was an important sort of step forward,
I think, in terms of the, in terms of, uh,
being really explicit about what, what we think software freedom might be.
Now, um, in, in the realm of network services.
Now, the FSF has been, uh, uh, internally,
the FSF, uh, has been thinking about this for a while, um,
and, um, and, uh, considering sort of how,
how it wants to move forward with it.
And, um, it's actually working on, um, a draft, uh,
of a document, which is actually, uh, built very, uh,
uh, built very explicitly on, on, uh,
the, the Franklin Street statement.
Um, but that, uh, sort of, um, I think, I'd like to say,
improved the sort of, uh, adds to it, uh, adds to it in,
in a, in a couple of important ways.
And I can talk about that.
So, I should also say that this is, of course, not,
not FSF policy.
It's just sort of, uh, but it's a window into our sort of thinking.
And, uh, I hope that, uh, I hope that it's also an invitation to, uh,
to, to speak with myself, and with, uh,
uh, uh, other, other, um, you know, the other,
the other FSF board members, and other, and, uh,
uh, other, and staff at the FSF about, uh,
uh, about, uh, this policy, and about
how we should be thinking about this going forward.
So, um, uh, uh, uh, uh, uh.
Excuse me.
Uh, so, so the, the, the first and most important thing that we were,
um, thinking about, uh, that we've, uh, discussing
is the idea that there really are different classes of network services.
And that's something that was implicit in the frequency statement as well, right?
You say, consider using different ones, but what are the factors that one might consider?
And the most important distinction between different types of applications was one that was
this idea between what was sort of we were calling and many other people called software
as a service and other types of network applications.
So software as a service, of course, is at least as we're explicitly referring to it.
Meaning this practice is sort of providing substitutes for software that runs on a user's
computer with software that runs on a server.
This is that, in many ways, this is the sort of easiest class of the easiest class of
network services to deal with because these really are just applications that one
can choose to either run locally or one that can choose to run remotely.
And if one uses to run them remotely, they will be, even if it is free software, even
if they have access to data, they will be inherently disempowered.
So by breaking it up to the streets, we can deal with them separately.
It's important to note that for example, things like search engines or Wikipedia or Facebook
for that matter are not software as a service in the way that we are using the term, but
they are network services.
So we're referring to them as a subset by dealing with.
And the reason we do this is because they're sort of very important, practical and ethical
implications of software as a service is in particular.
So our first recommendation is going to be that for software as a service, the situation
is pretty clear.
Users who want to live in freedom should must reject any use of software as a service.
If the programs free software, then the software being run is under the service provider's
control, but it's never under the use of control.
So users should reject that.
And where possible, they should develop or release free software to do the same jobs as
the programs that are offered only as software as a service, right?
If it were free software, then this is pretty easy.
We can just download it and sort of distribute it.
So be really clear on that sort of distinction.
That was the first sort of step.
And then the second two things that we're doing is one prioritizing those different actions.
The frequency statement is this list of things that we think people should do, but I mean,
as we've found about this, not everything on that list is sort of equally important,
or more importantly, it's not equally applicable to alterations.
So being really extensive, so we had sort of two goals going forward.
One is to prioritize these different types of actions, right?
To say, so for example, in software and the service, in situations where someone is
talking about software and the service, it's more straightforward, and we can be really
explicit there.
And the second thing we can do is to make it really clear why certain actions are possible.
So the frequency statement says, do this, do this, do this, but it doesn't actually sort
of connect those actions to the real freedom benefits that people are going to be sort of
reaping from this potentially, right?
So we've been really explicit about that.
So we can understand both what doing these things like, you know, releasing stuff under
the AGBL does, but also so we can understand what it doesn't do.
Because of course, you know, there are real limits to everything in that list.
So we can say, for example, that most network services did not fall into the category of software,
services service.
So rejecting them outright is not necessary for maintaining your freedom.
However, these services can potentially have other problems.
The most reliable way to prevent these problems is to avoid the need for a common service.
So we recommend the developers first develop software that can replace centralized network
services and data storage with distributed software and data development.
So again, something coming from the Franklin Street statement.
But we also point out that users who carry out network services that service providers
can take steps to reduce some of the problems raised by network services and to help support
free software communities.
This is of course most of what the AGBL does.
It supports free software communities who are helping build applications by being more
cooperative and collaborative and which can help give competitive advantages to the
services which are going to be more free and going to empower users to build things.
So we can do things like recommend the use of the AGBL and recommend that people develop
and release really licensed alternatives.
And then we can of course, explicitly point out that there are some, there's a class
of recommendations which are in the Franklin Street statement which are basically trying
to avoid mistreatment of users by giving them control over their data.
We point that out but also point out the limitations to this, that control over one's data is
itself kind of an interesting term, does that mean that one has access to, that one has
access to it?
Certainly, you should want to be able to explore it.
What about keeping other people from having access to it?
And there's this problem that in many network services, for example, there are legal requirements
that the government can show up and say, give us all of your data and there's nothing
that a third party can do and sometimes they can't even tell the user that it's done.
So making explicit that even in situations where a service provider has the best intentions
that there are real limitations to over what a user might be able to do.
But we end up making, I think all of the same in the current draft at least, we're making
all the same recommendations but in this sort of different way where we're doing making
these sorts of distinction and prioritizations.
So this is an ongoing process, we'll see where it ends up.
Of course it's possible that we'll hit a red block and we'll have to sit on this for
a while longer.
But I can say that this issue, network services and software freedom, insofar as it's an
increasingly large part of the world of software use, maybe not entirely representative of
people in this room.
But I think that it is representative of the way that people are using software more broadly.
And as a result, this is an issue that the foundation as an institution, the sort of
the board and the staff really care about because our goal, of course, is not limited to
the way that we've produced software in the past.
We're talking, our issue, ultimately the free software foundation is about technological
empowerment.
It's about ensuring that users of software have control over their software.
And the fact that it makes things more complicated when people start using those software in very
different ways or developing software in very different ways because it means that we have
to rethink some of the things that we've been able to take for advantage for a long time.
But this is certainly an issue that I and others in the FSF have been putting a lot of energy
and thought into it.
And I really look forward to continuing this conversation, both this afternoon, there'll
be at least one more talk on the topic that's a lot more specific.
And then also tomorrow in the sort of on-confer session where hopefully we'll be able to make
some real progress on some of these important issues, things like building distributed systems
or so there's some technical issues, there's electrical issues.
I think this is something that the free software's a community can really come together as
a whole and help lead the path forward.
So thanks for putting up with me and my voice.
I hope you have as much good news to report next year.
So thanks everyone.
So yeah, I mean, there's, yeah, great, so let's see.
So who has questions?
Let's, if we can, let's go here, here, here, here.
Okay, so yes.
If you don't have access to the network,
I mean, it's absolutely true that access to, there is uneven access to lots of public
services, and I think that that is an important issue.
I agree.
Yeah, I mean, I absolutely right.
Yeah, that's a, that's a, that's a great point.
All right.
Yes, up here, and then next.
So there's our communications here and the complexities that go beyond this simple software
freedom issues, but can you now or do you hope to be able to give something
comparable to the four software freedoms? I mean, maybe they're like the eight
network software freedoms or something. I mean, it would be really helpful to
be able to ultimately boil it down. Of course, there are always going to be
edge cases and complexities and significances. So I think that that's
personally, that's that's absolutely a goal of mine. Now, I think that the
first, the most important, we started out, I mean, with explicitly that goal, it
was like, great, we're going to bring together like eight smart people and we'll
have the definition of network freedom tomorrow. And what we realized really
on was that one important issue is that when we say network services, we're
actually referring to a really wide variety of different things. So I think
that the most important steps that we've been taking in the last several
months has been being really explicit about what we about what we mean
by network service. Or if one definition isn't actually, if one, if there's
not a singular concept of network services that needs to be treated a
particular way, then we need to break the stuff and treat it differently. The
idea, I mean, like the analogy would be like that, that, you know, if we don't
define what software is, right, than talking about free software is, is, I mean,
there are people who define software differently, right, and have come to
very kind of confusing results when they try to apply issues of software freedom.
So, so, so, so, so, so, yes, it is absolutely a goal of mine to work, to work
towards that that said, it's, it's it's worth being, I mean, the, the
opposite definitions of what software freedom means in particular, in
particular situations carry a lot of weight and it's something that we don't
want to get wrong. I think that we're a lot closer to that this year than we
were last year, I think that we're making, I think that by, by, that we're able to speak
very explicitly about, um, with, with explicit sort of statements about users who care about
freedom in this context, must reject software as a service, right? At least as we're defining
it in this situation. We're, we're getting close to being able to make a couple, to, to
making several very explicit statements like that. And I think that as we sort of are able
to, um, wrap our head around the world of, uh, network services, we're going to be able to speak,
um, in terms like definitions, um, about at least parts of these world, and I think that over time,
we'll, uh, we're, we're absolutely getting a better handle on that. So, so, yeah, I mean, that's,
that's, um, um, it's, it's absolutely a goal that said, um, uh, we're not going to get it wrong.
So, uh, uh, if that means we take a little bit longer to we're doing that. There was, there was a,
there was a question in the center first, and then there was a question here, and there was a
question up there. Okay. Yes. Um, uh, absolutely. Um, in fact, not only I've given it, uh, I've also
written, uh, uh, free software application for doing, uh, voting, uh, voting machinery. So, um, uh,
personally, uh, so, so yes, um, that's an issue that I care about a lot. Um, there, there are some
important issues with, um, I mean, like,
uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh
uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh
uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh
uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh
uh, uh, um uh, uh, um uh, uh, uh, uh, uh, uh uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh uh, uh, uh, uh uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh..... uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh uh, uh uh, uh, uh, uh