http://slides.com/adamretter/are-we-still-open-source
Not easy as hard to know what the future will bring, but Apache feels like the right place if we are not GPL.
http://slides.com/adamretter/are-we-still-open-source
Not easy as hard to know what the future will bring, but Apache feels like the right place if we are not GPL.
One usual mechanism for this is to require a CLA on all contributions, with a copyright assignment so you become the owner of the contribution (and probably cope with a lower amount of people willing to contribute, as some consider CLAs as harmful to Open Source). But of course this had to be put in place from the beginning, which I don't know if it was.
Other solutions are to reimplement all parts of which you don't own the copyright, or to ask one by one for copyright assignment from all previous contributors. In this HN thread they talk precisely about this: https://news.ycombinator.com/item?id=24954772
In your case the relicense is to Apache 2 instead of proprietary, but I think the same set of issues apply. I think we'd learn a lot if you could tell us about your case, so there are more examples about the fine detail of relicensing Open Source projects.
The contributors to the server & core, which is more challenging from a getting started perspective (prolog server and Rust triple store), have had fewer active outside contributors. I was looking at these slides (17 - 22 here: https://www.slideshare.net/slidarko/mmadt-a-virtual-machinea...) earlier in the week and remarked on how few devs actually worked on most of the major DB and OSS projects. Tinkerpop is effectively written by 1.5 people! But that largely tallies with our experience. Small number of focused devs keeping a lot of the architecture in their heads while they write the code.
Those that did contribute, and we are eternally grateful to them, were happy to allow their code to be re-licensed. But I wrote to all individually and waited until they had time to think before taking any other steps. If we had been moving to a proprietary license, I think it would have been harder to get sign off, but that is pure speculation!
Well good news for you then: There’s nothing stopping you making all future changes proprietary now that it’s Apache licensed. You can effectively relicense the project however you want now, attribution notwithstanding.
We really don't like the 'traditional' open source economic model - with a community version and all the good features in a proprietary enterprise edition. The community version is almost necessarily weak and you end up annoying your users. We'd prefer to keep as open as possible and have a commercial SaaS or open core model.
Isn't this opposed to this?
> We really don't like the 'traditional' open source economic model - with a community version and all the good features in a proprietary enterprise edition
This is what I thought open core was, am I wrong?
A commercial SaaS model would make a lot of sense for a project that wants to remain completely free software, though. You are the people who know your code best, and it makes sense to trust and pay you to run it reliably.
We want people to build stuff on our database whether they are companies or individuals and we don't want to encumber this with stumbling blocks.
We intend to do this by having a SaaS revenue model which doesn't require we hobble anything in the database in order to make money.
I wish you success!
https://www.mongodb.com/licensing/server-side-public-license
Mongo license would be a permissioned license however
Pff, the have not more freedom with a GPL, unless they are developers. What freedom do you have when you use Linux but never read or change the source-code?
>potentially improved kernel
Or potentially worsened kernel, which now sits in you closed down IoT device, again the license is NOT important for the normal end-user.
You might not know anything about how the engine works in your car but it is still important that it is made correctly. The whole Free Software movement targets end users and works on the assumption that these questions are important for them.
Licenses might look like non significant technical details to most end users, but they are not, and many people not in the field are able to understand the subtleties. We should consider people's ignorance inevitable. This is not a fact we can't do anything about. Software is omnipresent in our societies and as massive effects on them. They have the right to know, should care, and actually often do if you don't push them. I know, I tried.
> all the proprietary blobs
Which ones? Nvidia seems to the exception here, and only concerns Nvidia's hardware anyway. If you think of Android drivers, they are in user space libraries (Had the Linux kernel been in a non-copyleft license, they would probably live in kernel space and working out the shitty situation of Android with the kernel would be far more difficult.
Thanks to the Linux kernel being under GPL, Android vendors and manufacturers are forced to release their kernel sources, which allows projects like Lineage OS and other Android derivatives to exist.
> or potentially worsened kernel
I can't imagine why kernel developers would accept a patch that knowingly worsens the kernel upstream.
The GPL forces shitty hardware makers to release their shitty code but nobody is forced to merge it upstream.
bad closed firmware are unfortunate but I don't know what it has to do with Linux being under the GPL.
I think the sibling comment covered most of this well, but I just wanted to add that relying on closed-source drivers is far from necessary with many setups of modern day Linux. All of the drivers on my computer, save for the processor microcode, are open source and for the most part, bug free. In fact, they are probably mostly bug free because they have so many eyes on them.
> Nearly no one cares that most Androids have stoneage Linux kernels, whats important for them is that the Android-Runtime (aka Play-store) can download and execute "Apps".
While many users might not know this is the reason, I think the copyleft license of Linux has let it become where it is currently, as it forces vendors who might otherwise release proprietary blobs addressing issues must instead release the changes with a license such that it can be improved upstream. This pushes companies who spend the energy to fix the bugs in an otherwise good kernel to give those changes back to the community, similar to how the companies took from the community in order to use the kernel.
> > potentially improved kernel
> Or potentially worsened kernel, which now sits in you closed down IoT device, again the license is NOT important for the normal end-user.
Well I think this is a great argument in favor of GPLv3 over GPLv2, which bans this (see [1]). This is another reason why end users could care about the license used in the code. GPLv3 code guarantees the end user the freedom to modify the code and run it on their device (or apply other people's modifications). Though I will concede that this is less of an end-user-centric idea because it requires a decent level of technical competency.