I notice that AGPL (or Affero) licences are on that list. These are a more restrictive form of viral GPL, that require the entire source of an application be published under the terms of the licence, even when only the object form of the code is being distributed; if you unwittingly include such a package in your project, you could be forced to open source all of it.
I don’t know if any packages currently use this licence - should packages with this licence be allowed to be published?
Are there other potentially problematic licences in the list?
Most packages seem to use BSD or MIT. It would be worth displaying the licence type on the package site. It would also be worth doing a licence survey to see what is actually being used.
I don’t think banning packages because of licenses is a good idea but it would be nice for the package manager to warn the user if she tries to install a viral license and maybe have a warning about having to provide the source code or something like that.
I think most of the MPL-2.0 packages there are mine - that’s been my standard license for a while, but I’m open to feedback from anyone who knows a reason it could be problematic.
The very simplified version of the MPL is that that you can incorporate MPL-licensed code into proprietary code with no real restrictions, except that if you make changes to the MPL-licensed files themselves then those changes must be contributed back. To me this seemed like a sensible, non-viral and entirely reasonable requirement - just enough to prevent commercial, proprietary forks and encourage contributing back improvements and fixes. But I’m open to switching to BSD or similar if there are reasonable use cases I’m not considering where the MPL’s restrictions would be an issue.
I’m not advocating banning any existing packages, just the AGPL licence type, as it can be used as a Trojan horse.
I’m not advocating banning GPL or viral licences either, although others might want to argue the case here?
Consider this hypothetical scenario:
Our business invests $1M in developing a new product, using Elm of course. One of the major packages is AGPL, but the devs just install it anyway, as often happens when we’re up to our eyeballs in code. A week before the product launch, the legal department asks for an audit of software licences to perform due diligence. At that point, the AGPL problem is brought to light. We check the authors web site and find that they also sell a commercial licence; “just give us a call!”. The author turns out to be a shrewd individual who makes a level-headed assessment of the situation and realises that re-working that package out of our code is going to cost us around $500K in development time. He sets the licence price at $450K.
Our own fault of course, for not doing the due diligence on day 1 - but it is also possible to “make this undesirable state impossible”.
That is also required by the regular GPL, not only by AGPL.
It’s not enough to check license of a library, you must also check licenses of its dependencies. If any one of them is GPL, the final library is GPL too. Also, you must check all files in the library, checking just the LICENSE file is not enough, some files may have different license headers, etc. Checking license of any existing codebase is non-trivial, and you didn’t even mention how you did it when creating your plot, so I find the plot not worth a dime, I’m afraid.
You should always review the license of any code you include in your codebase. That’s on you, no excuses. The listing of packages may try to help you with this, but even if it does, the legal responsibility is most probably still 100% on you. (IANAL.) And by the way, both GPL and AGPL still allow you to sell software using this license for money; so your “hypothetical scenario” still allows you to not pay the author of the library you used a dime! (But did you stop for a moment to consider that he/she actually helped your business, so it might be actually right to pay him/her for his/her hard work?)
Personally, I’d find banning AGPL or GPL on packages list absurd. There are people who want to build FLOSS, and for them, GPL/AGPL might be a totally valid choice. Banning it from the packages list would make the Elm ecosystem explicitly pro proprietary licensing, and against free/libre licensing. I’m being super moderate with words when I’m saying this would be… controversial… on the Internet.
I’m not planning to follow this discussion after this post, as per point 4 above especially, I believe it is not really worth any discussion. I find this proposal outrageous. Just wanted to make sure a whistle was clearly blown on this suggestion, so that it wouldn’t be accidentally overlooked per some insane “silent agreement assumption”.
Is that really true? Wouldn’t it be sensible to let the project to either open source all of it or to stop using the package? But maybe that’s not how laws work.
Ok, you could be force to open-source your entire project if you continue to use the package. You could also choose to not use it, yes, and then you would not be subject to that requirement.
“Both versions of the Affero GPL were designed to close a perceived application service provider (ASP) loophole in the ordinary GPL, where, by using but not distributing the software, the copyleft provisions are not triggered.”
I guess it comes down to whether using a single page application counts as distributing the object code - but I think web applications do count as SAAS.
I see the AGPL as a way for developers to request (non-financial) compensation for their work, which I’d never begrudge anyone. Referring to it as “viral” or a “trojan horse” makes it seem as if authors who choose the AGPL are doing so with malicious intent, which I’d venture is almost never the case.
I do like the idea of having tooling warn if you include a library with a license which requires code re-sharing. That helps people make informed decisions, and highlights the importance of understanding the licenses of software you use. Banning those licenses however, seems to me to push the idea that open source developers not only aren’t compensated in practice, but in fact shouldn’t be, which isn’t something I can get behind.
Reading the header I thought you were asking what licenses apart from AGPL were missing on the list. Then I understand you mean the contrary !?
My answer is a clear “Yes, of course - AGPL licensed packages should be allowed to be published”!
Why?:
AGPL is a great license. It disallows closed forks, even for SaaS, simple. Btw I’m missing the ALGPL, it doesn’t exist (yet).
Automatic license compliance checking for standard free software licenses is not hard by the way - and even realistic with our cool favorite three letter language as @rtfeldman envisions above. This would be impossible with arbitrarily complex proprietary license contracts. But AGPL is not an issue.
An important “personal” note to @rupert : I’m actually worried by your fearmongering rhetoric, in particular reading the hypothetical “blackmail” scenario in your comment. In multiple ways, even shocked. Two advises:
Please take your responsibility seriously when writing and distributing source code professionally!
Please think more before writing proposals and be aware that you may trigger, even hurt people (you’re proposing exclusion after all!) and for sure occupy other people’s time, at least my last hour or more. Sorry that this is a bit embarrassing, but who cares. Happened to all of us
@democracy-bot / @rupert: I’m proposing the closure of this thread.
I agree that we should try to be a friendly and inclusive community. Everybody has his own views and opinions. You don’t know a persons background for that matter and judging him this way is simply unneccesary and does not add any value to the conversation.
The blackmail scenario is unfortunately real - I can’t say too much but I do have direct experience of it! I think this kind of thing is not that common, and of course you can’t cry about it if you didn’t do the due diligence early.
and many other big corporates also follow that policy.
Reading the above responses it sounds like I am in a minority on this issue, but I think it is good that we had a debate about it.
I would suggest that getting the licence type displayed prominently on the package site would be a good step to take and something that we do seem to agree on.
Also, no-one has used AGPL for an Elm package yet; its mostly BSD and MIT - and MPL for elm-geometry is also a good choice, of course we would want to contribute back to such a great piece of software. The licensing picture across Elm looks very healthy at the moment, and easy for the more corporate participants to work with.
@rtfeldman Sorry if this post came out as too emotional; I tried to restrain my wording, while still not losing the importance of the thing for me… I hoped that limiting this to assertive descriptions of my subjective feelings (without trying to cast them as objective truth) would be OK; sorry if I was still too risky. Huge thanks @rupert for keeping calm and not escalating further in response! And one more big thanks goes to @nidi, I find your post to summarize my view in much more elegant way than I would imagine possible, while also to my own surprise perfectly diagnosing why I felt so strongly about the issue. It’s humbling, refreshing and elevating to suddenly find myself among such a civilized company.
(this is a joke btw, just to be clear…)