|
|
Subscribe / Log in / New account

Videos from the 2020 Copyleft Conference

Videos from the 2020 Copyleft Conference

Posted Apr 30, 2020 18:11 UTC (Thu) by IanKelling (subscriber, #89418)
In reply to: Videos from the 2020 Copyleft Conference by Cyberax
Parent article: Videos from the 2020 Copyleft Conference

> For example, our product is a CAD application and what would happen if we have a plugin that allows to view our CAD models directly in webmail? Will this require opening up everything?

What is licensed under agpl in this scenario? There is no kind of gpl which requires "opening up everything."


to post comments

Videos from the 2020 Copyleft Conference

Posted Apr 30, 2020 18:14 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

Suppose that we're using an AGPL webmail software. And we want to write a plugin (for our clients' use) that would allow viewing our CAD models directly in the webmail.

Videos from the 2020 Copyleft Conference

Posted Apr 30, 2020 18:24 UTC (Thu) by IanKelling (subscriber, #89418) [Link] (8 responses)

So you're concern is that you might have to make the plugin be free software? Sorry, I'm not really interested helping people make nonfree software, but heres this:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins

Videos from the 2020 Copyleft Conference

Posted Apr 30, 2020 18:28 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Yes, this plugin would inevitably link our proprietary code and we don't want to open source it. It's also not at all fair, there's no way our code is a derivative work of a webmail app.

As for your link:
> It depends on how the main program invokes its plug-ins.

And so far there's no clear answer that applies to web. Is an iframe enough to establish "intimate communication"? What about a WebComponent?

Videos from the 2020 Copyleft Conference

Posted Apr 30, 2020 20:47 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

> It's also not at all fair, there's no way our code is a derivative work of a webmail app.

The FSF takes the position that any sort of linking constitutes a derivative work, but this is a question of law for a court to resolve. The FSF does not have the power to override the plain language of either the local copyright statute or their own licenses. The {,A,L}GPL are all very explicit about this. Consider for example this line from GPLv3:

> 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.

So, if whatever you did does not "require copyright permission" according to your local jurisdiction, then section 5 of GPLv3 ("Conveying Modified Source Versions") does not attach and copyleft is not applicable to your product. AGPLv3 has an identical definition, and LGPLv3 incorporates GPLv3's definition by reference. A prudent lawyer would probably advise you to assume that permission is required, but to the best of my knowledge, the claim that dynamic linking constitutes a derivative work has not been seriously tested in a court of law and might not actually be correct. Even if a court were to rule it correct, it might vary by jurisdiction or by circumstances.

(Whether it is wise to actually litigate this out is another question, of course. Lawsuits are expensive and may have uncertain outcomes. Most businesses will likely prefer to just avoid AGPL-licensed software altogether. This is probably why we don't have many clear court rulings on this point.)

Finally, I feel obligated to quote the actual part of the AGPL that gives most people pause (section 13, "Remote Network Interaction; Use with the GNU General Public License"):

> 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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
>
> [snip GPL compatibility paragraph]

It is important to bear in mind *which program* is the "modified version" and how it is interacting with the end user. For example, if you made a plugin to a traditional email client rather than a webmail service, then the user would not be interacting with your plugin "remotely through a computer network" but locally on their own machine, so the AGPL would not impose any additional requirements on top of regular GPL formalities. You might still object to those formalities, but in this case, your beef is with copyleft in general, not AGPL in particular.

Videos from the 2020 Copyleft Conference

Posted Apr 30, 2020 21:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> You might still object to those formalities, but in this case, your beef is with copyleft in general, not AGPL in particular.
I have no problems with copyleft when it's clearly defined. For example, Linux is perfect in that regard because there's a clear and concise description of where the GPL stops.

There are also no problems with GPL dynamic libraries, it's widely accepted that linking them in results in a derived work. So proprietary programmers just avoid them altogether.

But there ARE problems with uncertainty around AGPL's scope. And FSF at least can provide clear guidance here. It won't be legally binding per se, but it will be taken into account by courts.

With all the uncertainty companies just have to ban it entirely (like Amazon and Google do internally). And this in turn ensures that there is close to zero useful AGPL-only code.

Videos from the 2020 Copyleft Conference

Posted Apr 30, 2020 21:15 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

> There are also no problems with GPL dynamic libraries, it's widely accepted that linking them in results in a derived work.

This is mostly but not universally true. For example, Canonical has, for quite some time, distributed ZFS-on-Linux as a binary module with Ubuntu, which the Conservancy says violates the GPL. As you might imagine, Canonical disagrees with them. The heart of the dispute is dynamic linking between ZFS and Linux.

Videos from the 2020 Copyleft Conference

Posted May 3, 2020 3:11 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

This is a related but different problem: the lack of license enforcement for the kernel. I think that Canonical is clearly in the wrong, but nobody cares enough to sue them.

Videos from the 2020 Copyleft Conference

Posted May 4, 2020 21:26 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

> Sorry, I'm not really interested helping people make nonfree software

Unfortunately, software devs need to eat like everyone else. And if your software REQUIRES you to work on it full-time (things like tax software for example) how are you going to pay for your food if most people freeload off you?

Yes, I would like to write awesome free software. But most people can't afford to do it for free.

Cheers,
Wol

Videos from the 2020 Copyleft Conference

Posted May 5, 2020 8:57 UTC (Tue) by Lennie (subscriber, #49641) [Link] (1 responses)

Well, you get paid to write the code, if you do a good enough job, people will pay you to add more code.

So going with your example: the tax code changes, so the program has to change with it: people pay you to write the new code.

Where is the problem ?

Videos from the 2020 Copyleft Conference

Posted May 5, 2020 9:37 UTC (Tue) by Wol (subscriber, #4433) [Link]

> Where is the problem ?

Finding enough people prepared to pay rather than freeload ...

Oh - and the potential liability, and all that sort of stuff.

People write software for all sorts of reasons, get paid in all sorts of ways, but sometimes cash is a necessity :-(

Cheers,
Wol


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds