Switch back to less restrictive license than AGPL #638
Comments
No actually copyright law restricts the use of software and I, as the nice person that I am and the author of said software, grant you various freedoms that you otherwise wouldn't have.
The AGPL3 license is essentially the GPL3 license with one additional provision. The GPL has been used by a large number of free software projects for years now so you really can't call it "not well defined".
If your lawyers can't deal with a slight variation of a widely used license I really don't know what to tell you. If you want me to change the license you really have to come up with a better argument than that. |
|
I will try to get more details from them to give better argument. |
|
There are few aspects of AGPL which makes it problematic: given broad enough interpretation, licensor can claim that, any code which was created with a tool, becomes connected with the tool as if it interacted with it over the network, which would require the code to be also released as AGPL. The license also has not been yet tested with courts, hence lawyers prefer to keep on the safe side and prohibit use of it on any of corporate computers due to possible risks.
I am very grateful for this and I am a happy user of ghc-mod at home for my evening projects. Thank you! Unfortunately for lawyers what counts is the license text, it's worst-case interpretation and if it was tested at court.
This, again, boils down to not being tested in a court. Given how US law system works, unless there have been high enough court decisions on analogous cases, nothing is impossible :(
They are being on the safe side. I might not like it, but I can't do much about it :( On the other hand I totally understand why one might want to protect one's work by licensing their creation using AGPL, so I am closing the bug. I'll give ide-backend a try. |
Okay first I would like you to read Section 13 of the AGPL3: The AGPL3 does not add any other requirements to the GPL3 other than this Please point me to the passage that says that your program has to be under the Therefore the AGPL does not require you to also release your own code under
That is one really messed up policy in my opinion. If everyone did that then I But fair enough, nothing I can do about that policy. Just out of curiosity
I'm not protecting my own work, I'm protecting its users! That's the whole point |
|
Oh also your interpretation of remote interaction is clearly not the intent of the license, see: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingRemotely |
|
The significance of the GPLv3 suite is that it was all heavily vetted by lawyers, including those from many major corporations. The language is legally sound and solid. AGPLv3 for ghc-mod has absolutely no effect on any Haskell programs you build using ghc-mod unless you are actually using it as a dependency. directly. @gleber ghc-mod is not something you use in your software, it's just something you use on your own machine while you build software. Once the software has been written, there's zero trace of ghc-mod. If I check errors with ghc-mod or find out what some type is, nobody else can ever tell later whether or not I used ghc-mod to do my error checking. There's zero reason you even need to check with the lawyers at your company. You use ghc-mod yourself as a developer, it's a tool used by developers. The code you end up with that you publish is the only thing the lawyers need care about at all, and that code has zero connection to ghc-mod. The only time you, as a ghc-mod user, have any need to even think about the AGPL (besides that it guarantees your right to install and use the software however you wish) is if you actually make ghc-mod-based software, i.e. software that is a Haskell developer tool that is itself based on ghc-mod. The use of ghc-mod in your development process is as incidental as the color scheme you choose for your text editor. The AGPL here is completely irrelevant to the actual code you end up writing (again, assuming you are writing software that isn't itself a Haskell-developer-tool-based-on-ghc-mod). |
|
I do agree personally with both of you. And by reading the license I do see things the same way you do. IANAL and actual lawyers set up policies for our company. They clearly want to be on the very safe side of things... I will try to see if there are any chance to get an exception for ghc-mod to allow it's use here. |
|
To hammer home my point: it's about as relevant as if you write software on a system running Linux and are publish the software under a non-GPL license for others. The Linux kernel is GPL, but nobody nobody nobody says that all software you write at all on a Linux system must be GPL. Your lawyers' interpretation is that ludicrous. Ghc-mod is not used in your software, it's only something you use personally, and you should just use it and not even ask for permission. |
|
I see two misunderstandings here:
@gleber You are safe to use
@DanielG @wolftune You seem to assume that @gleber is asking about case (1), but I can't conclude this from this thread; it may as well be that he is looking at the case of building a commercial editor, web-ide or whatever that links against ghc-mod-the-library, in which case his question is very relevant. I don't know for which of the two cases the question is. @gleber The quick anecdote style comparison between the types of licenses:
|
|
To bring in my personal opinion: I'd also prefer if I see the value of copyleft licenses, but their protective effect is usually only strong protecting consumers (e.g. Linux's GPL did very well in protecting home users of Linux-based routers). With development tools, there's usually less need for protection, and a copyleft sometimes makes progress harder here. ghc-mod is one of the main entry points of building something useful on top of the GHC API - which is very permissive - so it would be nice if this entry point was as permissive as GHC itself. For example, I would welcome any web/network-based Haskell IDE or similar tool, closed source or not, and I'd rather have it built upon ghc-mod than some custom stuff. |
|
On Wed, Oct 14, 2015 at 10:50:47AM -0700, Niklas Hambüchen wrote:
In the case of development tools developers are the consumers, do you I think a strong copyleft license is perfectly appropriate here, most If the inconvinience of having to rewrite ghc-mod disuades even one
Why does it need to be permissive? You can build a perfectly good Now I don't recomennd anyone do this but that's what people seem |
That's my point - if I were to write such a thing, I'd much rather use the Haskell interface to ghc-mod (thus link it) than interacting with its process. I agree that if you were just interacting with the process, AGPL would be most effective for our goals, but to get a nice typesafe API, directly linking against Haskell seems a much better way than talking to a process.
I'd rather have more Haskell tools in total - so I'd prefer the creation of a proprietary tool over no creation at all. |
|
My concern is that we may end up with a sub-optimal technical design because of the perceived problem |
|
On Wed, Oct 14, 2015 at 11:24:12AM -0700, Niklas Hambüchen wrote:
Well feel free to write a shim library that just talks to ghc-mod via You also have to differentiate two use cases here an IDE written in
Oh I should've finished that thought, I meant the developer would |
|
@alanz what do you mean? |
|
I am approaching this from a broad view, in terms of the pieces that need to exist to go from a checked out project on a disk to being able to interact with it in an IDE.
I am concerned that a debate about what is the best architecture to achieve this may get sidetracked into suboptimal decisions because people want to minimise the use of |
|
I just wanted to make sure my request was understood clearly. I was talking purely about using ghc-mod as a program running on my workstation plugged in to Emacs under haskell-mode. Unfortunately lawyers did put a blanket ban on any AGPL software regardless of it's use :( |
I would also like to see consensus of effort and design around a primary way in which tooling integrates with GHC. A license which prevents or discourages usage in industry also discourages development in general. Did people ask for a switch from BSD to AGPL3, or was this a unilateral decision? |
|
@mgsloan There's nothing about AGPL for ghc-mod that discourages its use in industry. The fact that some lawyers oppose it is utter stupidy. @gleber sorry about your horrible experience at your work. Your lawyers are incompetent here. Their position is legally identical (i.e. zero legal basis) to telling you that you aren't allowed to read the Haskell Wikibook when programming because it is licensed CC-BY-SA. |
|
I agree that it is stupid that such restrictions exist in some companies. Stupid things can and will get enforced, though. Why create such barriers? |
|
Oh look at this article that says exactly what I'd say in response to that (more or less): http://lwn.net/SubscriberLink/660428/be2ce470dffefc44/ |
|
@mgsloan indeed, why create such barriers? … is a question for the lawyers who are being irresponsible. Nobody here is creating those barriers, certainly the AGPL is not a barrier here. At best, you mean "why fight that battle?" and the question amounts to implying that people should adapt to fit whoever has the lowest level of understanding, least flexibility, and worst judgement… if that person has any level of power. The real answer is clearly for the person who is facing complete nonsense at their work to spend their energy talking to someone with the power to change the nonsense, not spend the time and energy asking the rest of the outside world to adapt to the same nonsense they are facing. |
|
@wolftune We can wax political all we want. The facts of the matter remains unchanged:
I'm not going to argue politics and stupidity of companies and lawyers, since that's completely irrelevant. We have a clear-cut case here where this licensing change harmed someone. If the answer is "too bad," then that's the answer. But trying to say that the user wasn't harmed by the change is ignoring reality. It's also ignoring reality to think that this decision will have no impact on the Haskell community. If you value RMS software freedom above all else, you may decide that this is a positive impact. If you prefer having more collaboration, this impact will likely be negative. |
|
@snoyberg FWIW, I find your points reasonable. I was mostly critiquing the tone of the earlier comments rather than weighing in on this exact licensing decision. I'm much more willing and patient with arguments that say something like:
In other words, I'm okay with arguments about tactics, avoiding unnecessary battles, accepting practical compromises… I think there's strong cases to be made for permissive licensing based on compatibility, practical acceptance, all sorts of other things… I will still speak up when I see people make really unfair or lousy arguments that put the blame entirely on the wrong side. For my view, I value software freedom but entirely recognize that collaboration and acceptance may be in many cases the best strategy to maximize that freedom. Even RMS would agree, even though he's less compromising than I am, he does suggest that tactical compromises make sense. I think Yesod would clearly achieve less collaboration and contribution in today's environment if it were AGPL. I would wish that not to be the case, but I accept that reality. In terms of ghc-mod, I'm not sure it matters because everyone can contribute to and use it regardless of their license preferences for any other software they build. And while it is true in many cases that more contributions and collaboration can happen with permissive licenses, it's also true that there are cases where copyleft licenses maximize collaboration and contribution because they protect a commons that everyone can rely on (not to mention the existence of developers who are more enthusiastic contributors to copyleft because they like copyleft licenses). See https://www.youtube.com/watch?v=UneYZikN85Q for some perspective. In short: I am not arguing for AGPL without consideration, I'm not saying the concern here is meritless, and I certainly care about collaboration. My points in this issue were primarily to reject badly-put arguments. Again, "the lawyers are the ones in the wrong here, but practically, I can't make them change, can we just appease them?" is a sensible practical argument. I think the approach to the discourse matters. If someone suggests appeasing a stupid policy, I expect them to at least continue admitting that the policy is stupid. |
The reason I got involved in this discussion is because Alan Zimmerman proposed working more collaboratively on Haskell IDE tooling, possibly using ghc-mod as a basis. If we were to do this, the code in question would very likely end up becoming used as a library, not just an external executable, and therefore the license very much does matter. If these situations were all resolved, I think there's a real future of having massive collaboration in this space from the community. Instead, I think we're going to end up with fragmentation. I've already expressed these concerns to @DanielG in a private thread. I also expressed that my desire is to contribute exist code heavily to a shared project. I won't reshare words said privately on a public list, but I will say that his response has discouraged me from any desire to contribute to ghc-mod due to his attitude towards me. |
|
@snoyberg without weighing into all the details, let me just assure you that both you and @DanielG have my sympathies, and I see both of you having some valid concerns. I strongly favor pragmatism in general and reject dogmatism. We should all admit that these issues are fuzzy because there's so much we don't always know. Effectively copyleft licensing is about the fear of proprietary co-option that ends up overwhelming / distracting from the main project and/or that gets to the point of significant ethical concerns etc. and there's lots of views and arguments about it all. Sometimes that fear is purely speculative, sometimes it's legitimate, and sometimes focusing on that fear is destructive to other goals, sometimes not… often it's unclear. So, it's fuzzy. My only general goal in most of the discourse is to rid the discussion of the all-too-common really bad ideas (e.g. the view copyleft is somehow itself unethical while proprietary terms are not, or the view that some GitHub folks have suggested that says copyleft is bad for business despite, well, the fact that GitHub is based entirely on a copyleft project (Git)). In many regards, the views people have are self-fulfilling. People think you need to avoid copyleft for business so they do so and thus it proves true that successful businesses avoid copyleft in some cases but maybe their pure belief is the only substantial cause of that correlation… or maybe not… At any rate, if I see anyone expressing bad attitudes toward others, I call that out too. Effective collaboration requires respect and consideration for everyone involved. Back to this specific case, I actually think that most of the arguments I'm seeing here against copyleft are in the lousy vein of "we can't use copyleft because other people don't like it". It seems no business or project in this case actually needs to have any problem with it aside from having some weird anti-copyleft ideology. Because what's the harm in IDE tooling being copyleft? That's still not clear to me other than "it's harmful because people believe it's harmful". |
|
As I mentioned, we're currently discussing large scale collaboration. An On Thu, Oct 15, 2015, 8:45 AM Aaron Wolf notifications@github.com wrote:
|
|
@snoyberg thanks for clarifying about the concrete example. I don't know what short days analysis scripts are. I personally feel very wary about the idea of proprietary libraries that let people run code analysis via some web service. Anything that creates a situation in which the community comes to rely on a proprietary web service in their development and people who don't use that are left with second-class options is something potentially destructive to a healthy community. For example, a concern raised about LLVM is the prospect of Compiler As A Service (via extra modules added to LLVM) where people would end up relying on a proprietary service if they want effectively optimized code (and, of course, there's then much less ways to really understand or rely on the whole nature of what your code is even doing in the end). However, that is a purely speculative worry, of course. I just hope we don't see that ever. So, I definitely think proprietary software can range from mildly unfortunate (would be nicer if free/open) to much more troubling, and it varies case-by-case. In this situation, if licensing that permits the use you mention would result in the free software we all use to be that much better because of more collaboration and support, I do see that as a strong argument. And my tacit support would depend on whether the proprietary use cases themselves threaten the community commons in the long-term or are just extraneous use cases (which I am not clear on right now). I do trust your judgment and assuming you have valid points here. Anyway, I'm only a modest meta-level ghc-mod contributor (bug-testing, etc., helped get it working with Stack…). I'm trying to do my best to support whatever ends up most serving the community well overall. I do respect and understand @DanielG's concerns too (although I won't necessarily say I agree with however he may have expressed them to you). I hope the result works out well for everyone, and I hope that people will continue to feel welcome and encouraged to contribute whether or not decisions match their particular political ideologies… |
|
Sorry, swypo. I meant "short data analysis scripts." This is very much the kind of thing finance and data science companies would be interested in providing. Anyway, I've made my point - as have others - about the affects of this licensing change. It's been made clear to me that this opinion will be ignored, and that I'm seen more as a competitor than a collaborator, for some reason I can't comprehend. We all now get to make our decisions about how to spend our time, and I know what decision I'll be making. |
|
To go back to the discussion of AGPL and policies prohibiting it: The discussion here has portrayed @gleber's employer as irrational in prohibiting the use of GPL software. Although I wouldn't impose such a policy myself, I don't think it's irrational. To us as technical experts, there's a clear line between running a purely local process and running a service available to others. We are generally very aware of which side we're on, because we're trained to think through precisely what's happening. But in some contexts and to some users, it may not be so clear whether Program X has "users interacting with it remotely through a computer network" thereby triggering the additional disclosure requirements of the AGPL. There might be accidental users, and how are you expected to disclose source code to them? Especially for a company that does run closed-source, for-profit services, the risk of somebody muddling up the difference between local and remote services may be great enough to impose a blanket ban on AGPL, even in a context where GPL is perfectly reasonable, simply because it's possible to accidentally violate the AGPL in a completely different way than the GPL. (Note: This is not legal advice, and in particular I offer no opinion regarding @gleber's usage or the appropriate license for |
|
@conklech Stop apologizing for bureaucracy. Yes, overly-strict rules that avoid things a business doesn't want can be understandable as rules. That doesn't mean a given case where the rule results in nonsense is rational in any way. This particular case, the concern the rule is about has zero actual relevance. I wasn't saying that the business in question was incompetent, I was only addressing the specifics of this case. I suggest that in cases like this, the programmer just use ghc-mod and don't bother asking for permission or telling anyone, doing that would have no consequences. |
|
@conklech's analysis portrays exactly what's happening at my employer. The ban is centered around accidental use of AGPL software in a highly interconnected code base, which we have at the corporation. According to analysis of the lawyers, if a single accidental use happens, all interconnected code becomes "infected" by AGPL. @wolftune, I am sorry to say, but you are wrong about the concern having zero relevance. It is of non-zero relevance, at least in US law system, all the way until the license has been tested in court at least at Supreme Court level. I have been attending law school for many years and the most important thing that I have learned is that laws are not and does not have to be in any way reasonable and common sense. Given that laws in US are basically written by courts, until the license has been thoroughly tested in courts, there is always a risk about the way it will be interpreted by a court. |
|
@gleber your company is already likely in violation of a whole bunch of patents because it is impossible to write software today without that being the case (given the absurdity of patents today). There are tons of things about your work that you could be equally general about in terms of vague potential legal risk. There is no way to have a completely guaranteed legal safety in today's environment. You can be certain as much as is it is worth discussing that if you use ghc-mod specifically in your own development, you will never be legally required to release the code you write under AGPL. I'm not making a legal statement about interpretation of AGPL in general. It is absolutely unambiguous that checking types and errors with ghc-mod results in absolutely zero connection between ghc-mod and the code you end up delivering. This is not a case of "accidental use" and has no risk of becoming one (again, this is all assuming that you are building products that aren't actually themselves about code development in Haskell). Addendum: Haskell is particularly robust here, everything is functional. It's absolutely clear at the end of the day exactly what dependencies your code has etc. As long as ghc-mod is not an actual dependency for your final software to either compile or to run (and you don't actively copy specific code from ghc-mod into your code), then AGPL is completely irrelevant, period. |
|
I'd like to add one more point of view to the discussion. Many companies use AGPL as part of their dual-licensing business model: 'AGPL or commercial license'. Their whole business model relies on the broadest possible interpretation of AGPL, basically pay us or open source everything you have. This it not what AGPL says but this threat is good enough to ban all discussions with such companies. And ban AGPL as a prerequisite to never ever be contacted by lawyers of such a company. |
|
@gracjan that framing is a bit overblown. That business model does not rely on a broad interpretation of AGPL. For example, a forum software that is AGPL/proprietary dual-licensed would be simply saying either (A) "if you want to make a proprietary derivative of this forum software, you'll need our proprietary license" or (B) "we already have a proprietary version, and if you want those features, you have to get a proprietary license". There's absolutely no valid way to interpret AGPL to say that a company would have to release their separate music playing software or their main company website or their Android app under AGPL just because they run a user forum that is AGPL. The AGPL does not discriminate about who uses the software, it only applies to derivatives of the software specifically. Yes, some software is more upstream libraries that are used by far more derivatives. ghc-mod would only be used in derivatives that are Haskell development tools (not by any other type of Haskell project); but RethinkDB which uses AGPL, is a type of software that is much more fundamental as a piece of derivative softwares. So they say, "if a project is willing to use AGPL, then this DB is usable freely, otherwise, we offer a proprietary license". What's wrong with that? That is indeed the entire point of AGPL: to make software that everyone can use but that blocks the building of proprietary derivatives. Let's be clear: the answer for anyone concerned here is basically to have their lawyers contact Eben Moglen at the SFLC, and he can absolutely and clearly clarify to the lawyers where the AGPL does and doesn't apply. It is not a good answer to say "people have a totally wrong fear-based misunderstanding, let's make sure to bow to that and validate it." As I said before, there's only one way to "never ever be contacted by lawyers of [a company that makes completely invalid but scary claims that cost time and money to deal with]": don't make a business, especially not a software business. The primary threat is from patent trolls. Now, if you want to argue that AGPL companies even fit that description ever, I think it's fair for you to accept the burden of providing at least a single citation of any instance in which this sort of thing has ever occurred at all. I would indeed be interested to learn about such a case. But if it was indeed an invalid over-interpretation of AGPL, that still wouldn't justify avoiding the license. Really, stop advocating for decisions based on irrational fears. The complaint that ghc-mod as AGPL blocks a specific haskell-development-tool derivative is the only legitimate complaint anyone has brought up here. And then it's a political matter of whether we should or shouldn't allow that sort of derivative (obviously that legitimate debate centers around whether one sees "Open Source" as a tool in building proprietary software versus "Software Freedom" as a political/ethical goal). The other argument of "AGPL is bad because some people have completely irrational misinterpretations that are plainly wrong" is not something you should expect anyone to bow down to. Please focus on actual rational concerns. The solution to the fear-based wrong thing is not hard. Contact Eben and SFLC or other actual sources for knowledgeable expert judgement, i.e. educate people to remove the simply wrong ideas from the equation. |
|
@wolftune: I do not have any questions regarding AGPL. I've read how RethinkDB guys explain AGPL in context of RethinkDB and it is prefectly reasonable. I just mention that there are companies that try annoying shenanigans, unfounded, but real. If legal risk is not real in your book, then I do not know what is. |
|
@gracjan maybe the legal risk is real in the same way that absolutely insane patent troll legal risk is real (i.e. real but totally illegitimate)— do you have a single example of any actual situation? I'm concerned mainly about your implication that sounds like "some bad actor uses X illegitimately to threaten people baselessly, but there are real legal costs involved, so that means we should reject X entirely". You might as well say that Microsoft was doing scare-mongering legally over Android, so nobody should ever use Android or build Android apps. Or that there was a Linux lawsuit for VMWare, so nobody should ever use Linux… There are good arguments saying that software patents as a whole should be eliminated and even that the entire patent system should be eliminated, just as there are logical arguments against AGPL for various principled reasons. But a bad argument is "patent trolls abuse the patent system, therefore we should reject patents". Anyway, even if you do have evidence of AGPL abuse (I'm still curious to see any), it has no connection to thinking there's any threat of AGPL abuse from ghc-mod specifically. Similarly, because patent trolls exist is not justification for worrying about trolling abusiveness from every entity that ever has a patent. Again, I'm not saying no legitimate arguments exist against patents or against AGPL, but you don't seem to be making one of those logical arguments. And I think you really should accept that this can all be dismissed as FUD if you can't find a single real case where there was a problem. |
|
If the confusion around AGPL was not real then we would not have companies banning AGPL outright. Note that some of these companies are pretty big and have pretty good lawyers. It is hard to imagine that they were not able to understand a point in a license when a couple of programmers in this thread claim with certainty that they fully grasp all consequences of it. I do have an example of an attempt to use AGPL for a business model 'pay us or open source your whole application stack'. Note that it relies on misapplication of AGPL. I'm not able to share more details, sorry. |
That's not a logically sound assertion neither inductively or deductively. That sounds like you're saying companies never make fear-based, FUD-based decisions. Anyway, the reason Google bans AGPL is because they are politically opposed to it. They don't ban it because they are freaked out about the consequences of a Google employee using ghc-mod or whatever. Google wants AGPL to die because the concept of AGPL is a threat to their business model. They don't publish most software, they run it over servers and let people access the servers. They don't want to see a big commons of useful software that they cannot exploit.
Sure, I'm not doubting that sort of model exists, but it would need to be software that is fundamentally a part of the stack and not some accessory tool like ghc-mod. Look, the goal of AGPL is to stop people from making non-free software. The GNU manifesto says so right in the license. There's obviously a major and legitimate political debate here between two sides, one that wants to use "Open Source" specifically to make proprietary software and one that wants to see the end of the existence of proprietary software. The former side is quite interested in spreading FUD and otherwise working to undermine adoption of AGPL. You just don't seem to be framing your argument in a way that relates to that real debate, you seem to be saying there's something broken about AGPL. Let me make this super clear: although it is not applicable to all AGPL projects, when there is a real case "pay us for proprietary license or open-source your whole stack", that is actually a more flexible and gracious offer than the common approach of only "pay us for a proprietary license" (i.e. simple proprietary-only licensing). The idea is that if you stick to AGPL too, then you can use it under those terms. You seem mostly focused on the idea that people might inadvertently use AGPL software. Well, don't do that. It's not that hard to simply be thoughtful and to understand that you can develop your software and use ghc-mod without it affecting your end product, but that you cannot use an AGPL project as actually part of your core integrated stack unless you are okay with following the terms of the license. In other words, all you have to do in any case is follow the terms of the license. The terms allow the use of a development tool like ghc-mod with no effect on your end product license, and the terms require you to use AGPL for the end product if you actually build a derivative work. Again, it's perfectly reasonable to bring up, as Snoyman did here, a desire for ghc-mod to be permissively licensed specifically in order to build a proprietary ghc-mod derivative. The only reason that request would be denied is because of a political view that is actually opposed to the creation of such proprietary derivatives. That may not be a resolved debate, but it is a reasonable one on both sides. In contrast, the FUD-based argument doesn't deserve any deference. |
|
I don't think we're going to get any more productive discussion out of this thread so I'm going to close it. |
Use of AGPL restricts use of software licensed under it at corporations, since AGPL is not well defined and leads to ambiguity, which corporations' lawyers do not like.
The text was updated successfully, but these errors were encountered: