KiCad is licensed AGPL-3.0 due to included TTL library

[Stefan Bruens]

KiCad uses the following sources from the TTL triangulation library:

> kicad-5.0.0/include/ttl/halfedge/hedart.h
> kicad-5.0.0/include/ttl/halfedge/hetraits.h
> kicad-5.0.0/include/ttl/halfedge/hetriang.h
> kicad-5.0.0/include/ttl/ttl.h
> kicad-5.0.0/include/ttl/ttl_util.h
> kicad-5.0.0/common/geometry/hetriang.cpp

Usage of these files makes the combined work be licensed under Affero GPL 3.0.

Link to TTL upstream:
https://www.sintef.no/projectweb/geometry-toolkits/ttl/
https://www.sintef.no/projectweb/geometry-toolkits/downloads/

https://github.com/SINTEF-Geometry/TTL/blob/master/include/ttl/ttl.h
---
...
 * TTL is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License as
 * published by the Free Software Foundation, either version 3 of the
 * License, or (at your option) any later version. * TTL is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License as
 * published by the Free Software Foundation, either version 3 of the
 * License, or (at your option) any later version.
...
---

[Maciej Suminski (orsonmmz)]

Hi Stefan,

As far as I can tell AGPL, GPL2+ and GPL3+ are compatible. What is the expected action on our side?

[Stefan Bruens (stefan-bruens)]

Yes, they are *compatible*, but this still make the *combined* work AGPL. This means that any binary version, distributed by the KiCad project or e.g. a Linux distribution, is also AGPL.

https://www.gnu.org/licenses/license-list.html#AGPLv3.0

GPLv3.0, section 13:
---
13. Use with the GNU Affero General Public License.

Notwithstanding any other provision of this License, 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. ***
---

(emphasis mine).

[Maciej Suminski (orsonmmz)]

I understand it, but what are we supposed to do about it?

[Stefan Bruens (stefan-bruens)]

Actionable items:

1. include the GPLv3 license text in the repository, e.g. as LICENSE.GPLv3
2. include the AGPLv3 license text in the repository, e.g. as LICENSE.AGPLv3
3. add a short LICENSE.README in the repository, stating something like:

---
The majority of KiCads source code is developed and distributed under the terms
of the GPLv3 or later. It does include some third-party code licensed under
AGPLv3 or later.

Both licenses are compatible, but a combined works as is will be governed under
the terms of the AGPLv3 (or later). This includes any binary distribution of the
KiCad EDA suite by the KiCad project or any third party, e.g. Linux distributor.

You are free to use the *sources* under the terms of their respective licenses.

Licensed under AGPLv3 (or later):
- TTL [https://www.sintef.no/projectweb/geometry-toolkits/ttl/], sources in include/ttl/*
Licensed under GPLv3 (or later):
- everything else
---

An equivalent change should be done for the Web page, i.e. http://kicad-pcb.org/about/licenses/

[Stefan Bruens (stefan-bruens)]

The Appdata also contains the wrong license tag, it has to be

<project_license>GPL-3.0+ AND AGPL-3.0+</project_license>

https://git.launchpad.net/kicad/tree/resources/linux/appdata/kicad.appdata.xml

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent

[Wayne Stambaugh (stambaughw)]

Just out of curiosity, who added TTL to KiCad and when? If this is indeed true, then KiCad must be released under the AGPL per the TTL license. I doubt this objectionable to our developer but it could be so in the future, we need to make sure to inform the development team before adding such code to avoid licensing issues.

[Seth Hillbrand (sethh)]

git blame says Orson, 2013, in the parlor with the wrench.

https://git.launchpad.net/kicad/commit/?id=e76a151ee76aa3f63260bc8a8c29fbfbb497c4e1

Not a lawyer but it does look like AGPL overrides GPL as Stefan mentions. So if we keep want to keep TTL, we will need to adjust our license screen in the About dialog. I can rework this if no one has a different opinion.

[Maciej Suminski (orsonmmz)]

Wayne,

As Seth correctly noticed, it was me who added TTL. Since 2013 the library has been used for the ratsnest algorithm. I figured it would not constitute a problem since AGPL is compatible with GPL, but it is right that AGPL is more strict than GPL.

What do you say? Shall we look for an alternative or can we keep TTL? IMHO, AGPL is not a bad thing - I doubt anyone is going to run KiCad as a server, but it does not harm the project.

[Wayne Stambaugh (stambaughw)]

Orson,

I don't think removing it is necessary. We just need to be more aware
of licensing and let the dev team know what is going on so everyone is
aware of any potential licensing issues. I doubt there are any
objections but I don't want to get blindsided when some dev decides to
drop their support because they disagree with the AGPL. In the mean
time, we will have to update our license statement to include the AGPL
due to TTL.

Cheers,

Wayne

On 10/22/2018 6:19 AM, Maciej Suminski wrote:
> Wayne,
>
> As Seth correctly noticed, it was me who added TTL. Since 2013 the
> library has been used for the ratsnest algorithm. I figured it would not
> constitute a problem since AGPL is compatible with GPL, but it is right
> that AGPL is more strict than GPL.
>
> What do you say? Shall we look for an alternative or can we keep TTL?
> IMHO, AGPL is not a bad thing - I doubt anyone is going to run KiCad as
> a server, but it does not harm the project.
>

[KiCad Janitor (kicad-janitor)]

Fixed in revision 2a170c9847d4fefcd3033a4d35ed26fc567693c2
https://git.launchpad.net/kicad/patch/?id=2a170c9847d4fefcd3033a4d35ed26fc567693c2

[Wayne Stambaugh (stambaughw)]

I just pushed a fix for this in the source repo. I'll try to remember to update the website when I get a chance. If someone screams bloody murder, Orson will be scrambling to replace TLL ;)

[Maciej Suminski (orsonmmz)]

Thanks Wayne, for the moment I feel quite safe;)

[Stefan Bruens (stefan-bruens)]

The committed changes look fine, but the appdata still state GPL-2.0+:
https://git.launchpad.net/kicad/tree/resources/linux/appdata/kicad.appdata.xml#n7

[Thomas Pointhuber (pointhi)]

When thinking about the user-base having KiCad under AGPL is not optimal for commercial users.

There are already some fabrication houses which support direct KiCad upload. When they do not publish their server-code part for the KiCad->Gerber part, this would already be a license violation. I'm not a lawyer, but the AGPL could force them to relicense even more parts of their backend when they want to be license compatible. I don't think that's something we actually want.

Personally, I think having KiCad under something like LGPL would be most beneficial for commercial adoption. But this would require a relicense which means lots of work, and everyone needs to agree.

[Wayne Stambaugh (stambaughw)]

@Thomas, I believe you mean commercial developers. The AGPL does not impinge upon commercial users in any way. As for commercial developers, it was never the intent of the KiCad project to support their requirements and/or goals. Unless someone is willing to step up and replace the TTL library with a GPL3+ variant, the AGPL is in play. As for the LPGL, that will only happen when all of JP's, CERN's, Dick's, and my code is rewritten because I'm petty confident these contributors will not allow their contributions to be re-licensed under the LPGL.

[Stefan Bruens (stefan-bruens)]

@Thomas, as long as these fabrication houses call KiCad as a standalone binary, they only have to publish any modifications to KiCad itself - which is likely an empty changeset.

**Iff** they use e.g. the python interfaces matters are probably different, but I doubt this is the case here.

The typical GPL license barriers (control via command line parameters, data passing using pipes or files) also apply to the AGPL.

[Thomas Pointhuber (pointhi)]

I don't think we can generate gerbers without using the python interface ^^.

The fabrication houses are only an example because this is done right now. In their case the Gerber files provide a clear separation between KiCad and any propertiary software stuff. So calling KiCad+Export-plugin would be possible as the remaining software is clearly separated, and the GPL part is only a converter for one of many of their supported formats (not a central system part).[1]

My comment was not limited to fabrication houses. To my knowledge, KiCad tries to aim for professional users in long term. This would mean integration into business operation software for example. This was the reason for my LGPL proposal because this would allow (from what I know) commercial plugins without legal problems/workarounds.[2]

While I am not affected by thus things (I license all my stuff in GPL, AGPL, BSD, CC0,... or what else seems sensible) it seems reasonable to try to not block commercial development which interfaces with KiCad. For the TTL library, it seems any commercial developer who wants the GPL back has to fix this issue by himself for now ^^.

[1] https://softwareengineering.stackexchange.com/a/110401
[2] https://opensource.stackexchange.com/a/4434

[Wayne Stambaugh (stambaughw)]

I don't see how the GPL or AGPL prevent commercials companies from using
KiCad. They are free to write all kinds of code around KiCad including
any amount of proprietary Python scripting that calls our Python
scripting library. They are not free to modify KiCad (including our
python scripting library) without making the changes freely available.
There is a fundamental difference between these two actions. In a
perfect world the GPL and AGPL would not even need to exist because
common decency would dictate that using efforts of someone for personal
gain would automatically be reciprocated. The problem with common
decency is it's not as common as one would hope. Ergo, the GPL and AGPL
exist. For those of us old enough to remember BSD sockets (BSD license)
and Kerberos (MIT license) being hijacked by a company who shall remain
unnamed and who contributed nothing in return, quickly understood the
need for the GPL and later the AGPL licenses.

KiCad is humming along quite nicely and is gaining a pretty decent user
base. It's already in many commercial settings so I don't see how a
more liberal license really benefits the project.

On 11/1/2018 11:40 AM, Thomas Pointhuber wrote:
> I don't think we can generate gerbers without using the python interface
> ^^.
>
> The fabrication houses are only an example because this is done right
> now. In their case the Gerber files provide a clear separation between
> KiCad and any propertiary software stuff. So calling KiCad+Export-plugin
> would be possible as the remaining software is clearly separated, and
> the GPL part is only a converter for one of many of their supported
> formats (not a central system part).[1]
>
> My comment was not limited to fabrication houses. To my knowledge, KiCad
> tries to aim for professional users in long term. This would mean
> integration into business operation software for example. This was the
> reason for my LGPL proposal because this would allow (from what I know)
> commercial plugins without legal problems/workarounds.[2]
>
> While I am not affected by thus things (I license all my stuff in GPL,
> AGPL, BSD, CC0,... or what else seems sensible) it seems reasonable to
> try to not block commercial development which interfaces with KiCad. For
> the TTL library, it seems any commercial developer who wants the GPL
> back has to fix this issue by himself for now ^^.
>
> [1] https://softwareengineering.stackexchange.com/a/110401
> [2] https://opensource.stackexchange.com/a/4434
>