3 ms·

The entire crux of the post's commentary is an intentional misinterpretation of the original post. The motivating quote with the actual context is: > At AWS,

The entire crux of the post's commentary is an intentional misinterpretation of the original post. The motivating quote with the actual context is: > At AWS, we believe that maintainers of an open source project have a responsibility to ensure that the primary open source distribution remains open and free of proprietary code so that the community can build on the project freely Amazon's core complaint is: > Unfortunately, since June 2018, we have witnessed significant intermingling of proprietary code into the code base. The Elastic license itself professes to include code that isn't covered under the original Apache 2.0 license: https://github.com/elastic/elasticsearch/blob/master/LICENSE.txt https://github.com/elastic/elasticsearch/blob/master/LICENSE... > Within the "x-pack" folder, source code in a given file is licensed under the > Elastic License, unless otherwise noted at the beginning of the file or a > LICENSE file present in the directory subtree declares a separate license. If Elastic wants to adopt an open core model, that's perfectly fine, but mixing the open source and proprietary bits in the same repo is messy and should raise eyebrows. What Amazon seems to be asserting is that a project that is open source shouldn't change the license terms. That is not an assertion, as this blog post claims, that the original developers must maintain the project indefinitely.

__fu 8y ago
https://www.elastic.co/products/x-pack/open https://www.elastic.co/products/x-pack/open explains why and what was done pretty clearly imo.
deleted 8y ago
[deleted]
csdreamer7 8y ago
> If Elastic wants to adopt an open core model, that's perfectly fine, but mixing the open source and proprietary bits in the same repo is messy and should raise eyebrows. GitLab recently proposed a similar action. See the below link for the trouble they had maintaining two codes bases for one application. I have dealt with git submodules-it is not fun. https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codebases/ https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codeba... This is what GitLab proposed. I thought they handled it very transparently. Other companies should take note. The gitlab-ce and gitlab-ee repositories are replaced with a single gitlab repository, with all open issues and merge requests moved into the single repository. All frontend assets (JavaScript, CSS, images, views) will be open sourced under the MIT license. All proprietary backend code is located in the /ee repository. All documentation is merged together and clearly states which features belong to which feature set. Documentation is already licensed under CC-BY-SA.

__fu 8y ago

https://www.elastic.co/products/x-pack/open https://www.elastic.co/products/x-pack/open explains why and what was done pretty clearly imo.

deleted 8y ago

[deleted]

csdreamer7 8y ago

> If Elastic wants to adopt an open core model, that's perfectly fine, but mixing the open source and proprietary bits in the same repo is messy and should raise eyebrows. GitLab recently proposed a similar action. See the below link for the trouble they had maintaining two codes bases for one application. I have dealt with git submodules-it is not fun. https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codebases/ https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codeba... This is what GitLab proposed. I thought they handled it very transparently. Other companies should take note. The gitlab-ce and gitlab-ee repositories are replaced with a single gitlab repository, with all open issues and merge requests moved into the single repository. All frontend assets (JavaScript, CSS, images, views) will be open sourced under the MIT license. All proprietary backend code is located in the /ee repository. All documentation is merged together and clearly states which features belong to which feature set. Documentation is already licensed under CC-BY-SA.