search

yabits / uefi

Fast and lightweight yet another UEFI implementation
https://yabits.github.io/
GNU General Public License v3.0
99 stars 7 forks source link

Any chance of a BSD or MIT license? #2

Closed kallisti5 closed 6 years ago

kallisti5 commented 6 years ago

GPL is pretty limiting at something this low level. Any chance of a BSD or MIT license before the project grows larger?

retrage commented 6 years ago

Currently, most of the code is from Minoca OS which is GPL v3 license. If we switch to other license, we have to rewrite almost all code. I hope escaping GPL is good idea, but it is not realistic.

furkanmustafa commented 6 years ago

I'm really glad it's GPL.

Not being GPL is one of the main reasons of Tianocore problems, isn't it?

kallisti5 commented 6 years ago

Not being GPL is one of the main reasons of Tianocore problems, isn't it?

Not really, Tianocore is actually released under the BSD license (from what i've seen). What problems does Tianocore have? (besides being bloated)

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II

Releasing something under the GPL doesn't automatically mean you'll get people willing to dedicate time to something

The benefits of using MIT or BSD are a more likely uptick in development and contributions from corporate users (and corporate money). However, as you're likely calling out, this friendly two-way path of usage + contributions aren't guaranteed.

I can speak from personal experience that I've run into open source projects before I've wanted to leverage for employers (and return contributions to) but have been struck down at the legal department level.

There have been in the past (and continue to be) companies which don't follow the spirit of the GPL, but generally you don't want code contributions from those companies. (unskilled / unknowledgeable workforce, etc... those who would violate the GPL without thought)

If we switch to other license, we have to rewrite almost all code.

Not really 100% true. Licenses in open source projects are kind of a genie in a bottle. Once you pick something and gain contributors, it gets harder and harder to change. (Generally relicensing or dual-licensing requires project maintainers to contact every person who has contributed over the years for permission to do so.)

Anyway, i'm a developer of Haiku, and we choose to release our core operating system as open source MIT. While MIT is compatible with GPL code, GPL code isn't compatible with MIT. (Very few licenses are compatible with GPL)

You're also locking yourselves out of yabits/uefi from being used in OpenBSD, FreeBSD, NetBSD, etc.

Thanks!

furkanmustafa commented 6 years ago

You're also locking yourselves out of yabits/uefi from being used in OpenBSD, FreeBSD, NetBSD, etc.

Why would that be?

kallisti5 commented 6 years ago

Pretty much you can't put GPL code into non-GPL repositories because it limits the license of the whole repository. (which is why GPL is called a viral license)

https://www.freebsd.org/internal/software-license.html

The import of new software licensed under any licenses other than the BSD license
and BSD-Like Licenses (as defined below) requires the prior approval of the
FreeBSD Core Team.

https://www.openbsd.org/policy.html

While this may superficially look like a noble strategy, it is a condition that is
typically unacceptable for commercial use of software. So in practice, it usually ends
up hindering free sharing and reuse of code and ideas rather than encouraging it. As a
consequence, no additional software bound by the GPL terms will be considered for
inclusion into the OpenBSD base system.

For historical reasons, the OpenBSD base system still includes the following
GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils
and libraries, GNU CVS, GNU texinfo, the mkhybrid file system creation tool, and the
readline library. Replacement by equivalent, more freely licensed tools is a long-term
desideratum.

A few projects have created a workaround by using LGPL, or releasing headers that external projects would need to include as MIT/BSD/AS-IS

furkanmustafa commented 6 years ago

Pretty much you can't put GPL code into non-GPL repositories because it limits the license of the whole repository. (which is why GPL is called a viral license)

This is not true. It's not tied to the repository. It is tied to a work/product. A GPL project can sit in a folder in my repository (I can distribute it using git) as long as I comply. If my product/work is not a derivative of it, it does not need to be GPL. They can sit together in a repository just fine.

Although the links and texts you have shared shows that there is a decision by OpenBSD to not include GPL works as much as possible. It's their policy, I understand that.

As example; Most Linux distributions include GPL, BSD, Apache, MIT licensed software all together with no legal issue at all.

kallisti5 commented 6 years ago

Meh, i'm done here. I put forward some good reasons to license as MIT/BSD instead of GPL which benefit the overall open-source OS ecosystem in a less Linux-centric way. If there is no interest from the developers, there is no interest.

This doesn't need to be a GPL holywar. Haiku will continue to use Tianocore, and i'm sure the BSD's will as well due to the licensing.