Consider relicensing to BSD #164
Labels
No Label
blocked: dependency
blocked: info-needed
bug
duplicate
enhancement
fixed in HEAD
help wanted
hs:arrows
hs:brackets
hs:classes
hs:comments
hs:do-notation
hs:guards
hs:lists
hs:operators
hs:patterns
hs:records
hs:types
invalid
language extension support
layouting
needs confirmation
priority: high
priority: low
question
revisit before next release
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: hexagoxel/brittany#164
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Brittany seems very good, but unfortunately the use of AGPL makes it much harder to use at work than I'd like (custom sign offs etc) - it also prevented me using Brittany at my previous work place. Is there any way you'd consider a BSD license? To be clear, we would love to contribute any changes we make to Brittany (if any) upstream, because I think that's both morally correct and in everyone's best interest.
It goes without saying that the choice remains 100% yours, and I thank you for your open source work in either case!
See DanielG/ghc-mod#638, which similarly discusses the choice of the AGPL in the same sort of case of a non-library dev Haskell tool and its use in workplaces.
@wolftune
Thanks for the link.
No. To this end I have edited your comment to a plain link. Feel free to privately give feedback to this action.
@ndmitchell
Thanks for the compliment and for reaching out!
Well, certainly. You could for example acknowledge the time I invested in this project at a pay-per-hour rate similar to typical company lawyers, and we'd have a deal! I jest, this project is not worth as much, especially to any single company out there. But it feels like an appropriate response to put things into perspective.
I keep spending my free time to work on brittany, right now on supporting ghc-8.6 which is coming in rather soon - HIE will be left hanging otherwise. And while the transition is really mechanical, adding CPP around almost every GHC API pattern match and testing it against several GHC versions takes time.
Yet this request is motivated, and caused, by policies that come from what I assume to be well-paid lawyers and decision-makers.
So let's keep this constructive: Switching to BSD is on the table. What do you offer, other than potential future contributions? I am open to reasonable offers, or other ideas to find a fair exchange between me and interested companies. I may add that I'd also be interested in funding for the development of missing features such as data/class/instance layouting. I have a clear list of (several more) steps towards what I'd consider a proper 1.0 version release.
You may contact me privately for such, if you prefer.
To any past contributors, @wolftune : To be clear, I still am interested in any input you might have regarding a potential license change, but I'd prefer private feedback - this will be mostly be my decision after all. If a discussion is not directly connected to brittany it does not belong here, out of respect for those watching the repository. Also I am not willing to moderate a public discussion, and unmoderated public discussions have been far too tiring in the past for me.
@lspitzner first of all, let me thank you for creating brittany, it's the best formatter for Haskell code.
I'd just like to comment on the rationale for using AGPL, it's not entirely clear to me. It seems you have spent lots of hours on this project, made it open source, but restricted legal terms for companies to use freely. I understand the motivation, but not the chosen path for compensation of your time.
Business models for open source work are not infeasible nowadays, but AGPL would only work if: you provided a monetized license to companies, ie. they'd buy a yearly license for brittany with exclusive rights for their work.
I haven't seen asking it work in practice by asking companies how much your software is worth to them and resulting in any kind of mutual exchange.
I'd recommend listening to https://changelog.com/podcast/92
@domenkozar just a technical clarification: AGPL, like all approved Open Source licenses has no discrimination on who the users are. Unlike proprietary non-commercial type licenses, AGPL software is absolutely free for any entity, including for-profit companies. There's no clause restricting commercial use whatsoever.
If I understand right, brittany isn't even being requested to be used in any derivative software let alone distributed outside a company.
Under AGPL, any company may already freely use brittany as a development tool and may even create modified derivatives or otherwise distribute the software freely within the company without restrictions.
@wolftune I know, but @lspitzner is essentially putting on the table that he has chosen a non-permissive license, which usually blocks enterprises to use OSS.
In theory, companies should just contribute back any modifications made to OSS, in practice it just means a dead end for both.
If you want your work to be valued, why would you require them to open source some hacked thing together, while you can ask for monetization, if you want to be compensated?
@domenkozar I don't want to belabor the point, but I don't want to talk past one another. non-permissive licenses that are still Open Source do not block enterprises from using the software. If that were the case, enterprises could not use Linux, Bash, LibreOffice, or even Firefox. Enterprise use of copyleft software is widespread and totally normal. Copyleft only prevents the publication of proprietary derivatives. So, in the case of brittany, there's no requirement to open source anything. It's just a tool that anyone (enterprises included) can use within their own development of other software, not that different from using Firefox's developer tools while building a website (which is different than building a proprietary derivative of the developer tools themselves).
Furthermore, even a hacked-together modification to brittany itself does not need to be open sourced. The license doesn't require that unless the modified version is distributed on to others (which isn't likely to happen in such a case anyway). AGPL has no requirement to open source modifications used privately within an enterprise.
I want to respect the request not to argue about the license choice in detail here. I'm just aiming to clear up what seems to be misunderstanding (or at least statements likely to be misunderstood by readers) about the factual nature of the license.
@wolftune AGPL is different, it's not just about publication of property derivatives, that's what GPL is about. FYI :) If you have SAAS, you're compliant with GPL if you have modifications of OSS since you don't distribute the source, but you're not compliant with AGPL.
Anyway, I'll leave this discussion be. There are two ways to go:
@wolftune How is "others" defined, here? How does it include clients but exclude coworkers? (EDIT: swapped "clients" and "coworkers" by accident.)
@domenkozar w.r.t. brittany, this would only be relevant if your SAAS solution incorporated brittany within its functionality, e.g. if you offered haskell formatting in your interface, right?
@ElvishJerricco correct. Any entity like a corporation can consider all internal use of software to be private. If software is not distributed to someone outside the company, then distribution/conveyance clauses in GPL / AGPL do not apply.
@wolftune Could this be a problem for consultancies? If a consultancy writes software for a client, are they not allowed to include scripts that compile brittany and run it on the source? i.e. they'd have to tell the developers at the client company to have brittany preinstalled?
@ElvishJerricco This thread is not the place for continuing this discussion, especially in deference to @lspitzner's request not to moderate such a discussion. See https://www.gnu.org/licenses/gpl-faq.html for general relevant questions. Otherwise, there are many places online to discuss complexities of licensing.
But briefly: your scenario only is an issue if the company made changes to brittany that they care to keep private. Otherwise, they could just provide the updated source anyway or include the unmodified source. There's nothing in AGPL that restricts distribution of brittany as long as source and license are present. Scripts that compile brittany would be fine.
Please respect the request to keep further tangential discussion private. I won't post here further.
I have considered this request. I have read a fair bit on the legal background around this, and what would be necessary for a change of license, and its consequences.
Then I stopped, because I realized two things:
To give a clear answer: For the time being, no, I will not change the license. I don't even want to argue whether this is an issue. I want to simply leave that question open, while marking it as wont-fix due to the high cost the requirement analysis alone would incur.
To the people negatively affected by this decision: Feel free to continue asking me for changing this, but I might just mentally label you as "asking for free stuff" and move on.
Now, let me put my focus back to actually working on the project.
Oh, and one more thing. This is not meant as an accusation, but a simple observation and note on open source maintenance in general: Making these kind of decisions is not fun - I am a speaking as an open-source dev, not as an open-source lawyer, after all - and still I do feel responsible for making this decision, and making it a clear and well-informed one. This kind of mental pressure might, in theory, contribute a tiny bit towards a maintainer simply taking a break from their self-inflicted job.
It's been almost 2 years since this option was last discussed. The choice of license is still a blocker for using Brittany in many enterprises. Has anything changed that makes this issue worth revising ?
I'm just one of the people who discussed above, but I don't have any reason to think anything has changed. And I'll reiterate: there does not exist a single enterprise that has any legal trouble with using Brittany as is. Brittany's license is not a blocker. But enterprises might just have their own internal policies that bar the use of perfectly safe and perfectly legal software for whatever reasons (presumably some mix of excessive unwarranted misguided caution and/or political reasons).
This project has multiple copyright holders at this point. Not all are listed by name, but every PR that got merged implicitly was licensed under AGPL3 under the "in=out" assumption. Just theoretically speaking, revising the license to anything more permissive than AGPL3 would - in addition to me providing the "base contribution of this project" under a more permissive license - therefor require for every PR to either
a) obtain the relevant license from its copyright holder
b) legally argue why that PR is not worthy of a copyright (mundane dependency version bumps might fall in this category)
c) revert that PR, rolling back that functionality (until it can be replaced by a rewrite that is appropriately licensed)
So at this point even I cannot give out any sort of more permissive license without a serious amount of work; I cannot even give out individual commercial licenses if I wanted. This is something I was not really aware of when I started accepting PRs. but something I can live with.
It does sadden me that we live in a world with these annoying legalistic constraints, that we as a society have not yet developed a license that appropriately balances the rights of open source authors (so that their work does not get exploited commercially) but still allows others to use the open-source products with sufficient legal certainty (and let's just accept that "sufficient" is subjective). But this is not something I can do anything about.
FWIW, this multiple-authors-under-copyleft is specifically the most significant trust-building tool for projects that want to remove their own capacity to unilaterally go proprietary and undermine the free/libre/open assumptions the community started with. "It is easier to avoid temptation than to resist it" as Dan Ariely says. By locking in the freedoms, we can't be swayed to undermine them because it's too much hassle.
I do generally prefer this to be intentional so that people know what they're doing rather than feel bitten by an outcome they didn't expect.
All enterprises I have worked for have internal policies that ban AGPL3 for legal reasons, so I think this is a real problem. I wouldn't be asking otherwise.
This is a fair point, but not a blocker. A survey quoting all the contributors could be run, allowing a reasonable amount of time to object - if no one does, then the license can be changed as implicitly agreed by all the contributors.
This is a valid point too, but best not discussed in this thread.
I'm not saying the problem doesn't exist.
The core point is that the ban on AGPL3 is not because using it presents legal problems per se. There are two types of bans, one that blocks AGPL3 code from being included in a company's products which are themselves licensed in any other way (such a ban is legally necessary unless the company accepts switching to AGPL3). The other type is a prohibition on using AGPL3 tools internally (as in using the binaries to do things), and there is absolutely no legal justification for that ban at all — any time it exists it is either lawyers just doing their common absurd precautions (like the real-world analogy of the subset of Jews who avoid beans during pesach because somehow beans are maybe some sort of gateway food to prohibited leavened bread or some nonsense) or it's just political, making the ban wider just to be anti-AGPL3 even though there's no actual legal issue. Again, there does not exist a legal reason to prohibit the productive use of binaries licensed AGPL3, which is totally unrelated to including AGPL code in some other software.
You are nonetheless correct that even if the reasons are fundamentally wrong or faulty, the existence of the bans does create the problem (i.e. I'm blaming the bans because the AGPL itself isn't at fault). It is also true that even when totally in the right, it can make practical sense to play along with the way things are. Just because I have absolutely legal right to bike on a particular road doesn't make me any safer in case of a reckless driver hitting me. And software development happens in the world that has these AGPL-prohibitions regardless of their lack of justification.