LWN.net Weekly Edition for February 2, 2017
The Inkscape 0.92 release
On January 4, the Inkscape project released the latest stable version of its open-source vector-graphics editor. Version 0.92 adds a new tool for creating flexible color gradients that can vary with almost arbitrary complexity and it adds new capabilities to many of its existing drawing tools. There are new features to be found in the set of bundled extensions and path effects, as well as important updates to font features and to the application's ability to tune the XML objects in a scalable vector graphics (SVG) file. There are also some changes to how Inkscape handles some core document properties, however — changes that are mandatory if Inkscape is to fully support the SVG specification, but that might trip up unsuspecting users.The 0.92 release was accompanied by a detailed set of release notes on the Inkscape wiki. The project has long required developers who check in new features to document those features in the upcoming release-notes page, an admirable practice that other free-software projects would do well to consider. If anything, the wiki page for a new release can veer toward being overly detailed but, on the other hand, there is never a last-minute scramble to write release notes from memory and risk accidentally leaving out something important.
As one would expect, the release itself is available to download for Linux, Mac OS X, and Windows. In addition to the usual packaging options, there is also a self-contained snap bundle available courtesy of Ted Gould (who is a member of both the Inkscape and snap teams). Ubuntu, of course, has built-in support for snap packages; installing the update requires only downloading the bundle. But the snap framework is available for other distributions as well; it may be a simpler way to test out the new release than waiting for a distribution repository update.
Perhaps ironically, the only peculiarity I encountered with the snap package of Inkscape 0.92 is that, when it is run on Ubuntu, it does not pick up the user's GTK+ 2 theme. This is, evidently, a choice that Gould made when creating the package, so that the application would look correct on non-Ubuntu systems. Once Inkscape is ported to GTK+ 3, it will cease to be an issue. Still, theme-sensitive Ubuntu users may prefer to fetch the release through the project's personal package archive (PPA) instead.
New user-visible features
Regardless of what package format you choose, the new Inkscape
release sports a lot of user-visible changes. The most substantial is
a type of new image element known as a
mesh
gradient. Part of the SVG specification, mesh gradients are fields
of smoothly graduated colors that are defined on a deformable
lattice.
The traditional gradients most users are accustomed to are defined on rectangles or ellipses, perhaps with transitions between multiple colors. Mesh gradients are an extension of that same concept; the difference is that the gradient lattice can be twisted around and reshaped arbitrarily, fitting into almost any shape — with as many straight segments, curves, and corners as desired. In addition to being fun to mess around with, mesh gradients are beneficial because they enable artists to create compact SVG documents that still exhibit complex coloration. A well-made mesh gradient element could replace dozens of layers of primitive gradients.
Text objects also gain a powerful new ability in this release: users now have full access to stylistic alternates and glyph variants in OpenType fonts. The variants include well-known examples like smart fractions, discretionary ligatures, and small capitals that are all defined in CSS, but OpenType allows fonts to include arbitrary features. Making use of them in software is still something of an ongoing battle even in the proprietary software world; Inkscape allowing users to access all of a font's OpenType features is a significant move in the right direction.
Also on the font front, whenever the user converts a text object into paths, the ARIA accessibility label (which contains the accompanying text) is now preserved, so users with any form of vision impairment will still be able to access the underlying text.
There are two new tools of interest that concern how Inkscape users
manipulate objects in a drawing, even though neither tool is used to
draw on the canvas. Each might take a bit of explanation. The first
is the "Objects" dialog, which provides a way to access the tree of
XML objects within the SVG file. An SVG drawing can easily
include hundreds of image and text objects, many of which will be
difficult if not impossible to select on the screen with a mouse.
In the past, Inkscape has provided some workarounds for this issue, such as using control keys to rotate through the objects located under the mouse until the right one is selected. But this dialog will be far simpler, for some users at least. Furthermore, having a full-featured dialog box makes it possible to interact with objects immediately. Need to change the color or opacity of an object? Simply type in the desired value. The dialog can also be used to individually lock or hide objects on the page.
The ability to access all of the SVG objects opens up some new possibilities as well. Users can assign meaningful names to every object, layer, or group, thus making those names accessible for other users in the future or to other software tools. For example, a designer can create a page full of icons in one Inkscape document, then run a script to select and export each of them as PNGs in a variety of sizes.
The other new feature is the "Selection sets" dialog, which allows the user to, in essence, define virtual groups of objects in the drawing. But, unlike the existing "group objects" feature, adding objects to a selection set does not permanently bind them together (nor does it change the z-axis ordering of the objects on the canvas). You can easily select the entire set by clicking on its name in the Selection sets dialog, but you can still move and edit the objects individually as needed. Here again, the main benefit is that large, complex documents become easier to work with.
Some smaller features worth pointing out in the new release include
the ability to lock guide lines in place, the ability to set the
document background to a checkerboard pattern (as opposed to white) so
that transparent regions are easier to notice, and support for many
more layer blending modes. Previous releases supported only the
Multiply, Screen, Darken, and Lighten blending modes. Inkscape now
supports eleven more. Furthermore, the blending mode can now be set
on each object in a document separately; prior releases supported
setting blending modes only at the document-layer level.
There are also some enhancements to existing drawing tools. The pencil tool, for instance, now supports an interactive smoothing feature, so users can simplify their line drawings without oversimplifying them. And the spray tool (which splatters around copies of a selected object in random, spray-paint style) saw numerous updates: an erase mode, better pressure sensitivity, the ability to avoid overlaps, and more.
Extensions and live effects
The above features are built into Inkscape's core drawing tools but, as is usually the case, there are even more new features to be found in the extensions and live path effects (LPEs) that ship with the program.
For instance, the pen tool is used by default to draw Bézier
splines. But, with the addition of two new LPEs, it can now also draw
B-splines and Spiro curves. Both are spline
curves that are subject to special constraints meant to ensure that
they exhibit fewer discontinuities. The
curves thus appear smoother to the human eye, and they can meet
stringent requirements for physical manufacturing.
There is also a suite of new LPEs for transforming objects on the canvas. The Perspective/Envelope transform might be the most familiar-looking: the user can grab handles on any corner of an object's bounding box and drag them around to distort its shape interactively. The Lattice Deformation LPE is more complex: it superimposes a five-by-five grid of handles over the object, and any of the handles — inside or on the perimeter — can be dragged to locally distort the object.
Conversely, the Transform By Two Points LPE is a simpler way to distort a shape: it provides one handle on each end of the object, which the user can drag around to squeeze or stretch things. That might be a preferable method for resizing an oddly shaped object, without distorting it internally. Whether the Perspective/Envelope or Lattice Deformation option is better for doing more complex distortions really depends on the object involved.
Other new LPEs include the "Roughen" and "Simplify" effects that roughen and smooth out vector objects, an effect to automatically rotate multiple copies of an object so that they follow the curvature of a path, and an effect to dynamically draw a mirror image of an object (making it far easier to draw objects with perfect symmetry).
While LPEs operate on top of the drawing surface, Inkscape extensions tend to be a bit more self-contained, such as performing several steps in sequence or iterating through a process. The new release adds several of interest. One helps the user generate seamless patterns, another changes the colors of a drawing to simulate several types of color blindness, another generates high-quality charts from values loaded from a CSV file.
That said, two of the new extensions add subtle enough functionality that they might not stand out as extensions at all. The "deep ungroup" extension will recursively ungroup all of the items in a nested set of groups-of-groups. The "set image attributes" extension iterates through a drawing to set the scaling factor for embedded PNG and JPEG images. In previous releases, whenever such an embedded bitmap file had been resized (particularly if it was resized by different amounts in the horizontal and vertical dimensions), the results would be displayed unpredictably.
Under the hood
As Inkscape moves closer and closer toward supporting the full SVG specification, it has made several changes to the underlying model that it employs for documents. This can be good or bad at any particular moment, depending on what one is doing and how one has used Inkscape in the past.
On one hand, Inkscape now supports many new standard SVG 2 and CSS3 properties such as paint-order and mix-blend-mode — even though the user interface does not yet expose a way to work with these properties. This is clearly good from a compatibility standpoint; SVG files opened in Inkscape will now look more like their original authors intended.
On the other hand, the new release changes the default resolution from 90 DPI to 96 DPI. As was the case with the change of grid-coordinate systems in the 0.91 release, the change brings SVG compliance but it may cause headaches for users who have old Inkscape documents sitting around and who open them in Inkscape 0.92. The application does offer plenty of warnings, but users should watch for oddities nonetheless. Similar caveats apply to text objects in two respects. First, "vertical text" in the Latin script is now rendered with all of the letters rotated 90°. This adheres to the specification, but users expecting the old behavior (with the letters standing upright beneath one another in a column) will have to adjust.
Second, Inkscape now follows the line-height definition as established in the CSS specification. That can affect line spacing in haphazardly created documents, because the CSS specification dictates how the line-height property cascades through the elements in a document. Indeed, one serious Inkscape user has already encountered trouble with this change. David Revoy reported that the line-spacing change "breaks" 10,000 of his files, and lashed out with some rather harsh words for the Inkscape team. Looking a little closer, the issue seems to be that Revoy renders his web comic from SVG source files, pulling in several translations for the captions and speech bubbles from external text files. The line-height change seemed to cause lines of text to collapse into one another.
In the bug report discussion, Tavmjong Bah noted that the line-height property was inappropriately specified in the document root as a percentage of a 12-pixel-high text, while the actual text elements in use within the comic were specified as 48 pixels high. Bah said there were a few options to fix the source files and posted Perl scripts that would transform the documents. Revoy replied that he would rather see a fix released in a post-0.92 update of Inkscape. As of press time, such a change has been staged, but an update has not yet been released.
Future-scape
If there is a lesson to be learned from Inkscape's need to change document defaults in order to follow an external specification, it is probably just that following specifications is difficult work. After all, the SVG and CSS specifications have undergone serious revision and expansion since the Inkscape project was started.
Along those lines, astute Inkscape historians may recall that the project publicly bumped the version number from 0.48 to 0.91 in 2014 in order to communicate to users that it was closing in on its goal of supporting the full SVG specification. At that time, a project spokesperson indicated that 0.91 would likely be the last release before Inkscape 1.0 — but that is clearly not how events have unfolded.
Release manager Bryce Harrington said in an email that the team expects to keep making incremental releases, and that 1.0 is not imminent. But that should not deter anxious Inkscape users from trying out the new release. As a lot of the new features in 0.92 demonstrate, Inkscape is more than just an SVG implementation. It supports a wide range of tasks, from technical work to pure creative expression.
Three new FOSS umbrella organizations in Europe
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.
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: The Internet of scary things; New vulnerabilities in ansible, chromium, kernel, mozilla, ...
- Kernel: GFP_TEMPORARY; Vendoring in the kernel.
- Distributions: New online man pages for Debian; CentOS, LEDE, Scientific Linux, ...
- Development: Vim's 25th anniversary and the release of Vim 8; KDE Plasma, KDE Slimbook, Krita, LibreOffice, Python, Xpra, ...
- Announcements: Open-Sourcing Google Earth Enterprise, G.729 Consortium patents expired, ...