> It doesn't matter what they say, read the license.
I would love to but the terms within the ElasticSearch codebase on Github are quite confusing. Here's the text of the LICENCE.TXT file.
Source code in this repository is covered by one of three licenses: (i) the
Apache License 2.0 (ii) an Apache License 2.0 compatible license (iii) the
Elastic License. The default license throughout the repository is Apache License
2.0 unless the header specifies another license. Elastic Licensed code is found
only in the x-pack directory.
The build produces two sets of binaries - one set that falls under the Elastic
License and another set that falls under Apache License 2.0. The binaries that
contain `-oss` in the artifact name are licensed under Apache License 2.0 and
these binaries do not package any code from the x-pack directory.
Aside from not showing copies of the applicable licenses, it seems you have to read the code headers to determine which source file has which license. There are a lot of ways to respond to competitive threats from Amazon, but this approach is increasingly chaotic the closer you look.
The license change to the dual-license with SSPL and Elastic License hasn't happened — this is the state so far and all the code outside the `x-pack` folder is Apache v2 licensed.
Does this even work? ES was considered 'one work' at some point, right? It's developed together, not file-by-file. How is it possible then to license it file-by-file? Wouldn't most of those files be derivative works of the old 'one work' anyway? (Meaning they have to keep the original license, meaning "the default license, Apache License 2.0"?)
Sure, at some point someone started to create a plugin for ES (let's say the security/ACL thing in x-pack, used to be called Shield or something like that), they used the ES API and they used runtime linking. (I have no idea if that's okay or not, has been tested in court or not. I know the US Supreme Court will say something about that in June.) But when developing any feature in that plugin nobody thinks of just that plugin. Folks think about ES as a whole, indexes, shards, documents, terms, maybe even in terms of low-level Lucene primitives.
I think it's practically impossible to wear the OSS and the proprietary hat at the same time. (Or separately but on the same project.)
If ES is the sole copyright holder, they can license it to whomever they wish under whatever license they wish. IANAL, but it seems perfectly coherent to me that they can say "If you build the software this way, we release it to you under X license. If you build it that way, we release it under Y license."
Open-source and free software licenses don't imply that the source must remain served on some site, and it doesn't imply that the license for the code cannot change for future versions of that code necessarily- as it depends on the license and/or other factors.
But if you have a copy of the license and the code and it permitted use of it perpetually, then it can continue to be used. That's my understanding.
I would love to but the terms within the ElasticSearch codebase on Github are quite confusing. Here's the text of the LICENCE.TXT file.
Aside from not showing copies of the applicable licenses, it seems you have to read the code headers to determine which source file has which license. There are a lot of ways to respond to competitive threats from Amazon, but this approach is increasingly chaotic the closer you look.[1] https://github.com/elastic/elasticsearch/blob/master/LICENSE...