https://lwn.net/Articles/713073/ by Matija Šuklje
Last year, three new umbrella organizations for free and open-source
software (and hardware) projects emerged in Europe. Their aim is to
cater to the needs of the community by providing a legal entity for
projects to join, leaving the projects free to focus on technical and
community tasks. These organizations (Public Software CIC, [The Commons
Conservancy], and the Center for the Cultivation of Technology) will
take on the overhead of actually running a legal entity themselves.
Among other services, they offer to handle donations, accounting,
grants, legal compliance, or even complex governance for the projects
that join them. In my opinion (and, seemingly, theirs) such services are
useful to these kinds of projects; some of the options that these three
organizations bring to the table are quite interesting and inventive.
The problem
As a free/open-source software (FOSS) or open-source hardware project
grows, it is likely to reach a point where it requires a legal entity
for better operation — whether to gather donations, pay for development,
handle finances, organize events, increase license predictability and
flexibility by consolidating rights, help with better governance, or for
other reasons. For example, when a project starts to hold assets —
domain names, trademarks, or even just receives money through donations
— that should not be the responsibility of one single person, but
should, instead, be handled by a legal entity that aligns with the
project's goals. A better idea is to have an entity to take over this
tedious, but needed, overhead from the project and let the contributors
simply carry on with their work.
So far, the options available to a project are either to establish its
own organization or to join an existing organization, neither of which
may fit well for the project. The existing organizations are either
specialized in a specific technology or one of the few
technology-neutral umbrella organizations in the US, such as Software in
the Public Interest, the Apache Software Foundation, or the Software
Freedom Conservancy (SFC). If there is already a technology-specific
organization (e.g. GNOME Foundation, KDE e.V., Plone Foundation) that
fits a project's needs, that may well make a good match.
The problem with setting up a separate organization is that it takes
ongoing time and effort that would much better be spent on the project's
actual goals. This goes double and quadruple for running it and meeting
with the annual official obligations — filling out tax forms, proper
reporting, making sure everything is in line with internal rules as well
as laws, and so on. To make matters worse, failure to do so might result
in personal liability for the project leaders that can easily reach
thousands or tens of thousands of euros or US dollars.
Cross-border donations are tricky to handle, can be expensive if a
currency change is needed, and are rarely tax-deductible. If a project
has most of its community in Europe, it would make sense to use a
European legal entity.
What is common between all three new European organizations is that none
demand a specific outbound license for the projects they manage (as
opposed to the Apache Software Foundation, for example), as long as it
falls under one of the generally accepted free and open licenses. The
organizations must also have internal rules that bind them to act in the
public interest (which is the closest approximation to FOSS you can get
when it comes to government authorities). Where they differ is the set
of services they offer and how much governance oversight they provide.
Public Software CIC
Public Software CIC incorporated in February 2016 as a UK-based
Community Interest Company. It is a fiduciary sponsor and administrative
service provider for free and open source projects — what it calls
public software — in Europe.
While it is not for profit, a Community Interest Company (CIC) is not a
charity organization; the other two new organizations are charities. In
the opinion of Public Software's founders, the tax-deductibility that
comes with a charitable status does not deliver benefits that outweigh
the limitations such a status brings for smaller projects. Tax recovery
on cross-border charitable donations is hard and expensive even where it
is possible. Another typical issue with charities is that even when
for-profit activities (e.g. selling T-shirts) are allowed, these are
throttled by law and require more complex accounting — this situation
holds true both for most European charities and for US 501(c)(3)
charitable organizations.
Because Public Software CIC is not a charity, it is allowed to trade and
has to pay taxes if it has a profit at the end of its tax year. But as
Simon Phipps, one of the two directors, explained at a panel at QtCon /
FSFE Summit in September 2016, it does not plan to have any profits in
the first place, so that is a non-issue.
While a UK CIC is not a charity and can trade freely, by law it still
has to strictly act for public benefit and, for this reason, its assets
and any trading surplus are locked. This means that assets (e.g.
trademarks, money) coming into the CIC are not allowed to be spent or
used otherwise than in the interests of the public community declared at
incorporation. For Public Software, this means the publicly open
communities using and/or developing free and open-source software (i.e.
public software). Compliance with the public interest for a CIC also
involves approval and monitoring by the Commissioner for Community
Interest Companies, who is a UK government official.
The core services Public Software CIC provides to its member projects are:
accounting, including invoicing and purchasing
tax compliance and reporting
meeting legal compliance
legal, technical, and governance advice
These are covered by the base fee — 10% of project's income. This
percentage seems to have become the norm (e.g. Software Freedom
Conservancy charges the same). Public Software will also offer
additional services (e.g. registering and holding a trademark or domain
name), but for these there will be additional fees to cover costs.
On the panel at QtCon, Phipps mentioned that it would also handle
grants, including coordinating and reminding its member projects of
deadlines to meet. But it would not write reports for the grants nor
would it give loans against future payments from grants. Because many
(especially EU) grants only pay out after the sponsored project comes to
fruition, a new project that is seeking these grants should take this
restriction into consideration.
Public Software CIC already hosts a project called Travel Spirit as a
member and has a few projects waiting in the pipeline. While its focus
is mainly on newly starting projects, it remains open to any project
that would prefer a CIC. At QtCon, Phipps said that he feels it would be
the best fit for smaller-scale projects that need help with setting up
governance and other internal project rules. My personal (and
potentially seriously wrong) prediction is that Public Software CIC
would be a great fit for newly-established projects where a complex
mishmash of stake holders would have to be coordinated — for example
public-private collaborations.
A distinct feature of Public Software CIC is that it distinguishes
between different intangible assets/rights and has different rules for
them. The basic premise for all asset types is that no other single
organization should own anything from the member project; Public
Software is not interested in being a "front" for corporate open source.
But then the differences begin. Public Software CIC is perfectly happy
and fit to hold trademarks, domain names, and such for its member
projects (in fact, if a project holds a trademark, Public Software would
require a transfer). But on the other hand, it holds a firm belief that
copyright should not be aggregated by default and that every developer
should hold the rights to their own contribution if they are willing.
Apart from FOSS, the Public Software CIC is also open to open-source
hardware or any free-culture projects joining. The ownership constraint
might in practice prove troublesome for hardware projects, though.
Public Software CIC does not want to actively police license/copyright
enforcement, but would try to assist a member project if it became
necessary, as far as funds allowed. In fact when a project signs the
memorandum of understanding to join the Public Software CIC, the
responsibility for copyright enforcement explicitly stays with the
project and is not transferred to the CIC. On the other hand, it would,
of course, protect the other assets that it holds for a project (e.g.
trademarks).
If a project wants to leave at some point, all the assets that the CIC
held for it have to go to another asset-locked organization approved by
the UK's Commissioner of CICs. That could include another UK CIC or
charity, or an equivalent entity elsewhere such as a US 501(c)(3).
If all goes wrong with the CIC — due to a huge judgment against one of
its member projects or any other reason — the CIC would be wound down
and all the remaining member projects would be spun out into other
asset-locked organization(s). Any remaining assets would be transferred
to the FSFE, which is also a backer of the CIC.
[The Commons Conservancy]
[The Commons Conservancy] (TCC) incorporated in October 2016 and is an
Amsterdam-based Stichting, which is a foundation under Dutch law. TCC
was set up by a group of technology veterans from the FOSS, e-science,
internet-community, and digital-heritage fields. Its design and
philosophy reflects lessons learned in over two decades of supporting
FOSS efforts of all sizes in the realm of networking and information
technology. It is supported by a number of experienced organizations
such as NLnet Foundation (a grant-making organization set up in the
1980s by pioneers of the European internet) and GÉANT (the European
association of national education and research networks).
As TCC's chairman Michiel Leenaars pointed out in the QtCon panel, the
main goal behind TCC is to create a no-cost, legally sound mechanism to
share responsibility for intangible assets among developers and
organizations, to provide flexible fundraising capabilities, and to
ensure that the projects that join it will forever remain free and open.
For that purpose it has invented some rather ingenious methods.
TCC concentrates on a limited list of services it offers, but wants to
perfect those. It also aims at being lightweight and modular. As such,
the basic services it offers are:
assurance that the intangible assets will forever remain free and open
governance rules with sane defaults (and optional additions)
status to receive charitable donations (to an account at a different
organization)
TCC requires from its member projects only that their governance and
decision-making processes are open and verifiable, and that they act in
the public benefit. For the rest, it allows the member projects much
freedom and offers modules and templates for governance and legal
documents solely as an option. The organization strongly believes that
decisions regarding assets and money should lie with the project,
relieving the pressure and dependency on individuals. It promotes best
practices but tries to keep out of the project's decisions as much as
possible.
TCC does not require that it hold intangible assets (e.g. copyrights,
trademarks, patents, design rights) of projects, but still encourages
that the projects transfer them to TCC if they want to make use of the
more advanced governance modules. The organization even allows the
project to release binaries under a proprietary license, if needed, but
under the strict condition that a full copy of the source code must
forever remain FOSS.
Two of the advanced modules allow for frictionless sharing of intangible
assets between member projects regardless whether the outbound licenses
of these projects are compatible or not. The "Asset Sharing DRACC" (TCC
calls its documents "Directives and Regulatory Archive of [The Commons
Conservancy]" or DRACC) enables developers to dedicate their
contributions to several (or all) member projects at the same time. The
"Programme Forking DRACC" enables easy sharing of assets between
projects when a project forks, even though the forks might have
different goals and/or outbound licenses.
As further example, the "Hibernation of assets DRACC" solves another
common issue — namely how to ensure a project can flourish even after
the initial mastermind behind it is gone. There are countless projects
out there that stagnated because their main developer lost interest,
moved on, or even died. In this module there are special rules in place
to handle a project that has fallen dormant and how the community can
revive a project afterward to simply continue the development. There are
more such optional rule sets available for projects to adopt; including
rules how to leave TCC and join a different organization.
This flexibility is furthered by the fact that by design TCC does not
tie the project to any money-related services. To minimize risks, [The
Commons Conservancy] does not handle money at all — its statutes
literally even forbid it to open a bank account. Instead, it is setting
up agreements with established charitable entities that are specialized
in handling funds. The easiest option would be to simply use one of
these charities to handle the project's financial back-end (e.g. GÉANT
has opted for NLnet Foundation), but projects are free to use any other
financial back-end if they so desire.
Not only is the service TCC offers compatible with other services, it is
also free as in beer, so using TCC's services in parallel with some
other organization to handle the project's finances does not increase a
project's costs.
TCC is able to handle projects that receive grants, but will not manage
grants itself. There are plans to set up a separate legal entity to
handle grants and other activities such as support contracts, but
nothing is set in stone yet. For at least a subset of projects it would
also be possible to apply for loans in anticipation of post-paid (e.g.
EU) grants through NLnet.
A project may easily leave TCC whenever it wants, but there are checks
and balances set in place to ensure that the project remains free and
open even if it spins out to a new legal entity. An example is that a
spun out (or "Graduated" as it is called in TCC) project leaves a
snapshot of itself with TCC as a backup. Should the new entity fail, the
hibernated snapshot can then be revived by the community.
TCC is not limited to software — it is very much open to hosting also
open hardware and other "commons" efforts such as open educational
resources.
TCC does not plan to be involved in legal proceedings — whether filing
or defending lawsuits. Nor is it an interesting target, simply because
it does not take in or manage any money. If anything goes wrong with a
member project, the plan is to isolate that project into a separate
legal entity and keep a (licensed) clone of the assets in order to
continue development afterward if possible.
Given the background of some of the founders of TCC (with deep roots in
the beginnings of the internet itself), and the memorandum of
understanding with GÉANT, it is not surprising that some of the first
projects to join are linked to research and core network systems (e.g.
eduVPN and FileSender). Its offering seems to be an interesting
framework for already existing projects that want to ensure they will
remain free and open forever; especially if they have or anticipate a
wider community of interconnected projects that would benefit from the
flexibility that TCC offers.
The Center for the Cultivation of Technology
The Center for the Cultivation of Technology (CCT) also incorporated in
October 2016, as a German gGmbH, which is a non-profit limited-liability
corporation. Further, the CCT is fully owned by the Renewable Freedom
Foundation.
This is an interesting set-up, as it is effectively a company that has
to act in public interest and can handle tax-deductible donations. It is
also able to deal with for-profit/commercial work, as long as the profit
is reinvested into its activities that are in public benefit. Regarding
any activities that are not in the public interest, CCT would have to
pay taxes. Of course, activities in the public interest have to
represent the lion's share in CCT.
Its owner, the Renewable Freedom Foundation, in turn is a German
Stiftung (i.e. foundation) whose mission is to "protect and preserve
civil liberties, especially in the digital landscape" and has already
helped fund projects such as Tor, GNUnet, and La Quadrature du Net.
While a UK CIC and a German gGmbH are both limited-liability
corporations that have to act in the public interest, they have somewhat
different legal and tax obligations and each has its own specifics.
CCT's purpose is "the research and development of free and open
technologies". For the sake of public authorities it defines "free and
open technologies" as developments with results that are made
transparent and that, including design and construction plans, source
code, and documentation, are made available free and without licensing
costs to the general public. Applying this definition, the CCT is
inclusive of open-source hardware and potentially other technological
fields.
Similar to the TCC, the CCT aims to be as lightweight by default as
possible. The biggest difference, though, is that the Center for the
Cultivation of Technology is first and foremost about handling money —
as such its services are:
accounting and budgeting
financial, tax and donor reporting
setting up and managing of donations (including crowd-funding)
grant management and reporting
managing contracts, employment and merchandise
The business model is similar to that of PS CIC in that, for basic
services, CCT will be taking 10% from incoming donations and that more
costly tasks would have to be paid separately. There are plans to
eventually offer some services for free, which would be covered by
grants that CCT would apply for itself. In effect, it wants to take over
the whole administrative and financial overhead from the project in
order to allow the projects to concentrate on writing code and managing
themselves.
Further still, the CCT has taken upon itself automation, as much as
possible, both through processes and software. If viable FOSS solutions
are missing, it would write them itself and release the software under a
FOSS license for the benefit of other FOSS legal entities as well.
As Stephan Urbach, its CEO, mentioned on the panel at QtCon, the CCT is
not just able to handle grants for projects, but is also willing to take
over reporting for them. Anyone who has ever partaken in an EU (or
other) grant probably agrees that reporting is often the most painful
part of the grant process. The raw data for the reports would, of
course, still have to be provided by the project itself. But the CCT
would then take care of relevant logistics, administration, and writing
of the grant reports. The company is even considering offering loans for
some grants, as soon as enough projects join to make the operations
sustainable.
In addition, the Center for the Cultivation of Technology has a
co-working office in Berlin, where member projects are welcome to work
if they need office space. The CCT is also willing to facilitate
in-person meetings or hackathons. Like the other two organizations, it
has access to a network of experts and potential mentors, which it could
resort to if one of its projects needed such advice.
Regarding whether it should hold copyright or not, the Center for the
Cultivation of Technology is flexible, but at the very beginning it
would primarily offer holding other intangible assets, such as domain
names and trademarks. That being said, at least in the early phase of
its existence, holding and managing copyright is not the top priority.
Therefore the CCT has for now deferred the decision regarding its
position on license enforcement and potential lawsuit strategy.
Accounting, budgeting, and handling administrative tasks, as well as
automation of them all, are clearly where its strengths lie and this is
where it initially wants to pour most effort into.
Upon a dissolution of the company, its assets would fall to Renewable
Freedom Foundation.
Since the founders of CCT have deep roots in anonymity and privacy
solutions such as Tor, I imagine that from those corners the first wave
of projects will join. As for the second wave, it seems to me that CCT
would be a great choice for projects that want to offload as much of
financial overhead as possible, especially if they plan to apply for
grants and would like help with applying and reporting.
Conclusion
2016 may not have been the year of the Linux desktop, but it surely is
the year of FOSS umbrella organizations. It is an odd coincidence that
at the same time three so different organizations have popped up in
Europe — initially oblivious of each other — to provide much-needed
services to FOSS projects.
Not only are FOSS projects spoiled for choice regarding such service
providers in Europe, now, but it is refreshing to see that these
organizations get along so well from the start. For example, Simon
Phipps is also an adviser at CCT and I help with both CCT and TCC.
In fact, I would not be surprised to see, instead of bitter competition,
greater collaboration between them, allowing each to specialize in what
it does best and allowing the projects to mix-and-match services between
them. For example, I can see how a project might want to pick TCC to
handle its intangible assets, and at the same time use CCT to handle its
finances. All three organization have also stated that, should a project
contact them that they feel would be better handled by one of the
others, they would refer it to that organization instead.
Since at least the legal and governance documents for CCT and TCC will
be available online under a free license (CC0-1.0 and CC-By-4.0
respectively), cross-pollination of ideas and even setting up of new
organizations would hereby be made easier. It may be early days for
these three umbrella organizations, but I am quite optimistic about
their usefulness and that they will fill in the gaps left open by the
older US siblings and single-project organizations.
If a project comes to the conclusion that it might need a legal entity,
now is a great time to think about it. At FOSDEM 2017 there will be
another panel with CCT, TCC, PS CIC, and SFC that will be a perfect
opportunity to pose any and all questions and comments you may have in
person.
https://lwn.net/Articles/713073/
Hi FSFE community,
those of you who do develop Free Software privately or that are still
thinking about realising a project, could be interested in the Prototype
Fund:
https://prototypefund.de/en/
it is a project by the Open Knowledge Foundation and the German Ministry
of Education and Research where developers can apply for up to 30.000
Euros in half a year so they can concentrate on coding. The only
restriction it has is to have a living place in Germany (although you
can move here for this half of a year if I understood correctly). Else,
it comes with less formalia as possible.
Best regards,
Erik
--
No one shall ever be forced to use non-free software
Erik Albers | Free Software Foundation Europe
OpenPGP Key-ID: 0x8639DC81 on keys.gnupg.net
Earlier this month, there was some talk of the "free software company"
and what that might mean.
I work in an interesting variant of this concept, namely in a company
(the Danish company Magenta, see magenta.dk) which, according to its
mission statement, may only deliver software under an OSI-approved
license, practically speaking either GPL or LGPL version 3 or Mozilla
Public License version 2.
It's not a "free software company" in the sense that we only *use* free
software - new employees are free to choose their operating system and
favorite programs, and while most developers use GNU/Linux, some prefer
OSX or Windows, and that's completely OK. What matters is that none of
the software that we deliver to customers is under a non-free license.
I wrote a blog post about that, and I hope to be able to elaborate on
our practical work with free software in future posts:
http://blogs.fsfe.org/agger/2017/01/24/working-with-free-software/
Hello everybody,
I recently had a discussion which made me wonder: does anyone of you
know someone who was directly threatened with software patents; either
someone in the function as a volunteer contributor to Free Software, or
self-employed? To clarify: it is not about companies being threatened
with patents, but about threats to individual contributors.
If so, would you be able to ask them to get in contact with me? I will
of course handle all of that confidential. Currently I am mainly
interested how often that happens and in which areas.
Thank you,
Matthias
--
Matthias Kirschner - President - Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290
Registered at Amtsgericht Hamburg, VR 17030 | (fsfe.org/join)
Contact (fsfe.org/about/kirschner) - Weblog (k7r.eu/blog.html)
I just published a blog post about a topic we discussed at the FSFE's
last general assembly. Please let me know what you think about it.
Looking forward to your feedback.
(The text is also online available under
<http://k7r.eu/there-is-no-free-software-company-but/>. Feel free to
share it so we get a wide range of feedback.)
# There is no Free Software company - But!
Since the start of the FSFE 15 years ago, the people involved were certain that
companies are a crucial part to reach our goal of software freedom. For many
years we have explained to companies – IT as well as non-IT – what benefits
they have from Free Software. We encourage individuals and companies to pay for
Free Software, as much as we encourage companies to use Free Software in their
offers.
While more people demanded Free Software, we also saw more companies claiming
something is Free Software or Open Source Software although it is not. This
behaviour – also called *"openwashing"* is nothing special for Free Software,
some companies also claim something is "organic" or "fair-trade" although it is
not. As the attempts to get a trademark for "Open Source" failed, it is
difficult to legally prevent companies from calling something "Free Software"
or "Open Source Software" although it does neither comply with the Free
Software definition by the Free Software Foundation nor with the Open Source
definition by the Open Source Initiative.
When the FSFE was founded in 2001 there was already the idea to encourage and
support companies making money with Free Software by starting a "GNU business
network". One of the stumbling blocks for that was always the definition of a
Free Software company. It cannot just be the usage of Free Software or the
contribution to Free Software, but also needs to include what rights they are
offering their customers. Another factor was whether the revenue stream is tied
to proprietary licensing conditions. Would we also allow a small revenue from
proprietary software, and how high is that that you can still consider it a
Free Software company?
It turned out to be a very complicated issue, and although we were regularly
discussing it we did not have an idea how to approach the problems in defining
a Free Software company.
During our last meeting of the FSFE's General Assembly we came to the
conclusion that there was a flaw in our thinking and that it does not make
sense to think about "Free Software companies". In hindsight it might look
obvious, but for me the discussion was an eye opener, and I have the feeling
that was a huge step for software freedom.
As a side note: When we have the official general assembly of the FSFE we
always use this opportunity to have more discussions during the days before or
after. Sometimes they focus on internal topics, organisational changes, but
often there is brainstorming abut the "hot topics of software freedom" and
where the FSFE has to engage in the long run. At this year's meeting, from 7 to
9 October, inspired by Georg Greve's and Nicola Diedrich's input, we spent the
whole Saturday thinking about the long term challenges for software freedom
with the focus on the private sector.
We talked about the challenges of software freedom presented by economies of
scale, networking effects, investment preference, and users making convenience
and price based decisions over values – even when they declare themselves
value conscious.
One problem preventing a wider spread of software freedom identified there was
that Free Software is being undermined by companies that abuse the positive
brand recognition of Free Software / Open Source by "openwashing" themselves.
Sometimes they offer products that do not even have a Free Software version.
This penalises companies and groups that aim to work within the principles of
Free Software and damages the recognition of Free Software / Open Source in the
market. The consequence is reduced confidence in Free Software, fewer
developers working on it, fewer companies providing it, and less Free Software
being written in favour of proprietary models.
In the discussion, one question kept arising. Is an activity that is good for
Free Software which is done by one small company as their sole activity more
valuable than if the same thing were done as part of a larger enterprise? We
all agree that a small company which is using and distributing exclusively Free
Software, and has done so for many years, and no part of the software they
wrote or included was ever non-free software is good. But what happens if said
small, focused company got purchased by a larger entity? Does that invalidate
the benefit of what is being done?
We concluded that good action remains good action, and that the FSFE should
encourage good actions. *So instead of focusing on the company as such we
should focus on the activity itself*; we should think about ***"Free Software
business activities", "Free Software business offers"***, and such. My feeling
was that this was the moment the penny had dropped, while others and me
realised the flaw in our previous thinking. We need action oriented approaches
and we need to look at activities individually.
There was still the question where to draw the line between acceptable or
useful activities and harmful ones. This is not a black and white issue, and
when assessing the impact for software freedom there are different levels. For
example if you evaluate a sharing platform, you might find out that the core is
Free Software, but the sharing module itself is proprietary. This is a bad
offer if you want to run a competing sharing platform using Free Software.
The counter example of an acceptable offer was a collaboration software that
was useful and complete, but where connecting a proprietary client would itself
require a proprietary connector. It was also discussed that sometimes you need
to interface with proprietary systems through proprietary libraries that do not
allow connecting with Free Software unless one were to first replace the entire
API/library itself.
Ultimately a consensus emerged around a focus on the four freedoms of Free
Software in relation to the question of whether the software is sufficiently
complete and useful to run a competing business.
One thought was to run "test cases" to evaluate how good an offer is on the
Free Software scale. Something like a regular bulletin about best and worst
practice. We could look at a business activities and study it according to the
criteria below, evaluate it, making that evaluation and its conclusions public.
That way we can help to build customer awareness about software freedom. Here
is a first idea for a scale:
* EXCELLENT: Free Software only and on all levels, no exceptions.
* GOOD: Free Software as a complete, useful, and fully supportable product.
Support available for Free Software version.
* ACCEPTABLE: Proprietary interfaces to proprietary systems and applications,
especially complex systems that require complex APIs/libraries/SDKs, as long
as the above is still met.
* BAD: Essential / important functionality only available proprietary, critical
functionality missing from Free Software (one example for an essential
functionality was LDAP connector).
* EVIL: Fully proprietary, but claiming to be Free Software / Open Source
Software.
**Now I would like to know from you:** what is your first reaction on this?
Would you like to add something? Do you have ideas what should be included in a
checklist for such a test? Would you be interested to help us to evaluate how
good some offers are on such a scale?
To summarise, I believe it was a mistake to think about businesses as a whole
before and that if we want to take the next big steps we should think about
Free Software business offers / activities – at least until we have a better
name for what I described above. We should help companies that they are not
deluded by people just claiming something is Free Software, but give them the
tools to check themselves.
--
Matthias Kirschner - President - Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290
Registered at Amtsgericht Hamburg, VR 17030 | (fsfe.org/donate)
Contact (fsfe.org/about/kirschner) - Weblog (k7r.eu/blog.html)
I accidentally did not "reply all" this morning when sending this ...
---------- Forwarded message ----------
From: Charles Cossé <ccosse(a)gmail.com>
Date: Tue, Jan 10, 2017 at 6:17 AM
Subject: Re: Project to stimulate Edu-FLOSS development
To: Bastien Guerry <bzg(a)gnu.org>
Hi Bastien & All,
On Tue, Jan 10, 2017 at 1:26 AM, Bastien Guerry <bzg(a)gnu.org> wrote:
> I am not sure I completely grasp the relations between users and
> developers in your idea.
Here is an ASCII diagram which needs to be viewed in fixed-width font:
+-----------------------------+
| |
| EDU-FLS DEVELOPER COMMUNITY |
| |
| Dual-Purposed Javascript |
| FLS Activities |
| |
| 1. As Activity Plugin: |
| |
| Busking For Percentages |
| Of Subscription Fees |
| Creates Incentive |
| |
| 2.Indep of Online Website |
| Listed in FSD |
| |
+-----------------------------+
+-----------------------------+
| |
| ONLINE WEBSITE |
| |
| *Subscription Service* |
| |
| Whitelisted by DEVICE@HOME |
| Credit-Transfer API |
|-----------------------------|
| |
| +---------------------+ |
| | DEVELOPER ACCOUNT | |
| |---------------------| |
| | Maintain Activities | |
| | | |
| | Interact w/Users | |
| | | |
| | Get Compensated | |
| | | |
| |---------------------| |
| |
| +---------------------+ |
| | PARENT ACCOUNT | |
| |---------------------| |
| | Login from Anywhere | |
| | | |
| | Configure & Queue | |
| | Activities | |
| |NoSQL w/Credits,Queue| |
| | | |
| |Subscription Distri- | |
| | -bution Interface | |
| +---------------------+ |
| |
| +---------------------+ |
| | KID ACCOUNT | |
| |---------------------| |
| | Login from Home | |
| | | |
| | Complete Activities | |
| | In Queue | |
| |NoSQL w/Credits,Queue| |
| +---------------------+ |
| |
+-----------------------------+
+-----------------------------+
| |
| DEVICE @ HOME |
| |
| WiFi Access Point |
| Firewall w/Whitelist |
| Credit-Transfer API |
| |
| Local Web Server |
|-----------------------------|
| |
| |
| +---------------------+ |
| | KID ACCOUNT | |
| |---------------------| |
| | Credit-Meter UI | |
| | | |
| | NoSQL w/Credits,List| |
| | of Devices: XBox etc| |
| +---------------------+ |
| |
+-----------------------------+
The device at home is a tool for parents. A parent could award
credits for doing dishes, for example. The kid needs to access
the internet via the device. But the device runs a firewall which
only lets them access whitelisted sites unless they use credits.
To use credits they browse to the website broadcast by the device
and run the "credit-meter" web application. It's just a Javascript
application which controls the firewall and manages their credit
balance.
The online website lets them earn credits by completing activities.
The parent can configure and assign them from work, and the kids
can get there from home because the device's firewall allows access
to that site, i.e. the site is whitelisted.
It turns out that kids will do anything for those credits, and thus there
is this huge potential to supplement their education through these
activities. It's different that Kahn academy, for example, because
this compels them to make an effort. Their motivation is to earn
credits for internet access, but the end result is still that they focus
and make a real effort.
If there were a bunch of good activities then this would be a service
worth paying for. How to attract contributors? What's in it for them?
Require the parents to pay a subscription for unlimited access, but
allow them to distribute their subscription to the developers of their
choice. It creates a new market for education software, bringing
the parent and developer communities together and keeping the
interaction between them alive due to healthy competition for some
percentage of those subscription fees.
The ultimate goal is to create a whole bunch of new Edu-FLS. Thus
it seems reasonable that FSF would be interested to run a campaign
advocating the whole thing. The rest is details that have solutions.
Would you like me to set up a call with Lionel Laské about Sugarizer
> and your ideas?
>
Yes, that would be great! I will send a separate email ...
> I'm skeptical on whether it's worth looking for endorsement, would it
> be from FSF, FSFE or any other organization.
>
My thinking is that if RMS agrees that it's a good thing, and authorizes
an FSF campaign, then the important message is sent and FSF/* can
consider participation.
Let me understand more about the "equation" in a call some day!
>
I would definitely like to talk by phone. I will send that separate email.
Thanks,
-Charles
--
Linkedin <https://www.linkedin.com/in/charles-cosse> | E-Learning
<http://www.asymptopia.org>
Dear all,
I wish you a happy new year!
Yesterday, we published and submitted to the European Commission a
Position Paper for the endorsement of Free Software and Open Standards
in Horizon 2020 (and all publicly-funded research), as part of the
ongoing public consultation on the midterm evaluation of Horizon 2020,
the biggest research funding program in Europe ** open till 15.01.2017
**.[1]
The results of the consultation will define the 2018-2020 Horizon 2020
strategic goals as well as the post-Horizon 2020 framework funding
programs.
You can read the relevant news item here:
https://fsfe.org/news/2017/news-20170105-01.en.html and take a look at
the position paper itself here:
https://fsfe.org/activities/policy/eu/Horizon2020-Position-Paper.en.html
If you wish to contribute to the consultation, as an individual or as an
organisation, or share the position paper, there is a dedicated wiki
page with tips:
* Wiki page:
https://wiki.fsfe.org/Activities/OpenScience_InterimEvaluation_Horizon2020
We strongly encourage everyone to participate to the consultation! Every
single submitted questionnaire matters! Feedback is highly appreciated,
as always. Feel free to share!
Kind regards,
Olga
[^1]:
https://ec.europa.eu/research/consultations/interim_h2020_2016/consultation…
--
Olga Gkotsopoulou - Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, t +49-30-27595290
Become a volunteer translator: fsfe.org/contribute/translators
Spread the word: fsfe.org/contribute/spreadtheword
I'd like to get some feedback about some ideas floating around my head
at the moment, and thought that some of you might be able to help here.
I was talking with some people who would like to fund some concrete Free
Software activities, focusing on research and education.
One idea which came up is to support pupils to learn more about how
computer work, and promote hacking by providing "science packs" with
small hackable computers, and some modules, sensors etc.
What do you think about making it easier for pupils to get access to
such tools. E.g. by having some packs in the libraries or for school
projects?
I would be interested what you think about that, as I am not yet sure
about it.
If you like it, do you have an idea how you could make sure that
children who are interested in that are connected around Europe? (E.g.
in Germany there is something called "Jugend hackt" -- youth is hacking
-- Is there something similar on a EU level? Or are there other ideas?)
Thanks for your feedback,
Matthias
--
Matthias Kirschner - President - Free Software Foundation Europe
Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290
Registered at Amtsgericht Hamburg, VR 17030 | (fsfe.org/join)
Contact (fsfe.org/about/kirschner) - Weblog (k7r.eu/blog.html)