7 ms·

"And to be clear, this change most likely has zero effect on you, our users. It has no effect on our customers that engage with us either in cloud or on premise

"And to be clear, this change most likely has zero effect on you, our users. It has no effect on our customers that engage with us either in cloud or on premises." No, that's just not true. So many users, from small hobby side-projects, to large open source projects, and mega-corps care about the licensing of dependencies, each for their own reason, and will not want to build on top of proprietary software that imposes draconian licensing terms. It doesn't matter what they say, read the license. It's vague and there is no legal precedent. It's a big risk for anyone who cares about licensing issues for their projects.

signal11 6y ago
If you're a paying customer, you are probably fine. If you're using SSPL'd Elastic (or Mongo DB, the risks are the same) for anything serious -- i.e. beyond a hobby, get legal advice ASAP. SSPL isn't an OSI certified license; many would call it at best a 'shared source' license because of the riders attached. [DELETED because, as user `gpm` points out, OSI doesn't own 'open source' as a trademark, sorry about that -- the need for legal advice doesn't go away, however.] In fact given their kvetching about Amazon and their trademark, Elastic's cheerleading of open source in this and the original blog post seems to be a bit misleading and doing OSI's trademark a disservice.[/DELETED]
- gpm 6y ago
  OSI does not have a trademark on the term open source, they tried and failed to acquire one.
  - ddevault 6y ago
    Trademarks are not a requirement for defining terminology. The word "cake" is not trademarked, but if I sell you a used car tire when you buy a "cake" from me, I still lied and misled you about the product.
  - prepend 6y ago
    I think they need one. Comically, this is why trademarks exist to prevent people from confusing the market with similar and reused terms. I think we need a CreativeCommons-like trademark for open source software before it’s too late.
    - signal11 6y ago
      I think "OSI Approved Open Source License" could easily be an OSI trademark, if it's not already. Ironicallly, like many other organizations, Elastic themselves have used OSI's approval as a benchmark for 'open source'[1]: > Is X-Pack now open source? > Updated on 2018-04-24 with a link to the Elastic License > Open source licensing maintains a strict definition from the Open Source Initiative (OSI). > As of 6.3, the X-Pack code is open under the Elastic License. However, it will not be 'open source' as it will not be covered by an OSI approved license. The interaction model for open X-Pack will be identical to the open source Elastic Stack, including the ability to inspect code, create issues and open pull requests via our existing GitHub repositories. [1] https://www.elastic.co/what-is/open-x-pack https://www.elastic.co/what-is/open-x-pack
      - gpm 6y ago
        > I think "OSI Approved Open Source License" could easily be an OSI trademark, if it's not already. Something along those lines is trademarked
      - un_ess 6y ago
        https://opensource.org/trademark-guidelines https://opensource.org/trademark-guidelines lists OSI's policy for trademark usage. 3. Usage that Require Prior Written Approval 3.1. Distributing software under a license approved by OSI ("OSI Approved License")
    - colechristensen 6y ago
      I think there are valid differences in opinion in what “open source” means and an organization with an agenda shouldn’t try to own the terminology.
- pas 6y ago
  It's especially ... ironic, that they think Amazonification is not-ok, but Enterprizificaion (open core) is a-ok. That said hosting ES is basically the same as building a carwash, or a gas station, or let's say a printing house. You get the machinery and build your own support services around it. Even the unit economics are not that different. AWS spent probably millions of dollars to push the marginal price down. The initial cost of procurement for machinery might be zero for ES as opposed to buying a printing press, but none of the aforementioned sectors are limited by the cost of machinery. In case of brick and mortar services the cost of land, labor, construction, and logistics are all a lot more important. Yes, okay, but what about AWS's advantage, their "moat"? Elastic will never be able to match that. This is the same problem that plagues the browser, phone OS (and other) markets. Google can easily spend a billion USD each year on fiddling with Chrome and Android. Mozilla, Canonical, KDE, and others can't. AWS has the platform advantage, Google has money. It seems these market forces virtually force ES to become a "public good" like the Linux kernel. (Or Elastic could try to fork it and stop using any kind of free/open/available license. And try to find business niches.) But at this point the cat is out of the bag. Likely no amount of license engineering will be sufficient to overcome AWS' advantage.
  - jacobr1 6y ago
    The cloud providers would just build a competing service if they couldn't co-opt an existing popular open source solution. Or anoint an adjacent solution, like solr in the case of elasticsearch. But what can be done and we really haven't seen a "open-core" type infra component try this yet: is require open-sourcing changes. The opendistro approach sorta gets us there, in a hard-fork sense, but seems in adequate and is really only being done for connivence rather than licensing requirements. But we already have a licensing solution: the AGPL. But no enterprise or saas startup wants to touch AGPL software for the fear of it contaminating proprietary code. So it seems to me the solution is a hybrid APGL for cloud providers and apache/mit for others approach. Such a license seems feasible to write and would be superior to open-core for most users.
    - pas 6y ago
      ... a bit theoretical, but how is the GPLv3 with the anti-Tivo provision okay? OSI definition 10: License must not restrict interface, and def. 9. License must not restrict other software it gets distributed with. (So I can't put my encrypted bootloader and verifier into the same thing.)
- delfinom 6y ago
  "OSI certified" doesn't mean shit regardless in a legal manner. It's just toilet paper. Always have your own legal review by IP lawyers.
jameshilliard 6y ago
Yep, it's also incompatible with virtually all copyleft open source licenses. So if you were using any AGPLv3 code with elastic you now have to switch to Amazon's fork.
- alisonkisk 6y ago
  Is incompatible with non-Affero GPL?
  - jameshilliard 6y ago
    Yes, it's incompatible, although you might be fine if you aren't distributing it or running it as a service. SSPL requires re-licensing of all code to the SSPL, GPL has provisions that disallow re-licensing. > the simple requirement that if you provide the product as a service, you must also publicly release any modifications as well as the source code of your management layers under SSPL This provision is effectively impossible for anyone to comply with in practice. Calling this a "simple requirement" is a barefaced lie.
    - pas 6y ago
      Especially that no independent party with any authority (ie. a court) determined what's covered under "management layers". If I use a custom kernel (that's optimized to run the JVM and has filesystem and block storage optimizations for ES), do I have to provide the source for that? (It seems trivial that it's not "management", but naturally Elastic's interest lies in arguing that yes, that are covered under management layers too.)
- Proven 6y ago
  "with" Elastic how? I doubt that is true, in fact it seems like a completely random FUD statement. At least GP tried to make heir FUD ambiguous.
alex_young 6y ago
This lack of clarity in law will likely result in huge issues in the sale of your startup if you ever go that route. Who wants to buy a potential lawsuit because of a database selection?
- alisonkisk 6y ago
  There are always "potential" lawsuits, and stripes already use many many licensed dependencies with various proprietary licenses.
  - alex_young 6y ago
    This is true, and there are entire categories of licenses which are considered untouchable in an acquisition because of the risk associated with them.
prepend 6y ago
I find these kind of obscure, “don’t worry” posts to increase my worrying. Part of the simplicity of open source is that it’s available for easy audit. Having to hire lawyers to use a product means I probably won’t use it. I also think having people saying “we’re open, but read the fine print” is not good for open source collaboration as it increases confusion and complexity. Elastic is moving the way of a commercial software company. That’s perfectly fine as it’s their company, but it’s just different than open source.
- colechristensen 6y ago
  Yup. If you, understanding your product, your users, and your licensing, write a post for your users not to worry, it means that you thought about your changes and came to a well informed position that there was reason for worry.
  - greyhair 6y ago
    The Hitchhiker's Guide to the Galaxy starts out with "Don't Worry". By the end of the sixth book in the trilogy find it was right to worry all along.
  - dvfjsdhgfv 6y ago
    Or you might have a history of people being mad at you (for good reasons, like the story of security of the ELK stack). They know very well everybody will get mad again, so they precede all explanations by "don't worry".
  - dragonwriter 6y ago
    Well, you try to make it sound unlikely, but it's exactly like corporate messaging that there are no plans for layoffs in the wake of bad financial news. The idea that a license change made to prevent competition and enable a business model centered around extracting monopoly rents from customers has no effect on customers is ludicrous. It's whole point is to have an adverse effect on customers.
luisfmh 6y ago
So what should we be using instead of elasticsearch for logs? To mitigate that licensing risk?
- mjburgess 6y ago
  https://www.amazon.com/s?k=Seagate+BarraCuda&ref=nb_sb_noss_2 https://www.amazon.com/s?k=Seagate+BarraCuda&ref=nb_sb_noss_... & grep ( with parallel ) ...if it matches your use case, you'll find it trivially outperforms elasticsearch.
  - dvfjsdhgfv 6y ago
    Search speed is not the most important aspect at play here.
- hodgesrm 6y ago
  ClickHouse. It's Apache 2.0 and will stay that way. Edit to add disclaimer: I work on ClickHouse.
- pritambaral 6y ago
  Using an AGPL-licensed fork does not suffer from this risk.
- corford 6y ago
  We're using Grafana and Loki to great effect.
- technics256 6y ago
  Loki and grafana are great, use it on all my clients eks clusters.
api 6y ago
The open source world needs to come together and create a license that is well crafted. Otherwise we will keep seeing these less suitable licenses. So far the FOSS world seems to be pretending this problem doesn’t exist. Pretending a problem doesn’t exist doesn’t make the problem go away. It makes you go away as you become irrelevant. There is the AGPL, but it's not quite right. It also has the letters G-P-L in it, which spooks a ton of people still influenced by Microsoft's billion dollars worth of anti-GPL FUD. (I'm convinced you could just rename the GPL and all those problems would go away.)
- dragonwriter 6y ago
  > The open source world needs to come together and create a license that is well crafted. It has created several. It hasn't created licenses well-crafted for purposes directly contrary to the purpose of having open source software, because that's not what the open source community is interested in. > So far the FOSS world seems to be pretending this problem doesn’t exist. From the point of view of the FOSS world, the issue here is not a problem; creators having an exclusive ability to monetize software as a service isn't a purpose open source is intended to serve; in fact, avoiding the lock-in that results from such exclusivity is a big part of the point.
  - api 6y ago
    > From the point of view of the FOSS world, the issue here is not a problem; creators having an exclusive ability to monetize software as a service isn't a purpose open source is intended to serve; in fact, avoiding the lock-in that results from such exclusivity is a big part of the point. If the creators get nothing, then why bother? Why slave away to make software just to give free labor to billion dollar companies while you get nothing? Is free labor for Amazon what open source is about? If open source refuses to adapt to the realities of today's software ecosystem, it will die out... or at least "serious" open source projects will die out and all that will remain is hobbyist level stuff, abandonware, and half-done academic projects. Personally I do think FOSS in its present form is going to die for most major projects. You'll still see FOSS libraries, building blocks, academic projects, and some major projects that really are large and old enough to have enough real grassroots contributors to keep them going. For major projects in the future you're going to have something more like a shareware model but with source-available. Nobody creating a new large-scale project today is going to give it a license that they know will result in somebody else productizing it, making a fortune, and giving them nothing. At least Amazon acknowledges where things came from... in some cases the productizers even rename the project and don't even give the author credit. FOSS and its gift culture ethos just isn't working in today's world. The software market of today is a dark forest.
hodgesrm 6y ago
> 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. [1] https://github.com/elastic/elasticsearch/blob/master/LICENSE.txt https://github.com/elastic/elasticsearch/blob/master/LICENSE...
- pas 6y ago
  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.)
  - jblwps 6y ago
    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."
dvfjsdhgfv 6y ago
So what would be your advice for them in this situation? They are developing a product for Amazon for free, Amazon is making tons of money on it and they don't receive anything back.
franciscop 6y ago
The problem of the known open source licenses (vs this no-precedent one) is that they were made long time ago for other situations and they do a poor job at protecting open source authors from the abuse that we see from Amazon and similar.
- acatton 6y ago
  I'm confused by the "abuse" part. If I think the author of the GPLed project "foobar" is a jerk, and I fork it and maintain it without colaborating with foobar's original author, am I "abusing" the GPL? Personally, I don't think so, and I think I should have the right to do so. I wonder how this is different from Amazon behavior here. (I want to make clear that I'm not saying Shay or anybody at elastic is anything. This is for the sake of the example.) Now foobar's author can stop me from using his project name by registering a trademark on it. But the GPL is working as intented. At the end, "maintaning" a fork of Elastic is wasted engineering effort and time, it would be better to collaborate. But I personally think Elastic should just ignore Amazon and keep doing what their doing, instead of making their product proprietary.
  - franciscop 6y ago
    I never said forking is abusing. But if you fork it, position it as an official product with the same name on your platform and lie on twitter saying that your foobar was a collaboration with the original foobar author then yes, you are definitely abusing your power. On the other point: "the GPL is working as intented" yes but not as the authors want, hence the change of license! Nothing wrong with that IMHO.
    - acatton 6y ago
      As I said, foobar's author can sue me over trademarks in the situation you've described.

signal11 6y ago

If you're a paying customer, you are probably fine. If you're using SSPL'd Elastic (or Mongo DB, the risks are the same) for anything serious -- i.e. beyond a hobby, get legal advice ASAP. SSPL isn't an OSI certified license; many would call it at best a 'shared source' license because of the riders attached. [DELETED because, as user `gpm` points out, OSI doesn't own 'open source' as a trademark, sorry about that -- the need for legal advice doesn't go away, however.] In fact given their kvetching about Amazon and their trademark, Elastic's cheerleading of open source in this and the original blog post seems to be a bit misleading and doing OSI's trademark a disservice.[/DELETED]

gpm 6y ago
OSI does not have a trademark on the term open source, they tried and failed to acquire one.
- ddevault 6y ago
  Trademarks are not a requirement for defining terminology. The word "cake" is not trademarked, but if I sell you a used car tire when you buy a "cake" from me, I still lied and misled you about the product.
- prepend 6y ago
  I think they need one. Comically, this is why trademarks exist to prevent people from confusing the market with similar and reused terms. I think we need a CreativeCommons-like trademark for open source software before it’s too late.
  - signal11 6y ago
    I think "OSI Approved Open Source License" could easily be an OSI trademark, if it's not already. Ironicallly, like many other organizations, Elastic themselves have used OSI's approval as a benchmark for 'open source'[1]: > Is X-Pack now open source? > Updated on 2018-04-24 with a link to the Elastic License > Open source licensing maintains a strict definition from the Open Source Initiative (OSI). > As of 6.3, the X-Pack code is open under the Elastic License. However, it will not be 'open source' as it will not be covered by an OSI approved license. The interaction model for open X-Pack will be identical to the open source Elastic Stack, including the ability to inspect code, create issues and open pull requests via our existing GitHub repositories. [1] https://www.elastic.co/what-is/open-x-pack https://www.elastic.co/what-is/open-x-pack
    - gpm 6y ago
      > I think "OSI Approved Open Source License" could easily be an OSI trademark, if it's not already. Something along those lines is trademarked
    - un_ess 6y ago
      https://opensource.org/trademark-guidelines https://opensource.org/trademark-guidelines lists OSI's policy for trademark usage. 3. Usage that Require Prior Written Approval 3.1. Distributing software under a license approved by OSI ("OSI Approved License")
  - colechristensen 6y ago
    I think there are valid differences in opinion in what “open source” means and an organization with an agenda shouldn’t try to own the terminology.
pas 6y ago
It's especially ... ironic, that they think Amazonification is not-ok, but Enterprizificaion (open core) is a-ok. That said hosting ES is basically the same as building a carwash, or a gas station, or let's say a printing house. You get the machinery and build your own support services around it. Even the unit economics are not that different. AWS spent probably millions of dollars to push the marginal price down. The initial cost of procurement for machinery might be zero for ES as opposed to buying a printing press, but none of the aforementioned sectors are limited by the cost of machinery. In case of brick and mortar services the cost of land, labor, construction, and logistics are all a lot more important. Yes, okay, but what about AWS's advantage, their "moat"? Elastic will never be able to match that. This is the same problem that plagues the browser, phone OS (and other) markets. Google can easily spend a billion USD each year on fiddling with Chrome and Android. Mozilla, Canonical, KDE, and others can't. AWS has the platform advantage, Google has money. It seems these market forces virtually force ES to become a "public good" like the Linux kernel. (Or Elastic could try to fork it and stop using any kind of free/open/available license. And try to find business niches.) But at this point the cat is out of the bag. Likely no amount of license engineering will be sufficient to overcome AWS' advantage.
- jacobr1 6y ago
  The cloud providers would just build a competing service if they couldn't co-opt an existing popular open source solution. Or anoint an adjacent solution, like solr in the case of elasticsearch. But what can be done and we really haven't seen a "open-core" type infra component try this yet: is require open-sourcing changes. The opendistro approach sorta gets us there, in a hard-fork sense, but seems in adequate and is really only being done for connivence rather than licensing requirements. But we already have a licensing solution: the AGPL. But no enterprise or saas startup wants to touch AGPL software for the fear of it contaminating proprietary code. So it seems to me the solution is a hybrid APGL for cloud providers and apache/mit for others approach. Such a license seems feasible to write and would be superior to open-core for most users.
  - pas 6y ago
    ... a bit theoretical, but how is the GPLv3 with the anti-Tivo provision okay? OSI definition 10: License must not restrict interface, and def. 9. License must not restrict other software it gets distributed with. (So I can't put my encrypted bootloader and verifier into the same thing.)
delfinom 6y ago
"OSI certified" doesn't mean shit regardless in a legal manner. It's just toilet paper. Always have your own legal review by IP lawyers.

jameshilliard 6y ago

Yep, it's also incompatible with virtually all copyleft open source licenses. So if you were using any AGPLv3 code with elastic you now have to switch to Amazon's fork.

alisonkisk 6y ago
Is incompatible with non-Affero GPL?
- jameshilliard 6y ago
  Yes, it's incompatible, although you might be fine if you aren't distributing it or running it as a service. SSPL requires re-licensing of all code to the SSPL, GPL has provisions that disallow re-licensing. > the simple requirement that if you provide the product as a service, you must also publicly release any modifications as well as the source code of your management layers under SSPL This provision is effectively impossible for anyone to comply with in practice. Calling this a "simple requirement" is a barefaced lie.
  - pas 6y ago
    Especially that no independent party with any authority (ie. a court) determined what's covered under "management layers". If I use a custom kernel (that's optimized to run the JVM and has filesystem and block storage optimizations for ES), do I have to provide the source for that? (It seems trivial that it's not "management", but naturally Elastic's interest lies in arguing that yes, that are covered under management layers too.)
Proven 6y ago
"with" Elastic how? I doubt that is true, in fact it seems like a completely random FUD statement. At least GP tried to make heir FUD ambiguous.

alex_young 6y ago

This lack of clarity in law will likely result in huge issues in the sale of your startup if you ever go that route. Who wants to buy a potential lawsuit because of a database selection?

alisonkisk 6y ago
There are always "potential" lawsuits, and stripes already use many many licensed dependencies with various proprietary licenses.
- alex_young 6y ago
  This is true, and there are entire categories of licenses which are considered untouchable in an acquisition because of the risk associated with them.

prepend 6y ago

I find these kind of obscure, “don’t worry” posts to increase my worrying. Part of the simplicity of open source is that it’s available for easy audit. Having to hire lawyers to use a product means I probably won’t use it. I also think having people saying “we’re open, but read the fine print” is not good for open source collaboration as it increases confusion and complexity. Elastic is moving the way of a commercial software company. That’s perfectly fine as it’s their company, but it’s just different than open source.

colechristensen 6y ago
Yup. If you, understanding your product, your users, and your licensing, write a post for your users not to worry, it means that you thought about your changes and came to a well informed position that there was reason for worry.
- greyhair 6y ago
  The Hitchhiker's Guide to the Galaxy starts out with "Don't Worry". By the end of the sixth book in the trilogy find it was right to worry all along.
- dvfjsdhgfv 6y ago
  Or you might have a history of people being mad at you (for good reasons, like the story of security of the ELK stack). They know very well everybody will get mad again, so they precede all explanations by "don't worry".
- dragonwriter 6y ago
  Well, you try to make it sound unlikely, but it's exactly like corporate messaging that there are no plans for layoffs in the wake of bad financial news. The idea that a license change made to prevent competition and enable a business model centered around extracting monopoly rents from customers has no effect on customers is ludicrous. It's whole point is to have an adverse effect on customers.

luisfmh 6y ago

So what should we be using instead of elasticsearch for logs? To mitigate that licensing risk?

mjburgess 6y ago
https://www.amazon.com/s?k=Seagate+BarraCuda&ref=nb_sb_noss_2 https://www.amazon.com/s?k=Seagate+BarraCuda&ref=nb_sb_noss_... & grep ( with parallel ) ...if it matches your use case, you'll find it trivially outperforms elasticsearch.
- dvfjsdhgfv 6y ago
  Search speed is not the most important aspect at play here.
hodgesrm 6y ago
ClickHouse. It's Apache 2.0 and will stay that way. Edit to add disclaimer: I work on ClickHouse.
pritambaral 6y ago
Using an AGPL-licensed fork does not suffer from this risk.
corford 6y ago
We're using Grafana and Loki to great effect.
technics256 6y ago
Loki and grafana are great, use it on all my clients eks clusters.

api 6y ago

The open source world needs to come together and create a license that is well crafted. Otherwise we will keep seeing these less suitable licenses. So far the FOSS world seems to be pretending this problem doesn’t exist. Pretending a problem doesn’t exist doesn’t make the problem go away. It makes you go away as you become irrelevant. There is the AGPL, but it's not quite right. It also has the letters G-P-L in it, which spooks a ton of people still influenced by Microsoft's billion dollars worth of anti-GPL FUD. (I'm convinced you could just rename the GPL and all those problems would go away.)

dragonwriter 6y ago
> The open source world needs to come together and create a license that is well crafted. It has created several. It hasn't created licenses well-crafted for purposes directly contrary to the purpose of having open source software, because that's not what the open source community is interested in. > So far the FOSS world seems to be pretending this problem doesn’t exist. From the point of view of the FOSS world, the issue here is not a problem; creators having an exclusive ability to monetize software as a service isn't a purpose open source is intended to serve; in fact, avoiding the lock-in that results from such exclusivity is a big part of the point.
- api 6y ago
  > From the point of view of the FOSS world, the issue here is not a problem; creators having an exclusive ability to monetize software as a service isn't a purpose open source is intended to serve; in fact, avoiding the lock-in that results from such exclusivity is a big part of the point. If the creators get nothing, then why bother? Why slave away to make software just to give free labor to billion dollar companies while you get nothing? Is free labor for Amazon what open source is about? If open source refuses to adapt to the realities of today's software ecosystem, it will die out... or at least "serious" open source projects will die out and all that will remain is hobbyist level stuff, abandonware, and half-done academic projects. Personally I do think FOSS in its present form is going to die for most major projects. You'll still see FOSS libraries, building blocks, academic projects, and some major projects that really are large and old enough to have enough real grassroots contributors to keep them going. For major projects in the future you're going to have something more like a shareware model but with source-available. Nobody creating a new large-scale project today is going to give it a license that they know will result in somebody else productizing it, making a fortune, and giving them nothing. At least Amazon acknowledges where things came from... in some cases the productizers even rename the project and don't even give the author credit. FOSS and its gift culture ethos just isn't working in today's world. The software market of today is a dark forest.

hodgesrm 6y ago

> 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. [1] https://github.com/elastic/elasticsearch/blob/master/LICENSE.txt https://github.com/elastic/elasticsearch/blob/master/LICENSE...

pas 6y ago
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.)
- jblwps 6y ago
  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."

dvfjsdhgfv 6y ago

So what would be your advice for them in this situation? They are developing a product for Amazon for free, Amazon is making tons of money on it and they don't receive anything back.

franciscop 6y ago

The problem of the known open source licenses (vs this no-precedent one) is that they were made long time ago for other situations and they do a poor job at protecting open source authors from the abuse that we see from Amazon and similar.

acatton 6y ago
I'm confused by the "abuse" part. If I think the author of the GPLed project "foobar" is a jerk, and I fork it and maintain it without colaborating with foobar's original author, am I "abusing" the GPL? Personally, I don't think so, and I think I should have the right to do so. I wonder how this is different from Amazon behavior here. (I want to make clear that I'm not saying Shay or anybody at elastic is anything. This is for the sake of the example.) Now foobar's author can stop me from using his project name by registering a trademark on it. But the GPL is working as intented. At the end, "maintaning" a fork of Elastic is wasted engineering effort and time, it would be better to collaborate. But I personally think Elastic should just ignore Amazon and keep doing what their doing, instead of making their product proprietary.
- franciscop 6y ago
  I never said forking is abusing. But if you fork it, position it as an official product with the same name on your platform and lie on twitter saying that your foobar was a collaboration with the original foobar author then yes, you are definitely abusing your power. On the other point: "the GPL is working as intented" yes but not as the authors want, hence the change of license! Nothing wrong with that IMHO.
  - acatton 6y ago
    As I said, foobar's author can sue me over trademarks in the situation you've described.