MIT licence really suitable?

Distro
1

Hi,
there are different types of licences for different puposes. If someone cares about its work und want as many as possible users to benefit for, the author chooses a copyleft licence. If the author wrote a tool for himself and he wants to make it public for other users and he doesn’t care what happens with its software and who uses it, he chooses a non-copyleft licence. Well, that’s at least my opinion and I read the opinion about the Redox authors about MIT and GPL, but if you look at real life, you’ll see for example, that Sony und Apple are using FreeBSD, but they are almost nothing giving back.
You will discourage many opensource developers with the MIT licence, because they know, that there are many companies which will take the software for granted, but nothing giving back. MIT requieres more moral from companies than GPL.
Now, where redox is still young, there is still the possibilty where you can change the licence. You can see with Linux in practice, that GPL works really fine and it has forced many companies to public their source code against their will.

If you really insist of non-copylef licence, consider at least Apache 2, see:
http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_License_2.0

There is no good reason to choose MIT licence over Apache 2.

PS: You can ask youself if Linux and Android would have been that successfull without a copyleft licence.

2

The choice of MIT is not an arbitrary one:

The GPL is good for forcing people who make changes to the source to contribute back. This would be okay if you were developing a program, but never ideal for libraries or operating systems, because the GPL forces any code that even remotely uses or links to the GPL’d source, to become GPL’d.

Since operating systems are such an integrated part of our lives, we want as little restriction as possible. Restrictive licenses are quite a big disadvantage for OS projects. The MIT license opens up a lot of possibilities, which are simply not plausible with, say, the GPL.

The GPL is upstream-centric, the MIT license is downstream-centric. We happen to prioritize downstream more than upstream, since downstream is what really matters: the userbase, the community, the availability.

We wanted to encourage the use, modification, and packaging of Redox in absolutely all realms. Open source should be open, for everyone. There’s absolutely no reason for limiting the usage of the software. Therefore, MIT was the license of choice.

But what if someone “steals” the source code?

We wouldn’t mind if somebody did that. In order to successfully steal a project, you’d have to make some improvements over the upstream version. You can’t sell an apple for $2, if another person stands right next to you, giving them away for free. For this reason, making a (potentially proprietary) fork interesting requires putting some time and money into it.

There is nothing wrong with building on top of Redox. You can’t unfairly steal a project. That’s simply not possible. For a fork to gain interest, you will have to put effort into it no matter what.

Building on top of Redox, whether it gets to upstream or not, is a thing we appreciate.

We like to have a decentralized structure of the project, allowing people to do whatever they want, no matter how they intend to share it.

13 Likes
3

I completely agree with @Ticki.

AFAIK Android uses Apache 2: https://source.android.com/source/licenses.html

I’m not an expert, but it looks like Linux manages it quite well. Did they add some special clauses to make the license less restrictive ?

4

No they do not, but Linux has some severe problems with the license (for example, ZFS support is very limited due to licensing issues).

5

The GPL is good for forcing people who make changes to the source to contribute back. This would be okay if you were developing a program, but never ideal for libraries or operating systems, because the GPL forces any code that even remotely uses or links to the GPL’d source, to become GPL’d.

What is exactly wrong with LGPL and what makes MIT better than Apache 2?

AFAIK Android uses Apache 2

But not their contributions to the Linux Kernel. There was a time where Greg Kroah-Hartman complained that Google is not contributing to the Linux Kernel, but this changed with Android. Without GPL they wouldn’t have been forced to do that and their changes to Linux wouldn’t be propably open.

6

You have been drinking the Kool-Aid @Stefano. The companies that use the open-source projects with less restrictive licenses make direct contributions back to the projects by their own goodwill and without being forced to by a license, which gives them bonus points in terms of social responsibility. On top of that, some of the companies that utilize these types of projects go on to open-source their own amazing projects. Also, it’s interesting that you brought up and didn’t argue for the Apache License, then asserted that there was no good reason to choose the MIT License over it, while your main point was about why Redox should switch to the GPL.

As you can with Netflix, NetApp, Apple, Whatsapp, Sony, etc.

7

One thing that’s missing or barely covered in these discussions is patent trolling. This is a huge problem now where the most trivial things are getting patented with lawsuits following. Interestingly, the companies doing the suits are big users of BSD or MIT licensed code. The Apache and later GPL licenses included provisions for a patent grant on the code itself so they couldn’t improve it then sue people for using it. They currently can in your code since copyright and patent licenses are handled separately in courts with patent courts strongly favoring trolls so far. I’ve since encouraged all FOSS code to include a patent grant that covers the FOSS codebase itself. Anything broader would scare away adoption by patent-loving companies who contribute to BSD and Apache codebases.

The main gripe I’ve seen is Apache 2 license comes with other stuff people don’t like. I propose someone with some legal background simply take the MIT license, add a patent grant to it, and call that MIT 2.0. A simple, permissible license that says those participating in a codebase won’t patent sue others over that codebase. It’s hard to quantify the risk but I think a default of no, patent suits on BSD/MIT-style code would be consistent with authors’ goals of wide adoption.

Thoughts?

1 Like
8

It’s incorrect that the GPL is “never ideal for libraries or operating systems”. There are clearly libraries that need code contributed back. And operating systems are extremely sensitive to whether code gets contributed back by hardware makers.

In particular Linux’ success if partially attributed to its GPL v2 license. Linus Torvald’s stuck with the GPL v2 over the GPL v3 precisely because he felt the GPL v2 hit the sweet spot for convincing hardware makers to contribute.

There are increasingly companies that contribute code without this legal push, so maybe the GPL v2 route does not buy as much today. Right now, any definitive statement about this sounds like kool-aid though. All we really know is that Linux’ combination of being GPL v2 but extremely pragmatic works out well for them in the past.

I think Redox should stay permissive for now for flexibility. Right now, you need code to be able to migrate between redox and the wider Rust ecosystem. Also, there are anti-GPL kool-aid drinking companies who might consider financing Redox development.

In the long term, if Redox develops over the next few years without receiving much financing by GPL haters, and eventually runs into the old BSD proprietary driver problem, then Redox developers should be open to migrating to the GPL v2 like Linux. But that’s a problem for the distant future, if ever.

1 Like
9

If I’m correct - the Redox design is to be highly modular so the system can have a combination of any application or drivers with any type of licenses in that it would be easily integrated. The main issue would be having developers for these applications and drivers.

So keyword here is being highly modular thus by design, growth is represented by the amount of developers for the Redox OS Ecosystem

EDIT: topic about patents is probably my only concerned

10

Some (longer) time ago I looked into this kind of license choice “problems”. Sadly I don’t remember all details about how I came to given conclusion. Their I will jus post the conclusion(s) for libraries and similar projects (I think redux falls in this category) I had:

  1. If you have a small project MIT is fine, through there are some shitty laws so if it becomes bigger/commercial used you might get problems with parent trolls, so you should consider using e.g. Apache v2 or other licenses which are like MIT+protection

  2. If you want to go commercial but still have a big open source reach dual-licensing commercial+GPL/LGPL is the way to go (prefer LGPL if it is likely that big commercial projects still have to buy the Commercial license or if you have some extensions which are especially interesting for commercial usage and which licence with com+GPL while your main project is com+LGPL). Take a look at Qt as an example, also add a clause to LGPL that static linking even with link-time optimization is treated like dynamic linking.

  3. If your software provides a Plattform with a small well defined interface (e.g. kernel+syscalls) it can be a good idea to licence the kernel with GPL and make it clear that linking to then interface has nothing to do with the kennels license (in some countries a interface is not licensable anyway which I think includes the EU and maybe America?). Also if you provide a library to easier interact with the interface do use MIT or similar for it. Note that this is especially interesting for kernels which have user space drivers as only the kernel but no driver is affected by the copyleft license of the kernel.

If you use a copy left license make sure that it does allow the distribution of it “bundled” with non copyleft code e.g. shipping a disc image containing a kernel licensed like in case 3 but also some proprietary software/driver etc.

I forgot my conclusion of GPL v2 vs. v3 ;(

If there is a plan of going commercial with redox I would consider going with a combination of 3. and 2. (i.e. dual license the kernel com+LGPL/GPL and at the same time throughly isolate the effect of copyleft to the kerne, don’t forget to also make sure it can be shipped bundled with “other” software I think in case of GPLv2 a extra clause is needed for it but I’m not sure)

If there is no plan of commercialising redox then I still would consider switching from MIT to a dual license MIT/Apache v2. If I remember correctly Mozilla originally planned to use only MIT for rust but found that this is a bad idea I would have have to search for the exact reasons but they what along the line of protection from shitty usable patent laws. That Mozilla wants prove rust(compiler/libs/etc.) as freely as possible but still used a dual licence with Apache v2 should be a good hint for considering to go this way too.

If I find the time to again look up the nitty bity details of why I came up with above guide lines for my own projects I will follow up, but we’ll this is very unlit to happen. Just to many think I want to do :sweat_smile:.

Edit:
If you use any kind of copy left licence it is recommendable to provide a more human readable overview about what is allowed and what not. E.g. clearly state that shipping a bundle also containing proprietary software is due because… There are a lot of miss conditions about how GPL is supposedly infectious on slightest contact and other wrong assumptions.

Edit 2:
Isn’t it sad, that we have to protect innovative product from exactly the laws which where made to protect innovation :disappointed_relieved:

12

I agree 100%. I have heard of companies making MIT licensed software, then anotther company forks it, patents it, then sues anyone who uses it. I believe this has happened to Google multiple times.

13

It’s because these laws aren’t designed to protect innovation.
They were established to further the individual interests of lobbyists, just like any other law throughout history.

14

What would you suggest?

15

I would like there not to be a license, on principle.
Since I appreciate that for a project of this type this might harm adoption and my priority is the health and success of the project, I suggest WTFPL v2

16

Why not MPL 2.0 https://choosealicense.com/licenses/mpl-2.0/?

Its forces to contribute back changes in files while allowing linking both static and dynamic.

17

I would not sacrifice values for popularity so that company can take it and give nothing back. Do we make software to be popular ourselves or for it to be a good tool and make a better world? Linux made it even with copyleft and in my opinion that is the way to go. Maybe there could be a compromise that you wait for some big commercial project to adopt it and then change the license so they would have to open it to save money for continuing already costly development.

18

What bothers me if there is any permissive license compatible with GPL world ( https://www.mail-archive.com/search?l=debian-user@lists.debian.org&q=subject:"Re\%3A+Is+there+permissve+GPL3+compatible+license+\%3F"&o=newest )
I know that may be considered FUD, but GPL have very specific requirement to publish combined work with GPL (2 or 3 or later). Discussion on Wikiepdia https://en.wikipedia.org/wiki/Talk:License_compatibility suggest even that LGPL with GPL compatiblity means that you need to physically change license to GPL in code

I do not see any way to have MIT/BSD/Apache2 permission to change license to GPL2+ .

In my opinion license which would have to be GPL license would have to have direct clause that you can treat (cast) this license as GPL if you wish

19

I am not really a follower of the different open source license now available, but I wonder if the GPL addresses a problem that is already passed.

In the past there may have been problems with businesses ‘borrowing’ open source code, repackaging it somehow as their own, and selling it commercially.

Nowadays, nobody really ‘buys’ software in the sense of going to their computer shop and handing over a tidy sum for a box with some floppies in it. Bill gates might have made his billions that way, but not recent silicon valley billionaires like Mr Zuckerburg and Google’s promotors. The software is no longer the product. Rather it is the user - and their data - who is the product.

Redox has the potential to one day be more secure and powerful than Unix. Such a system would be a desirable commodity for the data oligarchs of this world. Perhaps the licence should not concern itself merely with who ‘owns’ the source code but also place limitations over who benefits from the data processed through it? This might take the form of a Redox Foundation empowered to charge license to commercial users whilst allowing home users to use freely (under whatever licence terms that would be).

1 Like