I would like to publish code for an application under an open source license like BSD, MIT, or Apache 2 which allows for changes and derivative works to be contributed back to the open source project or kept fully proprietary if the developer wishes, but where the code or derivative works can never be re-licensed under a GPL/Copyleft license. My concern is some group taking my code, relicensing it as GPL/copyleft, and then amassing enough momentum behind their GPL fork to dilute the momentum of the proprietary-able, commercial-friendly open source version.

In other words, users/companies may:

  • Distribute binaries without the source code (proprietary product)
  • Distribute source code with or without their additions
  • Submit changes back to the project

But may NOT:

  • Take code from the project and re-license it as GPL or any other form of license which COMPELS a user or company to distribute the source of their derivative works, making it untenable for use in corporate environments.

Is there a license or generally accepted clause that could be added to the BSD or Apache 2 license to accomplish this intent?

  • 2
    BSD does this quite well. Any BSD code that gets re-released under GPL by people other than the copyright holder (you) are technically illegal and GPL does not apply in such cases. This is why GNU people tend to avoid BSD projects like Tcl. If you want to enforce this I guess you can do what the busybox project does and monitor people using your code (in the case of busybox they're enforcing GPL, but you can enforce anti-GPL). See the GNU page for GPL compatibility: gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses
    – slebetman
    Commented Nov 22, 2017 at 3:44
  • 9
    @slebetman Please avoid answering questions in comments. They can not be vetted by the community, nor accepted as the solution to a problem.
    – pipe
    Commented Nov 22, 2017 at 13:03
  • 4
    @MikeC. I think it's important to establish what your actual goal is. Are you trying to establish a moral/ethical stance for your software? Or do you actually want to prevent specific people from doing specific things with your code? And the most important question, how much are you willing to spend on legal fees to achieve your goal? Unless you're actually willing to sue people, the debate is mostly philosophical. If you actually plan on enforcing your license legally, then craft it carefully, but otherwise, don't worry about it and focus on your code instead.
    – barbecue
    Commented Nov 22, 2017 at 16:53
  • 6
    The GPL doesn't compel the user to distribute source code in general. It only compels them to distribute source code if they distribute compiled code, and even then only to the same people.
    – bdsl
    Commented Nov 23, 2017 at 0:29
  • 7
    @LukeA.Leber I doubt that license of yours has much of a legal effect, at least if you don't properly define “viral” therein it would probably be easy to forge a mostly GPL-equivalent license that could be still combined with it. — And anyway I have to remark that this whole thing is rather silly. There's not really anything you could gain from such a licence over a proper dual-licensing (GPL + commercial license). The only thing the license could possibly accomplish is disrupting the GPL ecosystem as a whole. If that's actually your goal then you're being hypocritical, don't you think? Commented Nov 23, 2017 at 0:53

11 Answers 11


the code or derivative works can never be re-licensed under a GPL/Copyleft license

Ironically, I think the best practical strategy to accomplish this is to license your work under a (very weak) copyleft license that is incompatible with other existing copyleft licenses. Your proposed terms are not "permissive" as the term is used in FLOSS parlance: much like the mechanics of the GPL, you want your license to say, "Everyone may use this however they like, except for this set of restrictions that may never be removed." Your set of restrictions happens to forbid "licensing under conditions that compel downstream source disclosure" instead of the GPL's restrictions that require source disclosure. In other words, whereas the GPL's opponent in employing copyleft is non-free licensing terms, your opponent in employing copyleft will be copyleft terms (except for your own copyleft terms).

The like-minded folks in Redmond are prepared to aid you: the Microsoft Public License (Ms-PL) is a reasonable choice to accomplish this goal. The MS-PL imposes copyleft terms on source distributions only, while binary distributions carry only the minimal requirement that they be licensed under "a license that complies with this license". Since the Ms-PL does not impose any particular requirements for binary distributions beyond attribution, this compatibility is quite easy to satisfy. (It is my guess that Microsoft deliberately engineered this license to be as permissive as possible while remaining incompatible with the GPL.)

On a strategic note, I advise you to consider this decision carefully, for the practical reason that GPL compatibility is a valuable asset in a license. Without it, downstream authors will be unable to make use of GPL'd code and your own code in software they distribute: you force them to choose between GPL options and your own offering. Using a simple permissive license allow anyone to use your code in proprietary projects just as you would like, though it will also allow for a future when some downstream modifications of your project (authored by some other person) might not be available to authors of proprietary software. Weigh your dissatisfaction of such a possible future against a possibly loss of interest in your project for its GPL incompatibility.

  • 31
    "how to prevent having a bunch of GPL take a project I release under BSD or MIT by taking my code and re-licensing it as GPL" other people licensing their contributions as GPL doesn't change the license that you can distribute your code as. How they license their code has no effect on you. Stop wasting your time and go build some software.
    – mrr
    Commented Nov 21, 2017 at 21:29
  • 30
    @MikeC I have the specific problem that it doesn't help me understand what you're trying to prevent. Your worst case scenario, as I understand it, is that someone sets up a GPL fork of your project that competes with your own. However, since your objective is traditional commercial success, such a GPL fork can't begin to compete with you, right? The GPL fork has a totally different audience. I'm not sure why this is a problem.
    – apsillers
    Commented Nov 21, 2017 at 22:28
  • 15
    @MikeC. Again, it seems like you are telling me why the GPL applied to your project/market will naturally fail. If that's so, then let your project exist with the GPL and let any GPL-licensed fork meet its natural outcome (i.e., its licensing terms will be inferior for your use case, and your non-GPL project will naturally prevail. Success!). If your motive is purely moral opposition rather than rooted in a practical outcome (e.g. better software, commercial success, etc.) and GPL compatibility is moral anathema to you anyway, then the Ms-PL should suit your needs as detailed in my answer.
    – apsillers
    Commented Nov 22, 2017 at 14:21
  • 7
    @MikeC. Finally, to readdress your concern about a GPL fork as clearly as I can: even if the GPL fork becomes huge, is state-of-the-art, and goes so far as to drive your original project into relative obscurity, that seems like it would only give you a even stronger platform to say, "Hey, software development shops, I have a project that is quite similar to [famous GPL fork] except you can distribute it in your proprietary software! How great is that?" People who want your software for proprietary distributions will only contribute to your original project, so you will always have contributors
    – apsillers
    Commented Nov 22, 2017 at 14:38
  • 15
    Perhaps I'm wrong, but if people are contributing to the GPL fork instead of an original permissively-licensed project, I seriously question whether they'd choose to contribute to your project if it were under a GPL-incompatible license instead. In any case, I think(?) I've answered all your questions; it is up to you to decide what to do at this point. Best of luck with your development! Please let me know if you have more specific questions, of course.
    – apsillers
    Commented Nov 22, 2017 at 14:39

To my knowledge there is no such license. Note that this license may not be considered an open-source license. In no case would such a license be a permissive license that could be compatible with MIT or Apache 2 projects. Any wording to exclude copyleft licenses would probably also exclude any other open source licenses, so that your software would only be usable either in projects using the same license or in closed-source projects. That seems undesirable.

In general, permissive open source licenses and copyleft open source licenses both try to maximize freedom. They generally have the same intention, but take different avenues. It is important to recognize that both approaches have merit, even if you prefer one of them:

  • Permissive open source licenses try to maximize freedom for immediate users of that code, i.e. developers. E.g. code under the MIT can be used freely in open source and closed source projects. This freedom comes at the expense of user's freedom, who may not be able to view and modify the code if they received the software as closed-source.

  • Copyleft open source licenses try to maximize end user freedom, so that everyone who receives a copy of the software can read and modify the source. This is only possible by restricting how that code may be used, i.e. only in a manner that does not strip end users of their freedom.

    The motivation for copyleft is not a sense of fairness that modifications should be contributed back to the community, but a sense of end-user freedom.

There are licenses that try to find a balance, for example the LGPL: this restricts the copyleft properties only to the LGPLed component, but does not affect the whole software system in which such a component is used.

If you were to create a license that would exclude copyleft licenses, this fails to be a permissive license because it does restrict how the code can be used. You are much closer to copyleft ideas: in order to protect the freedom to freely decide whether modifications can be published as closed-source or under the same license, you sacrifice compatibility with other open-source software.

  • 2
    you are correct about copyleft being more focused on end-user freedom than permissive licenses like BSD. I would add that copyleft also protects developers interests. I think this facet is particularly relevant for the question, so I've posted an answer.
    – hackerb9
    Commented Nov 22, 2017 at 21:04
  • 5
    LGPL is excellent.
    – Joshua
    Commented Nov 22, 2017 at 22:19

If you release your code under a permissive license, it is not possible for anyone to "relicense" it under a less permissive one like the GPL. By issuing a permissive license, you grant everyone the right to use your code in any way you choose. If someone, say, adds your code to a larger GPL'd product, that does not in any way affect your original license: everyone can still use your code in any way your license permits, even if they happen to find it as part of something with a more restrictive license like the GPL. You have granted them the right to use your code--but you have not granted them the right to control anyone else's use of it. That right remains with you. If your code is included in a GPL'd product, that product's license cannot add restrictions on the use of your code, only on the larger product as a whole. Even if its license claims to apply to your portion of the larger product, such words are legal hot air. You, and you alone, control who uses your work.

Most of the popular licenses allow mixing and matching of software products that work together without affecting each other's individual licenses. Android, for example, is Apache licensed, but requires the Linux kernel (GPL) and SQLite (public domain) to operate.

  • This is really what it boils down to. OP may be under a misconception that someone else can change the license of his code, which is not really practical to do in most cases. Large legal budgets can accomplish anything though...
    – barbecue
    Commented Nov 22, 2017 at 16:55
  • Lee Daniel Crocker says, "You, and you alone, control who uses your work". I think I know what you're saying, but perhaps you may wish to clear it up a bit for people who are new to this. Permissive licenses explicitly allow anyone to use the software for whatever they want. That is, you cannot literally "control who uses your work". This can be a mixed blessing: companies are more likely to use your work because they have no obligations, but then your work might effectively become a closed source project as they develop it internally. (See my answer below about Microsoft and BSD).
    – hackerb9
    Commented Nov 22, 2017 at 21:30
  • 4
    YOU are the one who issued that license. You exercised your right to control the use of the work by telling everyone "go ahead". No one else has the right to do that, or to undo it. If a company takes your code, puts it into a proprietary product that they develop in-house and never share, that in no way affects your code. It's still licensed exactly as you licensed it. Commented Nov 22, 2017 at 22:47
  • 4
    @MikeC: They can do that, but they cannot restrict anyone from using your code under the terms you have licensed it under. At worst, if your license permits it, they can modify your code and release the modified version under a different license. So, yes, they can make a GPLed MyFreeProject fork (just like they could make a closed-source MyProprietaryProject) based on your MyProject, but your original MyProject code will still remain BSD/MIT licensed. Even the parts of it that are included (without modifications) in the GPLed fork. Commented Nov 23, 2017 at 23:58
  • 3
    @IlmariKaronen and that (derivative works containing parts that are under a copyleft license) is exactly what OP intends to stop. Commented Nov 24, 2017 at 9:47

Just to add my 5¢, I agree with the great answers above that suggest an Open Source license such as BSD might be what you want.

However, if you want to be as far as possible from copyleft (which might be a wrong choice), then there is a "license" that suits your goal well. The strongest "anti-copyleft" is called all rights reserved: a proprietary, traditional copyright.

No one can stop you from redistributing your proprietary source code publicly, if you wish to. You can still redistribute binaries and charge money. You can even sub-license the sources to some commercial companies under even more convoluted terms.

But, your software wouldn't be Open Source. No Open Source distribution would include you code, neither source, nor binary. Are you okay with that?

You might get into mixed distros, like nVidia drivers years ago were. There was a binary blob with no source code, and people used it anyway, because everybody loved to use their accelerated OpenGL. But to pull this off your program needs to solve a very special problem, extremely well.

Mostly, such behaviour provokes a rewrite from scratch under GPL. Think about the GNU userland, for example.


The BSD license basically already does what you're asking for, or at least effectively.

GPL-ed programs sometimes use BSD modules. When they do that, they obey the BSD license which says that the license is to be preserved in source code redistributions. Users of the GPL-ed program are free to take a BSD source code module from there and use it under the BSD terms.

A BSD-licensed module doesn't become GPL-ed when it is used in a GPL-ed program. That is a misunderstanding. Each piece of the program retains its respective license. What is legally required is that all the licenses in the combination must be compatible. A piece of BSD-licensed code can be combined with GPL-ed code because it is compatible with the GPL.

An article on license compatibility on the GNU website, written by Richard Stallman explains it thus:

In a combination of programs under lax licenses, each part carries the license it came with. When the code is merged to the point that the parts can't be distinguished any more, that merged code should carry all the licenses of the merged parts. Since all the licenses are lax anyway, this causes no practical problem except that the list of licenses gets long.

People who take BSD code and then alter the license with additional GPL-like restrictions are acting in bad faith and should be called out.

The BSD license doesn't exactly say that it must be preserved verbatim, but rather:

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Still, the strict, cautious interpretation of this is: hands off; do not add additional restrictions.

We could contemplate making a small modification to the BSD license which clarifies that no new restrictions may be added to the reproduced copyright notice, conditions and disclaimer. Even if that is found to make no effective difference, it would raise enough uncertainty that it's not worth it compared to using the standard license that large numbers of people and organizations understand.

  • 1
    This is wrong, code which is not GPL becomes GPL when it's combined with GPL code, this is the definition of GPL compatible license. From gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatMean "they also permit distribution of such combinations provided the combination is released under the same GNU GPL version. The other license is compatible with the GPL if it permits this too."
    – Oleg
    Commented Nov 26, 2017 at 10:16
  • 1
    @Oleg You're somehow not understanding "the combination is released under" and have not hit upon gnu.org/licenses/gpl-faq.en.html#GPLModuleLicense in the same document.
    – Kaz
    Commented Nov 26, 2017 at 15:40
  • 1
    @Kaz Rather than saying "combined with" which could mean including in the compile process, let's be more specific: if FreeBSD introduces a file compression process which is light-years ahead of anything else in existence -- clearly under the BSD license -- could the essence of this code not be copied into a GPL-licensed library or operating system making that code now GPL-licensed? Improvements in the GPL-licensed project could not be copied back to the BSD-licensed project, not could it be used in a corporate/closed-source product. This is what I want to avoid.
    – Mike C.
    Commented Nov 26, 2017 at 20:51
  • 2
    @MikeC This kind of thing has happened; you can easily find BSD-licensed source files in various GPL-ed projects. The files retain the BSD copyright notice header. You can take them out of the GPL-ed project and use according to the BSD license.
    – Kaz
    Commented Nov 26, 2017 at 23:17
  • 3
    @Kaz I understand, you for some reason misrepresent the GPL. one line of code under GPL is enough to create a "combination" and the original BSD license doesn't have to be retained. Anybody can easily take any project with a GPL compatible and more permissive license and create a new project out of it that will have all of it's code under GPL.
    – Oleg
    Commented Nov 27, 2017 at 2:39

The OpenSSL license is also a major headache in terms of GPL incompatibility, to the extent that there are LGPL replacements to remove the legal uncertainty.

The code is still used though, as there is a common interpretation that the incompatibility was not intended and the copyright holders are unlikely to enforce this license.

If you create a deliberate incompatibility and communicate that this is intended, expect nobody to even look at your code. The OpenSSL license situation has already eaten up several man-millenia of volunteer work.

It is absolutely certain that no Linux distribution would include it, as a legal requirement for inclusion is license compatibility with all other packages. You would get a friendly request to fix your license, and if you refuse as this would violate your intention, your package would become blacklisted.

Also, keep in mind that the C library on many distributions is LGPL licensed. Unless your license permits linking (= creating a derivative work) under these license terms, it also becomes illegal for you to provide binaries on your own web page.

In short, it's a bad idea that has absolutely no useful purpose.

  • 3
    Good answer, but maybe don't use the word "blacklisted". The original questioner has already posted in the comments that he's worried about being "raped" by "hippies" forcing him to share because of some communist mantra about "from each programmer according to his abilities." He probably is being "funny", but given the enormous misconceptions it would take to even joke like that, I could see him believing there's a literal "blacklist" rather than many people individually choosing to not use his software.
    – hackerb9
    Commented Nov 22, 2017 at 21:49
  • @hackerb9, in Debian, there is a mailing list where licenses are discussed, and of course if a license is found to be incompatible with the rest of the distribution, this knowledge is being archived. Individual people are always free to download his sources and compile the software themselves, but for this they'd need to find the software first (and the first thing they usually do is ask why there is no package, and it will be explained to them). Commented Nov 23, 2017 at 12:45
  • 1
    @SimonRichter Not quite. If a license prohibits distribution alongside GPL-licensed code, then sure, that's not going to get into Debian, but if a license is merely incompatible with GPL, but still Open Source and allowed to be distributed from the same servers, there's no problem for Debian. They do include GPL-incompatible software.
    – hvd
    Commented Nov 25, 2017 at 8:45

The answer to the question is No, there is no generally accepted open source license that is used by people who are specifically antithetical to copyleft. A person could make a custom license like that, but you should ask yourself why you are doing it.

The original question mentioned a valid concern that an open source project might be relicensed under a different copyright and then compete with the original. But, that's an argument for copyleft, not against it.

I was there in the 1990s when people realized that Microsoft had taken BSD code and relicensed it in their proprietary (closed source) products. In particular, Microsoft lifted the TCP/IP stack from BSD so they could compete with this "Internet" thing that UNIX had. Some BSD-license proponents claimed Microsoft's action was a "win" because their work would be used widely. I saw it as a loss and many developers (including me) switched to using the GNU General Public License (GPL). The GPL defends developers by preventing companies from taking without giving back.

If you want to make an open source project, but you're worried about someone stealing your project's momentum by making something that competes with you, then copyleft isn't the problem, it's the solution.


Not sure why nobody has mentioned it, but there is an excellent Mozilla Public License 2.0, that accomplishes exactly what you want.

If your code is licensed under MPL, then it can be freely used either by itself or as part of another project. The only restriction that MPL places is that your files (and your files only) have to still be available under the MPL terms. As this blog post puts it:

If your code is licensed under MPL 2.0 however, everybody retains the freedom to use your code as they please, but any enhancements to your open-source code have to be shared back. Sounds much fairer to me, and hopefully to you too.

A GPL project would also be able to use your code. However, they will be forced to dual-license your files under MPL and GPL. The GNU website explains this:

When you receive work under MPL 2.0, you may make a “Larger Work” that combines that work with work under those GNU licenses. When you do, section 3.3 gives you permission to distribute the MPL-covered work under the terms of the same GNU licenses, with one condition: you must make sure that the files that were originally under the MPL are still available under the MPL's terms as well.

  • The GPL project that uses MPL code will be forced to dual-license the MPL parts under both the MPL and GPL. However, the recipients of the GPL project can then choose to redistribute the code under the GPL only (since it is dual-licensed, the users have such a choice). This is not what the OP wants.
    – Flux
    Commented Aug 4, 2022 at 7:39
  • To achieve GPL incompatibility, one may choose to attach MPL 2.0's Exhibit B to the copyright notice.
    – Flux
    Commented Aug 4, 2022 at 14:10
  • The Eclipse Public License (EPL) could be an alternative to the MPL. It is similar to the MPL. Refer to What are some differences between MPLv2 and EPLv2?
    – Flux
    Commented Aug 4, 2022 at 14:17

To my considerable surprise, I recently discovered that somebody has created a so-called "BSD Protection License" which appears to be designed to specifically solve this problem.

The text of the license may be found here or here. It is quite lengthy, so I won't quote it in full, but I will summarize it as follows:

  • It allows verbatim redistribution of the software "as you receive it" in much the same way as the GPL, the MIT license, and most other open source licenses. This clause does not specifically mention the disposition of any source code, so presumably if you receive binaries without source, you can redistribute them as such. You're required to include a copy of the license and a copyright notice. This is all fairly typical.
  • It allows redistribution of modified software, under a license which "expressly prohibit[s] the distribution of further derivative works." This is highly unusual for an open source license, but by itself it does not make the license non-free, as long as the license provides an alternative option.
  • It also allows redistribution of modified software under the same license (i.e. copyleft). The modifications must be clearly indicated, which the GPL also requires, and copyleft extends to "any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof" - no exception for "mere aggregation."

Opinions vary on whether this is a free license. The Fedora wiki page, linked above, tersely describes it as "Free, but GPL-incompatible," but Debian thinks it's non-free, because the scope of its copyleft is even broader than that of the GPL. They also didn't like the wording of the "implied acceptance" section and suggested reusing the GPL's wording instead. Both of those problems are arguably fixable.

As for how effective it would be... that's unclear to me. If you keep the arguably non-free expansive copyleft, then it's certainly never going to be incorporated into a GPL project in any way, but this copyleft will extend to and prohibit all sorts of perfectly reasonable conduct, which could be problematic. For example, if somebody packages together your software with a bunch of other, unrelated software (e.g. in a Docker container or Linux distro), the license would arguably infect the entire package, which is probably not what you want and might create gratuitous license conflicts. If the copyleft were weakened, then it might strike a more appropriate balance here.

Overall, however, I'm not really impressed by this license. The sole beneficiaries of the "take proprietary" option are, presumably, developers who want to get into the business of selling the software. But since the "take proprietary" option is extended to the world at large, those developers would just end up competing with each other. If they would have used the GPL with a CLA, they could've gone proprietary without any competition (other than the inevitable non-relicensed fork, of course). If you want to take parts of the software proprietary and release other parts under copyleft, you can do that with a CLA too. And, of course, it's much harder to get people to contribute to your open source project when your license is screaming at the top of its lungs that you intend to take their contributions and go proprietary. So the license does not appear to provide substantive advantages over the CLA model, from the self-interested (greedy) perspective of the person choosing a license for their software.


I would like to publish code for an application under an open source license like BSD, MIT, or Apache 2 ... but where the code or derivative works can never be re-licensed under a GPL/Copyleft license.

Any additional restriction you place on the licensee usually renders the license a "non-free" license. This is an example of that happening. If you put such a restriction into a license, it would become a non-free (ie, proprietary) license.

How does that work? Because it would be impossible for anybody redistributing your code to do so under any open source license, whether permissive (BSD, MIT) or copyleft (GPL etc). They would only be able to re-license it under your proprietary license or a compatible proprietary license. The point of free software is binary: that there are no restrictions (except so called "reasonable" restrictions, like the requirement to preserve copyright notices), and that it can be re-licensed under widely-used open source licenses.

Thus, you may as well just license it under a completely proprietary license where they cannot redistribute at all. Claiming that your code is "free software" or "open source" would really just be dishonest.

That said, there is really no reason for you to do so. You can simply just license the code under a permissive license like BSD or MIT, and achieve all of your goals.

Licensees can:

  • Distribute binaries without the source code (proprietary product) ✔️
  • Distribute source code with or without their additions ✔️
  • Submit changes back to the project ✔️

And assuming that they are using the code in a proprietary product, licenses cannot:

  • Take code from the project and re-license it as GPL or any other form of license which COMPELS a user or company to distribute the source of their derivative works, making it untenable for use in corporate environments. ❌

That is, simply by including your code in a proprietary product means that they already are prevented from re-licensing it as GPL. Licensees could only re-license your code as GPL if they included it in a fully GPL licensed project, which would also mean that none of the rest of their code would be proprietary-friendly either. A company wishing to create a proprietary product is still welcome to use it under a permissive license by obtaining it directly from you.


Writing a new license can cause more problems rather than helping you, unless you invest in lawyers. It's better that you choose an already existing license. There's a list of GPL-incompatible licenses here.

However, a substantial number of such licenses were "fixed" in newer versions, so you must either explicitly specify the license version number that is GPL-incompatible, or choose one that never turned compatible nor seems to have the will for doing so.

Let me add that I understand (and agree with) your position, although I think your wording wasn't the best: you should have avoided talking about "momentum", as it can be interpreted as that you don't want to be less popular than a GPLed fork of your work. The problem here is not being popular, but that somebody modifies your code, by fixing bugs and adding more features, but they license their changes under the GPL, so the original author of the code cannot benefit from such contributions unless he "surrenders" to the GPL and releases the original code under the GPL.

However, I believe that a permissive license should allow a non-copylefted code to be included in a copylefted project. The only requirement I would add is: "if you do any modifications to my source code files, your modifications/additions/contributions must be done under the original license: only if you simply include my code into yours, you are allowed to use a copyleft license for your project while keeping my license intact" (note that I used quotes here not for saying I would add a clause like that in an existing license, but that what would be my will with my software)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.