Collabora Online moves out of The Document Foundation
Collabora Online moves out of The Document Foundation
Posted Oct 4, 2020 23:53 UTC (Sun) by ras (subscriber, #33059)In reply to: Collabora Online moves out of The Document Foundation by thumperward
Parent article: Collabora Online moves out of The Document Foundation
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
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