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

Request Feedback
21

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.

1 Like
22

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

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

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 :slight_smile:

1 Like
23

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

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.

25

That could easily catch people out.

26

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

27

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

28

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

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

2 Likes
30

Yes, very astute. Thanks for correcting me! :+1:

31

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.

2 Likes
32

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