ASL 2.0 + MIT about lux HOT 12 CLOSED

Lux is now MIT licensed.

from lux.

Lux currently doesn't involve any patents, so that shouldn't be an issue.

Should I ever patent anything related to Lux's compiler or standard library, I would grant free usage to those patents for both commercial and non-commercial purposes (which is equivalent to not patenting at all).

I'm not interested in sneaking time-bombs inside other people's code, or forcing people to buy a license.

I was worried about the patents from the perspective of receiving contributions.

Like: what if I a contributor sends me a pull-request that introduces code subject to a patent, but I don't know it because I'm not cognizant of the patent in question. What happens then?

Like, someone sneaks a time-bomb in Lux's code-base, and then an associate of theirs comes later and sues me for patent infringement.

I don't know how realistic that scenario would be, but I don't want to take any chances.

But I guess that's something that could be dealt with by having a contributor's agreement that says they'll be solely responsible for any patents they infringe in their pull-requests, or that if they provide code under their own patents, they give everyone who uses that code as part of Lux a free license, and they forfeit the right to sue me or any user.

So, I guess I might not need to push my patent worries onto users of Lux, and instead I can push them on the shoulders of contributors, where those worries do belong.

from lux.

As far as I'm aware, the MPL 2.0 license only forces copyleft on any code that changes the original licensed files.

That means you could link to an MPL 2.0 project and that wouldn't force you to make your own source-code open-source.

The only thing MPL 2.0 does is make sure that nobody can come later, take your open-source code and repackage it as closed-source for themselves, and make new versions of it that you (as the original author) can't get access to.

Basically, MPL 2.0 doesn't steal anybody else's code (by making it open-source), but doesn't allow others to steal your code either (by closing it).

That protection is certainly something that appeals to me (I can't imagine why someone would want to make a closed-source fork of Lux, but who knows).

However, I want to note that I'm not a licenses buff, so I may be wrong.

If there are some nasty properties to the MPL that I'm not aware of, feel free to point them out.

If someone has a use-case for which the MPL 2.0 interferes, I'm willing to talk and perhaps reach a compromise, so I'm not dead set on using any particular license. I just want my rights over my code to be respected.

Finally, here's a Stack Overflow comment explaining some of the differences between MPL 2.0 and ASL 2.0, to put things into perspective: http://softwareengineering.stackexchange.com/a/152612

from lux.

Ok, I'm open to making a change, if it's something that can really interfere with adoption.

My issues are these:

• I originally made the switch to MPL because some folks were worried about compatibility with GPL. MPL sounded reasonable, so I went with it.
• I find it a bit worrisome that I should go from using 1 license, to using 2 licenses. Also, which license you choose for Lux is at your discretion. Does that effectively nullify Apache's patent protection? Can somebody sue me because they chose to license at MIT instead of Apache?
• With that said, I might have some of the issues that the Racket folk mention about licensing being kinda fuzzy (they mention in-lining and macro-expansion as possible sources of trouble). Even though I don't plan to use that against anybody to force them to open-source their code, it would be better if I didn't even have the option to ever do such a thing.

Ah... open-source licensing is such a headache.

All I want is to make sure my work is protected and nobody can mess with me, while letting people do their thing in peace.

ASL 2.0 seems like a more permissive MPL, except that it isn't (at least from the GPL side), which is why Rust and Racket combine it with MIT.

. . .

@sirinath Could you elaborate a bit on why someone would have a problem with the MPL?

Is it just bias against copyleft, or are there specific issues with the MPL?

from lux.

I'm thinking of migrating to MIT, since it seems the most compatible with both proprietary and FOSS needs.

I'll be making the shift over the week.

from lux.

It is upto you to choose the license but there some businesses which does not whitelist copyleft licenses. Therefore, if this takes off quite a companies might not be able to use it regardless of they want to fork it or not.

from lux.

That's a valid point.

I'll give it some thought.

from lux.

You will have to choose soon as you might not be able to change the license once you get many contributors as you will have to get their agreement.

from lux.

On a related note, Racket has been gathering contributor permission to move the license from LGPL to MIT+Apache 2.0. I personally think the MPL is fine, just adding some food for thought.

from lux.

I think it is a smart move as some organisations cannot use copyleft. See: racket/racket#1570

from lux.

Some companies use license whitelisting. Whitelisted licenses are the common permissive licenses. If you want use something else you have negotiate that with the company or their legal department. For you you have to hire layers and for small time companies and contacter this expense is material.

You can just stick to ASL 2.0 with a few exceptions like for Swift: https://swift.org/LICENSE.txt

No need of MIT.

from lux.

There was a mention on patents, which MIT does not really address. Some food for thought, irrespective of license text, which ofc can be specialized for Lux and/or Lux libraries, and can include custom paragraphs.
http://law.stackexchange.com/a/9702, last paragraph

from lux.