# Elm 0.19 licence types - AGPL and what should be allowed/recommended?

**URL:** <https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056>\
**Category:** Request Feedback\
**Created:** [September 26, 2018, 10:30am UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056 "2018-09-26T10:30:52Z")\
**Posts on this page:** 12\
**Page:** 2

<div class="post-metadata">

**Author:** ![billstclair](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/billstclair/32/260_2.png) [@billstclair](https://discourse.elm-lang.org/u/billstclair)\
**Post date:** [September 27, 2018, 2:48pm UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/21 "2018-09-27T14:48:59Z")

</div>

The company I work for uses lots of open source code, but nothing even remotely GPL. Their lawyers do not want anyone to have the slightest chance of forcing their proprietary software into the open. I use the MIT license on my Elm code, encouraging use in any way anyone wants to use it, but asking them to give me credit.

---

<div class="post-metadata">

**Author:** ![nidi](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/nidi/32/283_2.png) [@nidi](https://discourse.elm-lang.org/u/nidi)\
**Post date:** [September 28, 2018, 12:01pm UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/22 "2018-09-28T12:01:43Z")

</div>

> [@rupert](#):
>
> The blackmail scenario is unfortunately real

Yes, it’s real ! (in the heads of corporate managers) 🙂

@all: I’m glad we’re all taking the open discussion with humor 🙂

For the sake of consensus:

- Of course displaying the license prominently on the package page would be very useful and welcome and can later be extended with an automatic compliance check.

- Some developers (such as me) choose to use more strict copyleft licenses for a good reason and being banned of corporate policies (due to corporate politics which is not in accordance to e.g. my interests) is not necessarily a blocker for me as a dev. To be clear: I second that generic data structure focused libraries are often in good hands when choosing BSD or alike - we don’t need to be too overprotective about code - we’re doing open knowledge after all. But for larger a larger (or smaller) application, I may very well want to choose to prohibit closed forks.

- The fact that the current Elm community doesn’t use AGPL yet doesn’t mean that it also wouldn’t be the license of choice for future devs and softwares. I would very likely choose to release a larger application, such as online participation software as AGPL in order to indeed protect “my IP” or rather “my engineering”.

- Maybe I just grasped something important which explains things to me. In those cases where some would choose to keep their larger app closed, I would choose AGPL for the sake of “protection”, but it’s “protection in the public”. Not doing Free Software isn’t an option for _me_ (both as a dev as well as as entrepreneur), this may be different for others.

This has turned into an interesting discussion. Thanks, @rupert 🙂

---

<div class="post-metadata">

**Author:** ![harrysarson](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/harrysarson/32/1305_2.png) [@harrysarson](https://discourse.elm-lang.org/u/harrysarson)\
**Post date:** [September 28, 2018, 10:40pm UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/23 "2018-09-28T22:40:11Z")

</div>

I am curious about what happens if an (apparently) MIT licensed package pulls in a GPL (or similarly) licensed elm dependency.

I am definitely capable (and probably have done) of both

- Publishing a package as MIT without checking all of the package’s dependencies.
- Carefully checking the licence of a package I install without paying the slightest bit of attention to that package’s own dependencies.

---

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [September 29, 2018, 8:28am UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/24 "2018-09-29T08:28:01Z")

</div>

> [@harrysarson](#):
>
> I am curious about what happens if an (apparently) MIT licensed package pulls in a GPL (or similarly) licensed elm dependency.

I think I can answer that. With reference to the article I linked above, what activates the copy-left clauses of the GPL is use in a derived work, and as Elm packages are directly linked into an application by the compiler, web applications based on GPL libraries are indeed derived works.

An MIT licenced _package_ with a GPL dependency, is allowable, as when it is in package form, it is not yet a derived work, because the GPL dependency has not been linked in (merely referenced).

An _application_ with a GPL transitive dependency through an MIT one, would activate the GPL copy-left clauses that exist deeper down the stack.

This situation does not exist (yet) in the Elm packages, as there is only one GPLed package, `elm-piano`.

---

<div class="post-metadata">

**Author:** ![harrysarson](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/harrysarson/32/1305_2.png) [@harrysarson](https://discourse.elm-lang.org/u/harrysarson)\
**Post date:** [September 29, 2018, 8:49am UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/25 "2018-09-29T08:49:27Z")

</div>

That could easily catch people out.

---

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [September 29, 2018, 9:33am UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/26 "2018-09-29T09:33:28Z")

</div>

> [@harrysarson](#):
>
> That could easily catch people out.

Yes. It is not a situation unique to Elm though, all web applications are in the same position.

---

<div class="post-metadata">

**Author:** ![nidi](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/nidi/32/283_2.png) [@nidi](https://discourse.elm-lang.org/u/nidi)\
**Post date:** [October 9, 2018, 1:21am UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/27 "2018-10-09T01:21:56Z")

</div>

> [@rupert](#):
>
> An MIT licenced _package_ with a GPL dependency, is allowable, as when it is in package form, it is not yet a derived work, because the GPL dependency has not been linked in (merely referenced).
> 
> An _application_ with a GPL transitive dependency through an MIT one, would activate the GPL copy-left clauses that exist deeper down the stack.

I doubt that the differentiation between package and application makes sense and just leads to unnecessary confusion (aka FUD v2: open source licenses are so complicated). If your peace of software has a dependency on a work with a copyleft license it needs to comply with that license, period. Simple!

(Even if you may find a formally legal loophole which allowed you to release the modified source under an incompatible license, it simply doesn’t make any sense to do so.)

---

<div class="post-metadata">

**Author:** ![Qqwy](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/qqwy/32/1062_2.png) [@Qqwy](https://discourse.elm-lang.org/u/Qqwy)\
**Post date:** [October 9, 2018, 6:34am UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/28 "2018-10-09T06:34:10Z")

</div>

Very interesting discussion!

What about:

- Allowing people to specify the package in a common format when publishing an Elm package. (There already is the ‘license’ field in the elm.json. Is it already used in some way currently?)
  - Warning, when publishing, if they have specified a license in here that would restrict commercial use.
  - Warning, when publishing, if they have specified an unknown license in here.

- When installing a package into your project, `elm-install` can also check for this field, and show similar warnings to the user:
  - Warning if the license is restrictive for commercial use.
  - Warningif the license field is unknown, asking the user to manually check.

In this case I think we can:

- Make sure publishers are aware of the choice they’ve made by picking a specific license.
- Busy developers installing a package are aware of its license and therefore should not be hit by horror-stories like the one that @rupert has shared.
- Nobody feels attacked for the particular choice of license they’ve made, because we restrict nobody’s choices, only show them helpful advice to make sure they are making an informed decision.

---

<div class="post-metadata">

**Author:** ![nidi](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/nidi/32/283_2.png) [@nidi](https://discourse.elm-lang.org/u/nidi)\
**Post date:** [October 10, 2018, 9:37pm UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/29 "2018-10-10T21:37:12Z")

</div>

> [@Qqwy](#):
>
> Warning, when publishing, if they have specified a license in here that would restrict commercial use.

Note that copyleft licenses like GPL or AGPL do not prevent commercial use in any way - you’re free to make money with the software, you just have to comply with the license. Instead of “restrict commercial use” you probably mean “restrict use within closed source / proprietary software”.

---

<div class="post-metadata">

**Author:** ![Qqwy](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/qqwy/32/1062_2.png) [@Qqwy](https://discourse.elm-lang.org/u/Qqwy)\
**Post date:** [October 11, 2018, 5:43pm UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/30 "2018-10-11T17:43:38Z")

</div>

Yes, very astute. Thanks for correcting me! 👍

---

<div class="post-metadata">

**Author:** ![ktosiek](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/ktosiek/32/1365_2.png) [@ktosiek](https://discourse.elm-lang.org/u/ktosiek)\
**Post date:** [October 14, 2018, 4:26pm UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/31 "2018-10-14T16:26:14Z")

</div>

I believe allowing AGPL makes sense - not everyone is building a proprietary application, especially on the frontend.

Of course having a tool that checks if all dependencies match a whitelist of licenses allowed in a given project would be great. Even better if it could generate an attribution list - even some of the more liberal licenses require attribution, otherwise you are not supposed to use the software.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [October 24, 2018, 4:26pm UTC](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056/32 "2018-10-24T16:26:21Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

[Previous page](https://discourse.elm-lang.org/t/elm-0-19-licence-types-agpl-and-what-should-be-allowed-recommended/2056.md?page=1)