Collabora Online moves out of The Document Foundation
The dispute over the marketing plan has its roots in money, as is often the case. Developing a large system like LibreOffice requires the work of dozens of engineers, who need to be paid to be able to put a full-time effort into the project. Some of the companies employing those developers — Collabora in particular — think that TDF has succeeded too well; the free version of LibreOffice is solid enough that attempts to sell commercial support for it are running into a wall. The proposed marketing plan was designed to better differentiate "community-supported" LibreOffice from the professionally supported offerings from TDF member companies. This idea did not sit well with community members, who worried that LibreOffice was being pushed into a second-class citizen status.
The tension is at its highest around LibreOffice Online, which provides for collaborative editing of documents hosted on a central server. Evidently, what revenue does exist in the LibreOffice ecosystem is mostly focused on LibreOffice Online, which is a relatively hard service to set up and maintain without having somebody dedicated to the task. TDF has encouraged potential users to go with commercial offerings by, among other things, allowing the system to suggest commercial support to users and not offering binary builds of the LibreOffice Online server. Currently, if you want to establish a LibreOffice Online instance, you must start with the source and build it from there.
As Michael Meeks describes it in this announcement from Collabora, there are members of TDF that would like to change how LibreOffice Online is managed:
Some TDF community, board and staff members have made it clear they don't accept this compromise, and want TDF to use the LibreOffice brand to distribute a competing gratis product in the marketplace driving the price to zero, (perhaps combined with nags for donations to TDF).
This is something that Collabora, in particular, finds hard to accept; according to Meeks, Collabora is responsible for about 95% of the development work going into LibreOffice Online. A turnkey, binary offering from TDF would put Collabora into a position of competing with its own work, which would be available without charge, carrying the LibreOffice name, and perhaps lacking even a suggestion that users might consider buying services from TDF member companies. It is not entirely surprising that the company does not see that as an attractive position to be in.
In response, and as a way of avoiding this situation, Collabora is taking its online work out of TDF and creating a new project called Collabora Online, hosted on GitHub. It remains free software, of course, but it seems clear that Collabora Online will be managed much more like a single-company project that is intended to drive revenue for that company:
Meeks expresses hope that, beyond solidifying the business case for
Collabora, this move will ease some of the tensions within TDF. It
will define "LibreOffice" as referring to the desktop application in
particular, reduce the pressure on TDF to improve its support of its member
companies, and establish LibreOffice as "a core Technology which can
be built upon to create amazing things such as Collabora Online
".
It will, he hopes, bring an end to fraught discussions (many of which are
evidently private) within TDF and allow its members to "return to
positive mutual regard
".
Whether that happens will depend partly on how the other members of TDF respond to this move. Given that Collabora Online will still be free software, there is little preventing other TDF members from simply merging Collabora's work back into LibreOffice and offering it free of charge anyway. Thus far, nobody has (publicly) expressed any interest in escalating the situation in this way, though.
The one response that is public is this
message from Lothar Becker, the current chair of the TDF board of
directors. He asked members to work toward "finding compromises for
all sides, win-win solutions
" and noted that it will now be
necessary to revisit work on the TDF marketing plan:
Figuring out what TDF's course should be from here is not an enviable task. For all of the positive words, Collabora Online represents what is, in effect, a partial secession from the foundation — a statement of a lack of confidence that working within the TDF is in Collabora's interests. Such a move from one of an organization's principal members will be an unwelcome development at best, if not a threat to the organization as a whole.
What will happen next is not easy for an outsider to predict. Perhaps the TDF board will decide to make changes with the intent of attracting Collabora back fully into the organization; that could risk increasing tensions with other parts of the community, though. Or maybe other commercial members will begin to withdraw as well, pushing TDF (and possibly LibreOffice with it) into relative irrelevance. Or perhaps Collabora Online will thrive alongside a newly refocused TDF that retains responsibility for the overwhelming majority of the LibreOffice code.
Free software is a wonderful thing, but its creation is not free.
Complex software projects that lack the support of paid developers tend to
languish. Look at the state of Apache OpenOffice, which has not
managed to produce a feature release since 2014 and struggles to even get
security fixes out, for example.
Some projects naturally attract company support, while
others don't; each must find its own path to sustainability. LibreOffice
has been struggling with this issue for a while; one can only hope that
this crucial free-software project can find a solution that
works for all of its stakeholders.
Posted Oct 2, 2020 16:02 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (27 responses)
Seeing as none of the software involved is AGPL'd, and we're talking about something that can (probably) be sold as a service rather than as a binary, I tend to imagine that this would be an unwise course of action for TDF. I think this sort of escalation would not end well for anyone involved.
Posted Oct 2, 2020 16:14 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (11 responses)
Much as I have Free Software tendencies, I think too many in that camp forget that software developers need to eat ...
Cheers,
Posted Oct 2, 2020 16:38 UTC (Fri)
by amacater (subscriber, #790)
[Link] (9 responses)
The saddest of this is that Oracle acted as dog in the manger when handing Open Office over to the Apache project who've done nothing with it otherwise we'd have had one unified brand which would have worked better.
Posted Oct 2, 2020 18:16 UTC (Fri)
by jra (subscriber, #55261)
[Link] (1 responses)
I don't know exactly when that level is, but I know it when I see it :-).
Posted Oct 2, 2020 21:02 UTC (Fri)
by nix (subscriber, #2304)
[Link]
How big a project that is depends on the person (for me it's not very big at all: I can get into that state over 10k-line projects easily). But I'm damn sure that something the monstrous size of LibreOffice is way over whatever threshold exists.
Posted Oct 2, 2020 18:26 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Some will but as we have increasingly seen, if you are going to rely on a project, it is better to have it funded directly one way or the other instead of relying on hobbyists to do it part time when they are interested. Otherwise the situation with things like OpenSSL and now Libreoffice is going to blow up
Posted Oct 2, 2020 19:10 UTC (Fri)
by amacater (subscriber, #790)
[Link] (1 responses)
My day job couldn't ever have paid for the experience that Debian has given me : but, by the same token, Debian would have been none the better if I'd been paid to do Debian work all through the years: it was the Free commitment that got me interested and has kept me going through the years - I can always say "I _know_ it doesn't have to be this bad" with a clear conscience in work.
Posted Oct 2, 2020 21:18 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
That's what Collabora Office is. Trouble is, that model didn't pan out as hoped and the risk is Collabora will take their work elsewhere as already has happened for Libreoffice Online. LWN has covered some of the warning signs before
>Debian would have been none the better if I'd been paid to do Debian work all through the years: it was the Free commitment that got me interested and has kept me going through the years
That maybe true for you but you wouldn't able to make that claim about Debian developers in general. Also distributions benefit immensely from upstream projects many of core ones are largely driven by paid developers including for the Linux kernel. They also benefit from other distributions which are commercial, so there is a lot of shared work, Canonical etc in the case of Debian.
For upstream projects themselves on the other hand, if they are complex and not necessarily fun to deal with and they don't have a viable way to sustain themselves commercially, they often languish
Posted Oct 2, 2020 19:03 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
Trouble for me is I'm "paid by other people", with a job that is (a) low paid, (b) physically exhausting, and (c) I have a disabled wife ...
I have no time to sit down and *concentrate* on programming, which means basically I have no time to offer.
And if the minority who do have free time sabotage it for those who want to contribute but need to eat, that is a BIG problem - you've just alienated probably the *majority* of people willing and able to contribute.
Cheers,
Posted Oct 2, 2020 21:03 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Oct 2, 2020 22:55 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Reading and replying to emails on a low-volume mailing list isn't that taxing :-)
Cheers,
Posted Oct 3, 2020 0:31 UTC (Sat)
by gerdesj (subscriber, #5446)
[Link]
"E pur si muove" as a famous bloke once said. You are still here and perform a part in the community, you have been doing this for quite a while and I suspect for some time to come.
You give what you can. That may not be in terms of cranking out code but that is not the only important input to the effort (whatever that might mean to you.) You don't hesitate to dive in and say your piece and in general it is well received or at least listened to and considered.
Keep it up matey.
Cheers, Wol
Cheers
Posted Oct 15, 2020 20:12 UTC (Thu)
by midol (guest, #25855)
[Link]
yes but not necessarily "eat what they make" Einstein said if you want to be a a physicist get a job as a plumber, do physics in the evening.
Posted Oct 2, 2020 20:28 UTC (Fri)
by Deleted user 129183 (guest, #129183)
[Link] (2 responses)
Well, I guess that it’s a nice case for always using AGPL instead of any other copyleft licence.
Posted Oct 3, 2020 1:39 UTC (Sat)
by droundy (subscriber, #4559)
[Link] (1 responses)
Posted Oct 3, 2020 3:54 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
> Notwithstanding any other provision of this License [i.e. GPLv3], you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
AGPLv3 has a similar clause:
> Notwithstanding any other provision of this License [i.e. AGPLv3], you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
Based on my non-lawyer non-expert opinion, it appears that each part remains under its own license, and the whole has to comply with all of the terms and conditions of both licenses. That seems really weird but potentially workable, if you're careful about tracking where everything came from.
Posted Oct 3, 2020 20:59 UTC (Sat)
by thumperward (guest, #34368)
[Link] (11 responses)
Likewise, it's also worth noting that for all its good intentions, the AGPL's use as it has borne out in the real world is primarily as a poison pill; one releases one's code not because one wishes for glorious communal collaboration, but because it prevents competitors from creating online products based on it (but not oneself, assuming one retains the copyright). That's the last thing anyone should be hoping for here. The silver lining is that a good few of Collabora's top people in TDF were involved in the early days when pushback against copyright assignment was one of the catalysts for the LibreOffice project in the first place, so I would be very surprised if they went this route.
Posted Oct 4, 2020 21:30 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
I suppose that's a possibility, but there is also the possibility that they (or anyone else working in this space) simply cease providing source (and binaries) altogether. The regular GPL does not prevent them from moving to SaaS-only model, doing all of their development in private, and never distributing anything.
There are issues of logistics etc. to consider before making such a dramatic shift in one's line of business (as I understand it, they currently sell binaries + tech support, not SaaS), but it's not like this would be totally impractical. In the short term, they could set it up on AWS or GCP, contract out most of the hard work to Amazon or Google, and then it's just a question of price and volume. The downside, of course, is that they would have to try and differentiate themselves from Office 365 and GSuite, which is probably not an easy case to make from a business perspective (i.e. it's the old "Nobody ever got fired for buying IBM" problem again).
(Disclaimer: I work for Google. One of the services that I help support is related to GSuite, and another is related to GCP. Views are my own.)
Posted Oct 4, 2020 23:53 UTC (Sun)
by ras (subscriber, #33059)
[Link] (9 responses)
I use the AGPL for my projects, and I don't think about it like that. Ironically, the only time I do think about whether to use the AGPL is appropriate is when it is web facing.
That's because the AGPL is just the GPL plus some web facing stuff. The corollary to that so if there is no web facing stuff they are effectively the same, so why bother to put any effort into thinking about whether to use it for non web facing projects?
Posted Oct 5, 2020 11:22 UTC (Mon)
by thumperward (guest, #34368)
[Link] (8 responses)
Because there could very well be uses for one's software in a Web-facing application that one hadn't thought of? I mean, the examples that people always give are databases; there's nothing inherently "Web-facing" about a database, but as soon as you build an application on top of an AGPL database, said application is bound by the AGPL. Hell. let's look at the very case in the article; prior to Google Docs, it wasn't commonly perceived as possible to put a Web frontend on a desktop-quality office suite. If OpenOffice had been licensed under the AGPL on the grounds that well, it didn't matter for offline projects, then LibreOffice Online might never have happened (at least by the route that it did).
Posted Oct 8, 2020 20:05 UTC (Thu)
by jfred (guest, #126493)
[Link] (7 responses)
That doesn't sound quite right. The AGPL doesn't contain any requirement that applications interacting with AGPL code over a network are themselves AGPL. All it says is:
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
In other words, you must provide the source code to *users interacting with the software over a network*, and in the case of a database... they're not. They're interacting with *your* code, which happens to use some AGPL database under the hood. (Though if your software is sufficiently trivial, e.g. a light wrapper around the database, it could probably be argued that they are in fact interacting with the AGPL'd software and therefore its terms would still apply.)
If the library that the application uses to interact with the database is AGPL, then sure - but that's basically the same old GPL requirement.
Posted Oct 14, 2020 8:18 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Sure, there are FAQs about this. Sure, the LGPL has a linking exception. But under American common law, none of that matters because none of it appears within the four corners of the license (i.e. the GPL or AGPL). Within the four corners of the document, all you get is this:
> To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
Note the conspicuous lack of the word "linking." The GPL does not actually say that linking creates a derivative work! Instead, it leaves this question up to the ambient copyright law.
The problems with this are twofold:
1. Some judge might decide that linking actually does not create a derivative work at all, possibly in a copyright lawsuit having nothing to do with the GPL.
The GPL can't really fix or prevent #1, because if #1 happens, then that would place linking outside the scope of the original's copyright. But the GPL could cabin in #2 with some kind of "pipe and socket exception." Obviously, the FSF does not want to do that, because it would make it far too easy for a proprietary developer to simply convert a library interface into a pipe/socket RPC interface, and they prefer to have a gray area of the law to fall back on in case someone tries something like that.
(Technically, section 5 does contain some language making exceptions for an "aggregate" of unrelated software. But this still does not refer to "linking" as such, and appears designed to function as a very narrow exception for software that doesn't really interact at all.)
But that also means that it is incorrect to assert that "pipes and sockets are not subject to the GPL." This is not necessarily true. Pipes and sockets might be subject to the GPL, or they might not, depending on which judge you happen to get randomly assigned, how technically literate that particular judge happens to be, and to a much lesser extent, whether or not you are actually trying to play fast and loose with the license in the first place.
Yes, I know, we should "just be reasonable, and everything will be fine." Unfortunately, corporate lawyers really don't like it when you tell them "It's OK, we're being reasonable. Everything will be fine."
Posted Oct 14, 2020 18:17 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (5 responses)
Unfortunately, the *authors* have *no power* to define (let alone exhaustively) what counts as a modified version. This is down to copyright law and copyright law *alone*. So if the corps want an answer they need to petition parliament, or congress, or whoever, for an answer. Sorry.
What the authors and the GPL *can* do is define what does NOT count as a modified version. So the fact that the FSF explicitly doesn't exclude linking from creating a derivative work is a clear statement of "we consider that linking creates a derivative work". Whether they are right will require a law suit.
Contrast this with the statement that the output of GCC is not a derivative work of GCC. This is legally "either you don't need a licence, or you have a licence. Whatever".
While I agree with you that the corporate types want certainty, and I think they're being very reasonable about it, if they're blaming the GPL for said uncertainty then they're several lawyers short of a courtroom.
Cheers,
Posted Oct 14, 2020 22:52 UTC (Wed)
by ras (subscriber, #33059)
[Link] (4 responses)
> Contrast this with the statement that the output of GCC is not a derivative work of GCC.
True, but to get a working program with gcc you have to -lgcc. (This happens automatically unless you give -nostdlib to gcc, so most people won't notice.) So in reality just about every program compiled with gcc is not just the output of gcc, it includes a bit for bit copy of some GNU code. I’m guessing they ignore that when they look at GPL compliance.
The kernel devs are very explicit about defining the syscall as the GPL demarcation line. They also have some other barriers in kernel code for GPL symbols. That has worked very well up until now, but all it would take is some miscreant to get a large blob of code into the kernel, then then say "well that's not how i read it". They would be right, and we would end up with another mess of similar ramifications to the Oracle / Google / Java fiasco.
So yeah, to me this has turned out to be the major flaw in the GPL. I'm no lawyer, but to be a solution would be a GPLv4 that demands a schedule be attached stating where the boundaries lie. Is it a derivative work if you link to it? What if you restrict your interactions with the library to it's publicly defined API from it's header files? How about running it from a shell and using it's input? What about calling it’s API via RPC over a network? A series of checkboxes covering the common cases would do. If the kernel licence had such a schedule attached, no one who commits code could claim it was otherwise.
As you say, this probably conflicts with the way copyright law is written. But given the liberties the kernel already takes with not only the law but the GPL and how well that's held up, I'd say those liberties won't alter enforceability in practice. The GPL seems to be enforced more by gentlemen's agreements, persuasion, and appeals to do the right thing than the law anyway.
Posted Oct 14, 2020 23:22 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 15, 2020 0:57 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
They're not ignoring it. In addition to the terms of the GPL, libgcc code is covered by the GCC Runtime Library Exception[1], a form of dual-licensing, which states:
> You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes.
Which basically means that you can link libgcc with non-GPL code as long as no GPL-incompatible software was involved in the compilation process. (See the link for details.) The whole "Eligible Compilation Process" bit is intended to make things as difficult as possible for anyone wanting to use parts of GCC in combination with non-GPL external tools (separate programs generating or processing GCC IR, not linked with GCC), for example to use GCC as a backend for a proprietary compiler or to leverage GCC's parsers and IR optimization passes in front of a proprietary backend code generator. However, the only leverage they have for this is the trivial bit of C runtime code in libgcc, and so the added complexity and off-putting legal risk of the Runtime Library Exception all seems a bit pointless to me since anyone interested in doing such things could easily substitute an ABI-compatible runtime with a more permissive license, such as LLVM's libcompiler-rt. Or for that matter just use LLVM itself rather than GCC.
Posted Oct 15, 2020 3:27 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (1 responses)
I have always understood that this is because it is not an issue that the license is in any position to clarify.
A license can *limit* what is a derived work, as the Linux kernel license does by explicitly saying that the copyright holders to not consider applications which use the syscall interface to be derived works. So it can say what is not a derived work, but it cannot say what is. Only a judge can do that, by interpreting the law.
Posted Oct 16, 2020 12:23 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Wol
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Wol
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Wol
Collabora Online moves out of The Document Foundation
Jon
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
> [...]
> To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
>
> To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
2. Some judge might decide that something which is not linking (e.g. a pipe or socket) also creates a derivative work.
Collabora Online moves out of The Document Foundation
Wol
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Enforced?
Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Copyright LAW declares that where copyright is granted, it also covers derived works. It is up to the LAW to determine what this means, not the license.
Collabora Online moves out of The Document Foundation