[HN Gopher] Grafana, Loki, and Tempo will be relicensed to AGPLv3
___________________________________________________________________
Grafana, Loki, and Tempo will be relicensed to AGPLv3
Author : WalterSobchak
Score : 505 points
Date : 2021-04-20 17:17 UTC (5 hours ago)
(HTM) web link (grafana.com)
(TXT) w3m dump (grafana.com)
| natas wrote:
| this is good, even if loki can't scale well it's still good for
| the community.
| gnalck wrote:
| Those who have reservations about the terms of AGPLv3 - would any
| of you prefer if it was licensed under BUSL1.1 (i.e., source-
| available or eventually-open-source) instead? I'm curious to see
| the perspectives of businesses as to whether AGPLv3 or BUSL-1.1
| is a "bigger risk" when compared to the previous Apache 2.0
| license.
|
| My gut feeling is that those passionate about open source on the
| whole will tend to prefer AGPLv3, while businesses or those
| making decisions on the behalf of a business, may prefer
| BUSL-1.1. I think there are trade offs with either approach.
| josephcsible wrote:
| > My gut feeling is that those passionate about open source on
| the whole will tend to prefer AGPLv3, while businesses or those
| making decisions on the behalf of a business, may prefer
| BUSL-1.1.
|
| Your gut is onto something. People who care about something
| bigger than themselves prefer AGPL, while those who only care
| about their own profits prefer BUSL.
| richardwhiuk wrote:
| The BUSL is worse - obscure licenses are problematic.
|
| The problem with the AGPL is it's very unclear what counts as
| linking, and this has never been tested in court, and that it's
| not clear what "network access" needs to look like.
| dec0dedab0de wrote:
| I like the AGPL, but I would like an extra step that forces you
| to distribute code even you have not modified it. This would be
| in the case of the original being unavailable for some reason.
|
| Does anyone know how difficult it would be to have the login page
| for a web app be a different license? The idea being that the
| only users of the AGPL code are ones that have a valid account.
| Off the top of my head a reverse proxy, with a completely
| separate auth app would do the trick, but would be a bit of a
| pain.
| jabiko wrote:
| Even though we use Grafana only internally and there would be no
| problem with AGPLv3 in theory I see big meetings with legal
| coming up which might result in us not being able to use it
| anymore.
|
| I could image that its the same with other corporations. In the
| end that might hurt the popularity of Grafana quite a lot.
| jchw wrote:
| While many are dismissing your concerns, I do think this is a
| valid point, at least to some degree. For example, Google
| institutes a blanket ban on all AGPL code:
|
| https://opensource.google/docs/using/agpl-policy/
|
| Now, one can read into why exactly this may be, though I have a
| strong feeling it is simply due to the fact that enforcing
| correct use of the license is harder than usual. Even if you
| use it alongside only compatible licenses, like GPLv3, it
| presumably would make the entire distribution subject to AGPLv3
| restrictions. GPLv3 virility is a little easier to deal with,
| and of interesting note the Bazel build system contains some
| awareness of licenses.
|
| https://docs.bazel.build/versions/0.24.0/be/functions.html#l...
|
| On the other hand, one might view this as a benefit. So, I
| guess it depends on who you ask, really. It's not clear that
| big corporations would necessarily have an easier time with
| SSPL or TSL either.
|
| Note: IANAL, please do not take my understanding of how these
| software licenses work as fact :)
| raegis wrote:
| I suspect this is not a popular opinion, but Google's AGPL
| policy reads like FUD to me. From the first paragraph:
|
| "...extremely difficult for Google to comply with..."
|
| and
|
| "...presents a huge risk to Google..."
|
| and later in the document is the best part:
|
| "This viral effect requires that the complete corresponding
| source code...".
|
| All from a company which built itself on GPL software. This
| reminds me of Steve Ballmer ranting about Linux being a virus
| 20 years ago.
|
| More:
|
| "Do not install AGPL-licensed programs on your workstation,
| Google-issued laptop, or Google-issued phone without explicit
| authorization from the Open Source Programs Office."
|
| Assuming Google follows its own policy, this just creates a
| hassle for its employees. Worse, Google making this public
| sends a strong anti-AGPL message to other companies. I'd bet
| $10 RStudio server (AGPL) is installed somewhere at Google
| (perhaps the commercial version). But other organizations
| with less sophisticated legal departments might just ban
| RStudio completely following Google's lead. I would not call
| Google irresponsible here, but I think it could act more
| responsibly.
| gpanders wrote:
| It is absolutely FUD.
|
| https://drewdevault.com/2020/07/27/Anti-AGPL-
| propaganda.html
| jeffbee wrote:
| On the one hand you have a large department of battle-
| hardened IP lawyers who say that AGPL virality is
| overbroad and poorly defined, and on the other hand you
| have a FOSS advocate who says it's fine, so I guess we'll
| never know for sure!
| josephcsible wrote:
| The FSF and other similar organizations have lawyers too.
| What do you think their opinion is?
| jeffbee wrote:
| The FSF is not generally a party to the license, so it
| makes no difference what they think.
| globular-toast wrote:
| There should be no problem with it even if you use it
| externally. It's about time companies stopped seeing open
| source as freely exploitable. Every company that uses open
| source software should be obliged to contribute, or pay for
| proprietary software.
| bboreham wrote:
| Would you consider paying for a licence to use it?
| jabiko wrote:
| Honestly, I have no idea.
|
| I think if there would be a possibility to pay money to have
| what we are doing reviewed by Grafana and be "certified" to
| be withing what they consider acceptable under the AGPL that
| might actually be a good option
| bboreham wrote:
| What about just paying for a commercial licence to use it
| to meet your needs?
| jabiko wrote:
| I have no Idea. Realistically its probably not the
| license cost but the one time and the perpetual
| operational overhead associated with the license that's
| going to be the problem.
| peterbonney wrote:
| That makes zero business sense. Your first post is about
| the one time and perpetual operational overhead
| associated with operating under the prior FOSS license
| (yes, you're saying it's the new license that's a
| problem, but since the situation arose while operating
| under the prior conditions then implicitly those
| conditions carried this very overhead). Operating under
| any license carried an overhead, unless you simply choose
| to not read (or to read and ignore) the fine print.
| jabiko wrote:
| > Your first post is about the one time and perpetual
| operational overhead associated with operating under the
| prior FOSS license
|
| My first post is about the fact that even though the
| planned use case would be 100% compliant to the AGPLv3
| license the fear that is associated with that license
| could prevent such use.
|
| > That makes zero business sense
|
| Purchasing a license in that case while not strictly
| necessary might be seen as an insurance. So that makes
| business sense.
|
| In the end though I highly doubt that's whats going to
| happen. The most likely outcome is that we just get told
| to get rid of Grafana and use something else.
| peterbonney wrote:
| > In the end though I highly doubt that's whats going to
| happen. The most likely outcome is that we just get told
| to get rid of Grafana and use something else.
|
| Whatever you replace it with will have the same licensing
| overhead. Again, this makes no sense.
|
| If you said we can't afford to pay for it, fine. But you
| explicitly said you don't think cost is an issue.
|
| Maybe I'm making the wrong inference, but it sounds like
| you're afraid your higher ups just don't want to have any
| restrictions placed on whatever business need it is that
| Grafana is filling for you. If I haven't misunderstood
| that fear, then I regret to say that any software product
| other than one you build and maintain yourselves will
| come with some restrictions or the possibility of future
| restrictions.
|
| When I say this makes no business sense, that's what I'm
| trying to get at: other than (potentially) licensing
| cost, any Grafana substitute will come with the same
| issues, plus switching costs. So unless there is a FOSS
| product that provides a better solution to your problem,
| by definition switching will be more costly than
| maintaining status quo.
|
| Or am I missing the point?
| t-writescode wrote:
| If I was in charge of the money, assuming it's a reasonable
| price for on-prem Grafana, I would pay for a license to
| Grafana, just to not have the licensing stress.
| dvfjsdhgfv wrote:
| In a large number of cases, this is not an issue at all. Just
| like we all use GPL-ed kernel and a ton of other stuff. There
| is also no problem with making AGPL-based services available to
| customers. The caveat is that when you modify AGPL-based code,
| you need to make the source of these modifications available,
| too. For some reason, this scares Amazon a lot. Developers know
| that and use AGPL when they don't want to be screwed by AWS.
| jsdwarf wrote:
| I don't get why Amazon should be scared by AGPL. I mean all
| of their services run on GPLed Linux, why should they be
| scared by a GPLed Grafana?Even if they had to open-source
| their Grafana contributions, they could do this in a way that
| they are worthless for potential competitors (e.g. if the
| contribution depends on a proprietary Amazon system)
| yorwba wrote:
| > they could do this in a way that they are worthless for
| potential competitors (e.g. if the contribution depends on
| a proprietary Amazon system)
|
| That is not allowed.
|
| """The "Corresponding Source" for a work in object code
| form means all the source code needed to generate, install,
| and (for an executable work) run the object code and to
| modify the work, including scripts to control those
| activities. However, it does not include the work's System
| Libraries, or general-purpose tools or generally available
| free programs which are used unmodified in performing those
| activities but which are not part of the work. For example,
| Corresponding Source includes interface definition files
| associated with source files for the work, and the source
| code for shared libraries and dynamically linked
| subprograms _that the work is specifically designed to
| require, such as by intimate data communication or control
| flow between those subprograms and other parts of the
| work._ """
|
| (Emphasis on that last part mine.)
|
| """Notwithstanding any other provision of this License, if
| you modify the Program, your modified version must
| prominently offer all users interacting with it remotely
| through a computer network (if your version supports such
| interaction) an opportunity to receive the Corresponding
| Source of your version by providing access to the
| Corresponding Source from a network server at no charge,
| through some standard or customary means of facilitating
| copying of software."""
|
| If Amazon modifies Grafana so it depends on a proprietary
| Amazon system, the source code for that system is included
| in the Corresponding Source, and if they allow users to
| interact with that modified version, they need to provide
| them with access to the proprietary system's source code.
| Iolaum wrote:
| If Amazon was really scared of AGPL then MongoDB wouldn't
| need to relicense.
| pritambaral wrote:
| This is a myth that has been repeated far too often. Amazon
| had made no move on MongoDB _until MongoDB started using
| the SSPL_. No hosted-MongoDB, no MongoDB-derived products,
| nothing.
|
| MongoDB Inc. instead went after much smaller companies,
| like mLab, holding their future hostage and thus strong-
| arming them to sell themselves to MongoDB Inc. a short
| while before they announced the monopolistic license change
| that would have effectively shut those small companies down
| anyway.
|
| Frankly, I'm tired of hearing this myth. MongoDB would like
| you to believe they were David in a fight against Goliath
| -- PR and marketing have always been their strong suit --
| but they were quite happy playing Goliath themselves while
| pointing fingers at imaginary Goliaths.
| drdaeman wrote:
| Cannot be helped - that's just fear of the unknown.
|
| If legal is familiar with AGPL, like they are with GPL, BSD or
| Apache, they should see no issue. This change does not really
| affect anyone except for the very small number of
| people/companies that make their own changes to software and
| make this software available online to others.
|
| If you aren't such a company and legal would still say you guys
| can't use e.g. Grafana anymore... the truth will be that it's
| some incompetent (or severely underhanded, where they can't do
| any research and err on the side of caution) legal department,
| failing at their jobs.
| gen220 wrote:
| Many devs at Google routinely use GPLv3 code, in GNU Emacs,
| to make an example.
|
| Unless you're repackaging Grafana into an app bundle for
| customers to use, there's no violation occurring here, right?
| kevincox wrote:
| GPL and AGPL are very different here.
|
| If a developer uses GPL Emacs to write a server that uses
| GPL libraries and Google runs that sever in their
| datacenter it is very clear that Google doesn't have to
| release any source code.
|
| However Google's argument is that if they make a web
| application that uses AGPL MongoDB as a backend it is
| unclear if 1. The user is interacting with MongoDB over a
| network and 2. do they need to release the code of their
| server.
|
| It appears that the answers are 1. Yes and 2. No but
| apparently Google isn't confident to use that in court. (Or
| at least they don't see enough benefits for that risk)
| 188201 wrote:
| I think that's misunderstanding of AGPL. For internal use, AGPL
| does not require to share the proprietary part.
|
| If a company develop an proprietary UI and use Loki as backend,
| this is not serving Loki directly to customer, so that does not
| require company to release their code.
|
| It is similar to GPL. Dynamic linking to a GPL software does
| not require the developer releasing their code.
|
| Only provider serving Loki instance directly to customer
| required to share the code.
|
| Only Amazon is upset that they cannot just host a popular open
| source project directly on their cloud. Maybe they could pay a
| license fee for dual licensing arrangement, which is a better
| way to support open source startup.
| atat7024 wrote:
| > I think that's misunderstanding of AGPL.
|
| That's GPs point.
| klintcho wrote:
| This might be the case. However there is an additional risk
| and process component:
|
| - you might not want to risk because you don't have lawyers
| etc in your company.
|
| - even if you have lawyers etc in your company, if there are
| 2 alternatives one which is just an MIT license, you'll
| probably go for that one because you don't want to have a 1.5
| month review of the use of this AGPL licensed alternative.
|
| In general things like this
| https://github.com/xdspacelab/openvslam/wiki/Termination-
| of-... (repo with 3k stars), an effort terminated because of
| some traces of GPL code MIGHT be somewhere in there comes to
| light. Even though Grafana etc are mostly tools, for my
| startup I would probably not risk any of this (for my own
| sake and also for any kind of due diligence in case it ever
| gets acquired)
| aulin wrote:
| did not follow the events of openvslam, wouldn't they be
| required to still release the source code of the previously
| public version as GPL? also once the doubt is there, why
| not rerelease as GPL?
| rhaps0dy wrote:
| > Dynamic linking to a GPL software does not require the
| developer releasing their code.
|
| That's not true, you do have to release the code. There is no
| difference between statically or dynamically linking to a GPL
| library. Source: https://www.gnu.org/licenses/gpl-
| faq.html#GPLStaticVsDynamic
|
| You may be thinking of the LGPL.
| gpanders wrote:
| Not everyone agrees on this point [1]. One relevant quote:
| "This is ultimately a question not of the GPL per se, but
| of how copyright law defines derivative works."
|
| Whether or not dynamic linking constitutes a "derived" work
| is still an open question, legally speaking. Obviously the
| FSF has their own thoughts on this, but it's unclear how an
| actual court would rule.
|
| (IANAL, this is not legal advice, etc. etc.)
|
| [1]: https://en.wikipedia.org/wiki/GNU_General_Public_Licen
| se#Lin...
| tamalsaha001 wrote:
| That does not seem to be the case. From [1]
|
| The difference between the AGPL and traditional GPL is
| simple: The AGPL seeks to close a "loophole" that allows a
| company or organization to modify GPL'ed software and use it
| to provide a service -- but without actually distributing
| changes. So a company can take a package like, say, WordPress
| and modify the software significantly to sell a service --
| but hold back changes because it's not technically
| "distributing" or "propagating" the software. The AGPL goes a
| bit further and says that if the program is "intended to
| interact with users through a computer network" and if the
| version that you received gives users "the opportunity to
| request transmission to that user of the Program's complete
| source code," you have to maintain that functionality and
| distribute the modified version.
|
| [1] https://www.networkworld.com/article/2229265/is-the-
| affero-g...
| rasz wrote:
| Wasnt this solved with GPLv3 anti tivoization rules?
| tzs wrote:
| The anti-tivoization rules only apply if:
|
| 1. the software is conveyed in a "User Product", and
|
| 2. that conveyance occurs as part of a transaction in
| which the right of possession and use of that product is
| transferred to the recipient.
|
| A "User Product" is defined as 'either (1) a "consumer
| product", which means any tangible personal property
| which is normally used for personal, family, or household
| purposes, or (2) anything designed or sold for
| incorporation into a dwelling'.
|
| In other words, it only covers software that is installed
| on actual physical hardware when that hardware is sold
| (or rented, etc) to the consumer.
|
| For a sale of a service, it is completely out of scope.
|
| This is probably the most misunderstood clause in GPLv3,
| with people thinking that it some sort of general anti-
| DRM clause. Almost everybody, for example, thinks that it
| is why you can't have GPLv3 code on the Apple app store,
| but because it only applies to conveyances that are part
| of the transaction by which you acquire your iPhone or
| iPad it in fact does not apply to software purchased
| later from the app store. Apple's app store DRM is
| perfectly compatible with GPLv3.
|
| The incompatibility between the app store and GPL is that
| the license agreement for the app store says you won't
| redistribute the app or reverse engineer it. GPL does not
| allow adding additional license restrictions like that,
| and so you can't satisfy both the app store license and
| GPL.
| detaro wrote:
| How would the anti-tivoization rule that discusses
| physical products apply to a service?
| btown wrote:
| I think _this_ is a misunderstanding of how vague the AGPL
| actually is.
|
| The key clause is "your modified version must prominently
| offer all users interacting with it remotely through a
| computer network (if your version supports such interaction)
| an opportunity to receive the Corresponding Source of your
| version."
|
| Would putting AGPL software behind a reverse proxy change the
| fact that you're a user interacting with it remotely? What
| about a reverse proxy that changes/adds some headers? What
| about a really smart reverse proxy that reformats some of the
| output or repackages it or mixes it with things from other
| data sources? Is that materially different from the API that
| powers the "proprietary UI" you're describing?
|
| And say you're pretty confident that you're on the right side
| of things. Can you point to any case law where courts have
| established precedent about what "interacting with it
| remotely" means in this context? No? Then to be on the safe
| side, you'll probably need to maintain a source code
| repository for your Corresponding Source, remember to update
| it every time you update a minor version of the service
| internally, and maintain an info screen in your product with
| "prominent" links to that source code repository, which
| likely means it needs sign off from a product team if not a
| legal team as well. All things that add expense and barriers
| to entry.
|
| I think the AGPL is great for services like Grafana's UI
| itself, where there's likely to be a "human gap" between the
| software and anyone outside your organization. But things
| like Loki that are _designed_ to power other proprietary
| systems that may well be touched by end users through a
| computer network, where Loki 's output may have influence or
| side effects on the output the user sees? I don't think it's
| nearly as clear what liability that entails.
|
| (Obligatory: Not a lawyer, the above is not legal advice.)
| PeterisP wrote:
| Most companies who use Grafana or Loki as part of some
| deployment would use an unmodified version, so the only
| AGPL specific clause, which you cite, would not apply and
| is irrelevant.
| Thaxll wrote:
| And 99.99% of users don't modify the code so it's
| irrelevant.
| Rapzid wrote:
| I don't understand the point you're trying to make with the
| reverse proxy as it doesn't seem related to anything the
| parent wrote.
| btown wrote:
| Sure! Saying that the parent's "develop an proprietary UI
| and use Loki as backend" is a slippery slope to "user
| sees data that incorporates data served from Loki" which
| I am arguing could be interpreted as data that would
| require the developer to maintain a source repository for
| Loki under the AGPL.
| Rapzid wrote:
| I see now and yes the AGPL seems vague in that regard.
|
| If it's anything like dynamic linking and GPL that could
| be considered okay even if it's not the intention of the
| licensee. Seems like the license should be more explicit
| about what "interacting with" entails.
| jpalomaki wrote:
| How does this actually work towards your employees or 3rd
| party personnel (for example consultants) getting access to
| the tools - would you have to make the source code available
| for them and allow them to distribute the code?
| josephcsible wrote:
| A company giving its own employees access to software for
| work use only doesn't count as distribution, but giving it
| to contractors can: http://www.gnu.org/licenses/gpl-
| faq.en.html#InternalDistribu...
| jpalomaki wrote:
| AGPL uses the wording "all users interacting with it
| remotely through a computer network".
| jononor wrote:
| Hmm. Where does Grafana people stand on what constitutes a
| "derivative" work? Are my Grafana dashboards derivatives of
| Grafana, and must now be published? If I embed a Grafana
| dashboard in my application, is my application now a derivative
| of Grafana and must be released as AGPLv3?
| jononor wrote:
| The Q&A suggests that "unmodified" distributions are not an
| issue. But if I distribute dashboards, custom configurations,
| etc - is that a "modification" ?
| nopzor wrote:
| nope, that wouldn't be a modification to the AGPL-licensed
| grafana. you are free to do that.
|
| plus, dashboards and configuration are inherently ("source
| available"), so even if one were to consider them to be
| modifications (which they're not), you are already
| distributing them in source form ;-)
|
| [note: am co-founder/ceo of grafana labs]
| lovasoa wrote:
| The AGPL license states
|
| > A compilation of a covered work with other separate and
| independent works, which are not by their nature extensions
| of the covered work, and which are not combined with it
| such as to form a larger program, in or on a volume of a
| storage or distribution medium, is called an "aggregate" if
| the compilation and its resulting copyright are not used to
| limit the access or legal rights of the compilation's users
| beyond what the individual works permit. Inclusion of a
| covered work in an aggregate does not cause this License to
| apply to the other parts of the aggregate.
|
| Doesn't a product that offers grafana-powered dashboards
| "form a larger program" ?
| abraae wrote:
| How about an intelligent proxy that effectively intercepted
| and modified the queries that Grafana send to it's back
| end?
|
| Is that considered a modification?
|
| In my eyes it shouldn't be as no changes are needed to any
| Grafana code, it's all just networking.
|
| Interested to get your perspective.
| wyoawayd wrote:
| There's a lot of weird assumptions in this thread that this is
| some sort of strike against Amazon/AWS. It's not. AWS's managed
| grafana is built in partnership with grafana labs, and this
| license change won't affect it.
|
| From Grafana:
|
| "AWS is a strategic partner, and given the commercial
| relationship AWS has with us for AMG, AWS and their AMG customers
| are not impacted by this change. We hope that other XaaS
| providers follow AWS's lead in working with open source software
| companies in similarly sustainable ways."
|
| https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...
| sandstrom wrote:
| It could still be with AWS in mind. After this change, they'll
| be in a better negotiation position vs. AWS, since AWS can't
| (as easily) threaten that they'll build their own competing
| offer.
| 867-5309 wrote:
| Grafana: The analytics platform for all your metrics. Allows you
| to query, visualize, alert on and understand your metrics no
| matter where they are stored. Create, explore, and share
| dashboards with your team and foster a data driven culture.
|
| Loki: Web Analytics Dashboard for NGINX
|
| Tempo: An open source, easy-to-use and high-scale distributed
| tracing backend. Tempo is cost-efficient, requiring only object
| storage to operate, and is deeply integrated with Grafana,
| Prometheus, and Loki. Tempo can be used with any of the open
| source tracing protocols, including Jaeger, Zipkin, and
| OpenTelemetry.
| znpy wrote:
| Big kudos, they learned from elastic' story
| oxfordmale wrote:
| I wonder how long will it take for Amazon to announce their an
| open source fork.
| josephcsible wrote:
| Unlike ElasticSearch, Grafana itself is still open-source.
| Forking Grafana would be viewed a lot less favorably than
| forking ElasticSearch was.
| sitkack wrote:
| Thank you! AGPL is a fine license for software freedom.
| rodgerd wrote:
| Seems like a sensible choice - one of the things that as cause me
| to look askance at some of the anti-serverisation (urgh) licenses
| has been companies trying to bespoke something when the AGPL has
| always been right there to solve the problem they're trying to
| tackle.
| lovasoa wrote:
| The announcement seems to say that products that include an
| unmodified version grafana can still be proprietary, and only
| modifications to grafana itself will have to be published.
|
| However, the AGPL itself is quite clear that if you distribute a
| larger work based on an AGPL software, the whole larger work has
| to be distributed under the same license.
|
| Would you still be confident shipping a proprietary product that
| includes a grafana dashboard ?
| pavon wrote:
| The GPL and AGPL are clear that bundling does not constitute a
| derivative work, and does not require you to license the
| bundled works under the GPL/APL.
|
| > Inclusion of a covered work in an aggregate does not cause
| this License to apply to the other parts of the aggregate.
| https://www.gnu.org/licenses/agpl-3.0.en.html#section5
| https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
|
| If you write a custom plugin for Grafana, then that plugin will
| likely need to be distributed under the AGPL (depending on
| Grafana's plugin architecture), but not your entire app.
|
| I would be completely confident in bundling in this manner. The
| AGPL3 and GPL3 have identical wording on this matter, and it
| has been a well understood aspect of the GPL for decades.
| yjftsjthsd-h wrote:
| Okay, so they go out of their way to avoid answering how this
| actually affects people, so I'll ask here: If a company uses
| grafana internally, this should have no effect, right? And then
| the next step: If a company did offer grafana-based dashboards to
| customers but wasn't actually modifying grafana, what if anything
| does this do?
| josephcsible wrote:
| They'd have to offer the source code to Grafana itself, which
| has basically negligible effect since it doesn't have anything
| of theirs in it.
| e12e wrote:
| Presumably - offering dashboards to users, would count as
| distribution to those users (internal or otherwise).
| _Unmodified_ Grafana like has /will get a link to source
| code/license - that would likely cover you - although if
| Grafana goes away (or becomes closed source) - you might have
| to offer a copy of the source code on request?
| frenchman99 wrote:
| They do say it:
|
| > It's important to note that this change does not prevent our
| users from using, modifying, or providing our open source
| software to others -- provided, however, that under the AGPL
| license, users have to share source code if they are modifying
| it and making it available to others (either as a distribution
| or over a network). For distributors, AGPL has the same source
| code sharing requirements as GPL. Those conditions are designed
| to encourage third parties looking to modify the software to
| also contribute back to the project and the community.
| technics256 wrote:
| It's still unclear to me if this also means things like
| custom dashboards, etc?
| Andrew_nenakhov wrote:
| When we released our server product under GNU AGPL v3 license, we
| have received a rather negative reaction from other participants
| in our field.
|
| The general sentiment was, "this license makes a useless
| curiosity".
|
| I wonder where does this hostility come from. Jealosy? FUD?
| Frustration that they can't take the source and not share own
| improvements??
| jchw wrote:
| The same reason some people dislike the GPL, but a bit more
| extreme.
|
| One of the cool things about open source is that you can go and
| use Open Source code for things that the original author may
| have never even thought of. So your implementation of some
| novel algorithm might end up being useful in some situation
| that you were not aware of or maybe did not even exist when you
| wrote the code. While it seems idealistic, it is not that
| uncommon.
|
| Now for the GPL license, depending on version, it is not a huge
| deal if you borrow GPL code. It is a fairly standard license
| that a lot of projects use. And of course GPL is compatible
| with a lot of different licenses, making it possible to
| distribute your projects under the terms of the GPL including
| code with compatible licensing.
|
| Something interesting to note is that AGPLv1 is not GPL
| compatible. AGPLv3 is not GPLv2 compatible. GPLv3 and AGPLv3
| are compatible, since GPLv3 was written to intentionally allow
| this usage. (Note: IANAL or an expert; so this should be taken
| with a grain of salt.)
|
| In the end, this is why permissive licenses have gained a lot
| of popularity. It is immensely aggravating to people when
| things that are technically possible and not spiritually
| immoral are prevented by legal barriers that feel unnecessary.
| When the ZFS on Linux project faces trouble because of software
| licensing, it feels like a farce and a waste of time and
| resources.
|
| Now imagine that the reasoning for the license choices being
| incompatible was not to protect user rights, and not simply a
| matter of differing policies between different organizations
| and their open source releases, but rather transparently a ploy
| to protect a profit model. This is where people's aggravation
| turns to anger, because it then feels like the open source
| label is being used to pull people in, then the more
| restrictive licenses are being used to seek rent forever after.
|
| The reality is obviously not quite that grim. In fact, perhaps
| because of licenses like the Timescale license and SSPL, people
| have come around to AGPL in quite a significant way. The
| Overton window of open source licenses from corporate open
| source releases may have tilted a bit more towards the
| 'restrictive' side.
|
| I don't think there's anything actually immoral about
| protecting one's own profit model. It does, at least in some
| sense, dilute what it means for software to be open source; if
| AGPL becomes popular, it will be more likely to encumber more
| projects with its requirements. Of course, in _many_ cases, the
| ownership of the copyright will be spread among multiple
| parties, and so everyone is on a level playing field, and so
| other than the burden of ensuring you adhere to the restriction
| there 's no real reason to feel that it is 'unfair' anymore
| than copyleft licenses already are.
|
| At the end of the day, GPL was a legal solution to a community
| problem, and it imperfectly encodes an idea. There is no
| perfect encoding of that idea, so it is bound to cause some
| frustration for where the expectations mismatch with reality.
| josephcsible wrote:
| The hostility comes from people who wanted to abuse the
| loophole that it closes, and/or from people who bought into
| their FUD.
| aidenn0 wrote:
| No lawyer wants to be the first one to adopt licenses with
| novel clauses because the legal system runs on precedent, so
| using something that is untested in court is higher risk.
|
| It wasn't that long ago that no large company would touch the
| GPL with a 10 foot pole.
| zokier wrote:
| The problem I have with AGPL is that you need to think about
| it, even if you just run the software and are not distributing
| it. Or rather AGPL forces you to distribute the software you
| run. This is in stark contrast to all other mainstream licenses
| where in general you don't need to think about the license at
| all if you are not distributing the software, which makes very
| worry free experience.
| gpanders wrote:
| > Or rather AGPL forces you to distribute the software you
| run.
|
| No it does not. Using AGPL software does not suddenly make
| your own software a derived work.
| zokier wrote:
| If you run AGPL licensed software you must be prepared to
| distribute it to its users.
| djb_hackernews wrote:
| Tell that to the lawyers who are paid lots of money to be
| risk adverse. As others point out, the law operates on
| precedent, no lawyer wants their decision to be the one
| that makes their employer a test piece.
| tyingq wrote:
| Is there some exception for plugins? I can see a weird situation
| where a plugin for technology 'X' doesn't allow AGPL, but Grafana
| requires it.
| mrwnmonm wrote:
| Sorry for my ignorance, what does this license mean? I find
| licenses a little bit difficult to understand.
| Shoop wrote:
| "The GNU Affero General Public License is a modified version of
| the ordinary GNU GPL version 3. It has one added requirement:
| if you run a modified program on a server and let other users
| communicate with it there, your server must also allow them to
| download the source code corresponding to the modified version
| running there." https://www.gnu.org/licenses/why-affero-
| gpl.html
| black_puppydog wrote:
| IANAL, and this is _very_ simplified.
|
| The GPL (without A) requires you to publish sources under
| compatible license (usually also GPL) if you use a software and
| distribute it (to clients for example).
|
| Git is GPL. Git _hub_ however can totally run _modified_
| versions of git on their servers to build their service, and
| doesn 't necessarily have to contribute back, since they never
| distribute their programs to the customer, but only some html.
|
| The AGPL goes one step further and requires any changes that
| github makes in that situation to _also_ be licensed under
| AGPL. That way it is like GPL, but for software that is
| typically run on servers, not on client hardware.
| mrwnmonm wrote:
| Thanks
| macnale wrote:
| 1) We distribute Grafana as docker container along with our
| product to customers. What is the impact for us and our
| customers? 2) We build Grafana on a platform which is not
| supported by out of the box. What is the impact for us and our
| customers?
| josephcsible wrote:
| You'll need to give your customers the source code you used to
| build Grafana. If your customers are just using it internally,
| then they have no new obligations. If they're letting customers
| of their own use it, then they have the same new obligations
| that you do.
| macnale wrote:
| Thank you for clarification. I read about Confluents decision
| about the license change. It looks like Confluent has
| opposite view than Grafana labs about AGPL.
|
| " Why didn't Confluent use AGPL? AGPL doesn't solve the
| problem we are trying to fix. AGPL allows cloud service
| providers to sell services using the exact software being
| licensed, and charge for it, without any limitation. This
| means the software developer has become the unpaid developer
| and maintainer for the cloud service provider--which is not a
| scenario we want to enable.
|
| Also, AGPL is too aggressive for our customers who need to
| redistribute commercial products. If you put AGPL code in a
| distributed program, you have to open source the whole
| program. We want you to be able to embed our code in
| proprietary applications, change it and not worry about open
| sourcing any of your changes. We don't think that proprietary
| applications are bad, and we think it's great if you use
| Confluent Community software to create them.:"
| josephcsible wrote:
| It sounds like Confluent doesn't get what the real problem
| is. There's 2 ways developers who also sell hosting end up
| losing all their market share to players like Amazon:
|
| 1. The big players like Amazon make custom, proprietary
| modifications to the software they're hosting, and since
| they're not technically distributing it, they don't have to
| release the changes, giving them an unfair advantage. This
| is the exact loophole that the AGPL closes.
|
| 2. Sometimes, the big players are just better/more
| efficient at hosting the exact same software the exact same
| way. There's nothing unfair or unethical about this; it's
| how the free market is meant to work that customers flock
| to them.
|
| Confluent is trying to "fix" the second "problem", which
| rather than making anything more fair, just makes it unfair
| in their favor.
| blendergeek wrote:
| I applaud this decision.
|
| I would like to see _all_ major SaaSS projects be AGPLv3. End
| users still have freedom to user, modify, and distribute the
| software. Cloud providers must share contributions.
|
| This is how I like it.
| rakoo wrote:
| > Cloud providers must share contributions
|
| To be really strict: AGPL only mandates that contributions be
| shared with the user. The freedom of users is more important
| than the freedom of developers.
|
| Of course an upstream maintainer can be a user and get the
| contributions.
| kevincox wrote:
| They have to be shared to the user under the same license. So
| any user could publish the changes publicly.
| LukeShu wrote:
| Sure, but there might be out-of-band reasons for users to
| not do that.
|
| For instance, grsecurity will sell you a security-
| hardening-patched Linux kernel. You, as the user/customer,
| have the right to take those GPL patches, and share them
| publicly. But if you do so, grsecurity will blacklist you
| as a customer, and you won't be able to get any more
| patches from them.
| m4rtink wrote:
| Didn't that preaty much out grsecurity into (an even
| bigger) obscurity as no one sane will touch a logic bomb
| like this, not to mention build their business on it ?
| jrv wrote:
| That sounds nice in theory, but the reality is also that a lot
| of more permissively licensed (BSD / Apache) projects now
| cannot use (most) parts of Grafana / Loki / Tempo anymore,
| since realistically they won't be able to or want to switch to
| the AGPL as well (because of all the pain that would incur on
| others, in turn). That means that basically the whole free code
| sharing idea goes out of the window, at least in one direction
| - Grafana can of course still integrate code from more
| permissively licensed projects into their codebase.
| the8472 wrote:
| > but the reality is also that a lot of more permissively
| licensed (BSD / Apache) projects now cannot use (most) parts
| of Grafana / Loki / Tempo anymore
|
| Doesn't that depend on how they use it? They're only AGPLing
| their backends. The tools still follow open protocols, so the
| client libraries can be permissive. I.e. the rest of their
| project won't be "infected".
| jordigh wrote:
| > projects now cannot use
|
| They can, they just don't want to because they want to ensure
| other people can produce non-free work.
|
| Remove the desire to produce non-free work and you can
| perfectly legally put copylefted code into weakly-licensed
| free code. Weak licenses don't forbid this. Copyleft licenses
| don't forbid this. There's no need for anyone to change the
| license or copyright to combine weak licenses with copyleft
| licenses.
|
| Copyleft licenses forbid proprietary code. And proprietary
| licenses forbid a lot of other things.
| Seirdy wrote:
| That's kind of the point. The purpose of MIT/BSD is to enable
| nonfree derivative works; the purpose of the AGPL is to only
| allow free derivatives. AGPL maximizes freedom by prohibiting
| further restriction of it; it's a local maxima of "user
| freedom" as a function of "developer freedom".
|
| If you want to use AGPL software in your project, you're free
| to relicense under AGPL.
| josephcsible wrote:
| I agree with the substance of what you said, but I'm going
| to nitpick a bit of wording: what you call "developer
| freedom" isn't freedom at all, and is more rightly called
| power.
|
| http://www.gnu.org/philosophy/freedom-or-power.en.html
| m4rtink wrote:
| Well, GPL is about _freedom for the users_ , not
| necessarily for the developers.
| clusterfish wrote:
| That seems like splitting hairs for ideological gain.
|
| You might as well describe freedom of movement as power
| to take someone else's job in another town, or freedom of
| speech as power to manipulate masses, or freedom to do an
| abortion as power over the unborn child. Which way the
| issues are framed says more about the author than the
| issue.
|
| Software has leverage (one developer, many users at low
| marginal cost) built-in, but that doesn't make developing
| non-(A)GPL or even proprietory software a projection of
| developer's power. Lack of competition is what lets
| developer's exert power over users, and while copyleft
| licenses help with that, they're neither required nor
| sufficient to prevent abuse of power.
|
| At the same time, copyleft doesn't come free (ha), as
| developers who need to earn a living will choose to work
| on problems where they can actually extract some profit
| to compensate for their effort. Not everyone is keen to
| work for free, or work as much / as hard for free as they
| would if they could make a living off it. So yes you
| might get free-er software, but less of it.
| 533474 wrote:
| I suggest you read more deeply into the legal
| interpretations; it is not so clear cut as you put it.
|
| A more permissive license is simply incompatible with this
| project's ideals - they are willing to sacrifice developer
| convenience for user freedom and prevent corporate theft and
| bastardization of the codebase into competing products
| 533474 wrote:
| *Correction: My comment is a reply to Seirdy's answer
| [deleted]
| watermelon0 wrote:
| I have a question regarding AGPL, that I couldn't answer by
| Googling or reading the license.
|
| Let's say that Postgres server is licensed under AGPL, and I
| modify it to my needs. I have a closed source web application,
| that is publicly accessible, and uses Postgres for storing
| data.
|
| a) Do I need to publish source code of my version of Postgres?
|
| b) Does my application (which relies on Postgres, and my
| patches) need to also be under AGPL, and be available in source
| code form to all my users/visitors?
| SAI_Peregrinus wrote:
| IANAL, but as I understand it:
|
| a) Yes, if Postgres is exposed to users for some reason. Your
| changes to Postgres are a derivative work of the original,
| and thus covered under the AGPL.
|
| b) No. Your application is not a derivative work of Postgres,
| any more than it's a derivative work of whatever OS you're
| using.
| darkwater wrote:
| Do you need to release as GPL the code of a program runnning
| on GNU/Linux? The answer is no. The same applies to software
| interacting with AGPL Postgres using the postgre protocol. If
| you are AWS and gives access to customers to modified
| versions of AGPL Postgresql you AWS must release your patches
| over Postgresql. IANAL and all that jazz, also I'm not that
| sure about the typical cloud vendor secret sauce that
| controls automation etc. Most of it it's probably external
| enough and not covered by AGPL but there might be some
| exceptions.
| SSLy wrote:
| 1) Yes 2) Nope
| eitland wrote:
| I've tried really hard to understand this a few times and
| yesterday or early today or something I found an interesting
| thread here: https://news.ycombinator.com/item?id=11354475
|
| reitanqild seems to misunderstand and the other posters fill
| in with more information.
|
| If the information in that thread is correct and I read it
| correctly it is totally fine to use an AGPL server that
| touches connects to a lot of stuff, it won't affect any of
| that.
|
| Only if you somehow touches the codebase of the AGPL licensed
| code by modifying it or creating a combined work then the
| AGPL will take effect in the same way as today - except that
| allowing access to a running instance over a network will
| trigger it too, not only distribution of the binaries or the
| code.
| Jarwain wrote:
| Would an extension like citus or timescaledb or opengis be
| considered a combined work for AGPL purposes?
| w4rh4wk5 wrote:
| Assuming a client has no direct access to the Postgres
| server, I'd say you neither need to publish your changes to
| Postgres, nor put the web application under AGPL. Just
| because your web application uses Postgres as a storage for
| data, in a way it could also just use SQLite or MariaDB
| instead, does not make it a "derivative work". #notalawyer
| janoc wrote:
| And you don't read what he wrote:
|
| "... and I modify it to my needs ..."
|
| So he has explicitly created derivative work of Postgres,
| that's not the question at all. The question is whether the
| conditions of the AGPL for distributing the source would
| trigger in his case. I would say yes but IANAL.
| w4rh4wk5 wrote:
| Just because I create a derivative work of an (A)GPL
| project does not immediately require me to publish those
| changes. Only if I distribute the work, I also need to
| distribute the changes along with it.
|
| While a derivative work of Postgres is created, it is not
| "distributed" (in the sense of the AGPL). The web
| application is, which I do not consider a derivative work
| of Postgres in the general case.
|
| If you implement a feature in Postgres and have a web
| application that is practically just a wrapper around
| this one, new feature, then that could be considered a
| derivative work. But I'd say that's a far stretch.
| edp wrote:
| IANAL
|
| a) postgres is not user facing, so no
|
| b) there is no linking (as in compiler linking) between your
| application and postgres, so no
| sneak wrote:
| I view the AGPL as a nonfree license; I think more permissive
| licenses are better, because I believe in software freedom.
| Companies are right to avoid the AGPL.
| LambdaComplex wrote:
| You believe in freedom for who, exactly? Freedom for the
| users of software? Or freedom for corporations who benefit
| from denying access to the source code of that software?
|
| The Free Software Foundation exists to protect the former at
| the expense of the latter.
| sneak wrote:
| You are dragging anti-corporate ideology into a very simple
| matter.
|
| Corporations are sometimes users, and individual people
| often benefit from denying access to the source code of
| software _that is used to provide a service_.
|
| Providing a service is fundamentally different from
| providing software.
| LambdaComplex wrote:
| > individual people often benefit from denying access to
| the source code of software that is used to provide a
| service
|
| To the detriment of the users of that service--which are
| the people that the FSF aims to protect.
| pvorb wrote:
| But if my proprietary SaaS only uses Grafana for monitoring but
| its key purpose is doing something else entirely, I can no
| longer use Grafana unless I also publish my SaaS under AGPLv3,
| right?
|
| What if I release my own SaaS as AGPLv3? Do others, who rely on
| it, also have to license their software under AGPLv3? I think
| this kills many business cases.
|
| Am I missing some key point?
| gpanders wrote:
| If you're only using Grafana for monitoring but not
| distributing it to your users as part of your product then I
| don't think you need to make your own product AGPL.
|
| I'm sure if I'm wrong I will find out very quickly, this is
| HN after all.
| HideousKojima wrote:
| >I can no longer use Grafana unless I also publish my SaaS
| under AGPLv3, right?
|
| If you link to it directly from your code then yes, unless
| you're willing to pay Grafana for a commercial license
| (assuming they offer one or you can negotiate one with them).
| If you have Grafana running on your servers but you aren't
| using the code in your own applications then you're generally
| fine (the GPL is generally recognized as ending where a
| process ends). And that's the point of the GPL/AGPL, you get
| the code for free, with the only expectation being that you
| pass it on if you make any changes.
| pvorb wrote:
| That was also my understanding of the GPL, but the AGPL is
| for me to understand.
| pavon wrote:
| The only difference between GPL3 and AGPL3 is what
| constitutes distribution. With GPL3 you have to provide
| source to anyone you provide binaries. With AGPL3 you
| also have to provide source to anyone who uses the
| software remotely (eg a web app). Everything else,
| including the scope of what must be included in the
| source (modifications, linked software, but not software
| that talks over IPC, etc), is identical between GPL3 and
| AGPL3.
|
| More specifically, the only difference between GPL and
| AGPL is section 13 (and the preamble summary). The rest
| of the license is word-for-word identical (save for the
| name).
| https://www.gnu.org/licenses/agpl-3.0.en.html#section13
| LukeShu wrote:
| To expand on that, you have to offer to provide the
| source to "all users interacting with it remotely through
| a computer network". If you're using Grafana for
| monitoring your SaaSS app, then your users aren't
| interacting with Grafana, so you're fine.
| pmontra wrote:
| If your server runs Linux you don't have to distribute
| the source code of Linux to the users of the services
| running on it. If Linux was AGPL you would have to. And
| yet, you would not have to distribute the source of your
| closed source software running on the server.
| neatze wrote:
| Can library be licensed under AGPL and class path exemption ?
|
| Seems like it will be better solution then MPL.
| renewiltord wrote:
| Is it still possible to integrate Grafana in your product or does
| the whole thing have to be AGPL. No complaints. Just curious.
| Like, can I distribute some SaaS that has a Dashboard section
| that is Grafana-powered while retaining my code?
| [deleted]
| crazypython wrote:
| Note that the AGPLv3 has an exception allowing you to link to
| GPLv3. GPLv3 allows for private use, in other words keeping
| changes secret as long as they stay on your own computer.
|
| In effect, it becomes a weak copyleft- akin to MPL-2.0 where as
| long as you keep it in separate files code can stay closed-
| source.
| bonetruck wrote:
| I wonder how many companies will choose to kill off Grafana use
| as a result of this change. Two companies I've worked for have
| simply banned the use of anything having a GPL type license.
| lolc wrote:
| Oh, no Linux at all then?
| natas wrote:
| only red star os allowed?
| saagarjha wrote:
| Red Star OS is Linux-based.
| belorn wrote:
| Out of curiosity, what kind of markets are those two companies
| in and how much competition exist.
|
| Using open source libraries is, among other things, a cost
| saving measure. It allows a company to focus their expertise on
| what they are good at, without having to spend time and
| resources on reinventing wheels. Banning tools that enable a
| company to produce products faster, cheaper and (sometimes)
| more stable and secure can have a major impact when the
| competition does not limit themselves in the same way. However
| if the market is dominated by a monopoly or is very slow, then
| increased costs and delays might not have much of an impact.
|
| As an example of such company, Google's revenue would not be
| impacted by a single percent if they suddenly needed to hire
| 200 more programmers for android. Delay next version with 2
| months and the impact for android market share would unlikely
| be statistically verifiable.
| wdb wrote:
| One of the reasons why I find it hard to contribute to projects
| that use CLA. Now you don't have any say in this relicensing even
| when contributed reasonable amount of code.
| josephcsible wrote:
| This has nothing to do with CLAs. The old license was Apache 2,
| which is compatible with AGPLv3 (although the converse is not
| true). You'd only need a CLA to relicense if it weren't
| compatible.
| damm wrote:
| Good. If Amazon wants to continue its creep of using open source
| software to build their empire they need to support the companies
| that make open source software.
|
| > If Amazon/AWS was not a large monopoly it wouldn't be a
| problem.
|
| DOJ Needs to split up AWS/Amazon and fine them and use that fine
| to create competition.
| BringerOfChaos wrote:
| Looks like there were two blog posts. This QA session with the
| CEO is also interesting. https://grafana.com/blog/2021/04/20/qa-
| with-our-ceo-on-relic...
| candiddevmike wrote:
| I can see why they would relicense Grafana this way, but why
| Loki? It's a fairly immature product that needs the boost of a
| less restrictive license IMO. I'm worried this will harm the
| adoption of it compared to the ES ecosystem (OpenSearch in
| particular) and we won't see it used for anything beyond Grafana.
| dvfjsdhgfv wrote:
| Popularity can increase rapidly, and if they do it too late,
| Amazon will screw them just like they did with Elastic.
| josephcsible wrote:
| I wish people would stop equating what Grafana did with what
| Elastic did. Grafana switched from one FOSS license to
| another. Elastic switched from a FOSS license to a
| proprietary license.
| sojsurf wrote:
| Counter opinion:
|
| I don't want to host Elasticsearch myself, which is why I pay
| Elastic to host several clusters. That said, I really don't
| want to be locked into a single-vendor situation, which is
| what Elastic is realistically aiming for. I am 100% glad that
| Amazon forked ES, because it preserves the benefits of using
| an open source stack. I still have a choice of hosted
| providers. In my opinion, the amazon fork is much more likely
| to lead to a healthy ecosystem of hosted ES providers than
| the Elasticsearch version.
| ltbarcly3 wrote:
| I remember when the AGPL was being talked about in around 2008 or
| so, and thinking it was ludicrous. Now I wonder if it's too
| lenient. AWS is just rebranding open source products and selling
| access for infinite markups while killing the open economy that
| created them.
|
| Maybe what we need is a 'no AWS' license, think Apache License
| but with a clause that says no corporation with more than $50B in
| revenue can resell it.
| josephcsible wrote:
| > I remember when the AGPL was being talked about in around
| 2008 or so, and thinking it was ludicrous. Now I wonder if it's
| too lenient.
|
| It'd be really hard to come up with a license less lenient than
| AGPL without it being non-FOSS, which would defeat the purpose.
|
| > Maybe what we need is a 'no AWS' license, think Apache
| License but with a clause that says no corporation with more
| than $50B in revenue can resell it.
|
| This would be a blatant violation of freedom 0.
| nrmitchi wrote:
| Is that not essentially what the Server Side Public License
| (SSPL) went for?
| retzkek wrote:
| I mean, good for them? If they're "just rebranding and selling
| access for infinite markup" then surely the only people who
| would pay them are either too lazy or too busy to host it
| themselves, or too rich to care?
|
| Would you prefer that people/companies that fall into these
| categories be forced to go through some _other_ reseller (who
| is just adding their own markup on top of the cloud hosting
| costs) instead of getting the service directly from their cloud
| provider of choice?
| asim wrote:
| All of the most important software of our lifetime is going
| through this relicensing effort as the creators attempt to
| capture the value of what it enables. This is not some nefarious
| plan to screw over the community. It's a very measured and
| thoughtful way to ensure the long term progress and continuity of
| these projects. If the core companies maintaining them did not do
| this they would eventually die and these projects would slowly
| rot. Hopefully over time rather than having everyone choose their
| own licenses we end up with some form of standardisation.
| throwaway823882 wrote:
| > If the core companies maintaining them did not do this they
| would eventually die
|
| Good riddance. Incumbents owned by corporations have too much
| control and prevent replacement projects from arising. When a
| community builds a solution, how it works is dictated by its
| users and developers, not profits.
| echelon wrote:
| If they don't, Amazon will gobble them up.
|
| This is a good thing.
|
| Linux being GPL 2 was great for computing when we had thick
| clients, but now everything is moving to the cloud. Companies
| can innovate on top of it and not really give back.
| 29athrowaway wrote:
| And each one of them will be forked by the major companies that
| were supposed to pay.
| judofyr wrote:
| > All of the most important software of our lifetime is going
| through this relicensing effort as the _creators_ attempt to
| capture the value of what it enables. [...] It 's a very
| measured and thoughtful way to ensure the long term progress
| and continuity of these projects.
|
| _Ahem:_ Grafana Labs Brings In $50M Series B For Open-Source
| Developer Platform: https://news.crunchbase.com/news/grafana-
| labs-brings-in-50m-...
|
| I completely support the right to chose your own license and
| how you want to sell and use your own code, but let's be honest
| here. This is done because investors have discovered that it's
| possible to earn money on services around Open Source products,
| and Grafana Labs has gone all-in on this approach. Now they
| need the relicensing in order for the business model to remain
| viable. We're lucky that the code remains AGPL, but notice that
| they are still not committed to ensuring that all the code will
| _remain_ AGPL (i.e. they still want CLA so they can relicense
| later).
| nopzor wrote:
| do you think that earning money or having a viable business
| model is a bad thing?
|
| look at our actions since the inception of the company, as
| well as our "big tent" philosophy; i think they speak for
| ourselves.
|
| we built a sustainable business over the course of 4 years,
| prior to raising a dollar of VC money. we raised VC money to
| go even faster.
|
| most of our VC money goes to paying our employees.
|
| most of our employees are engineers.
|
| most of what our engineers do is open source.
|
| if we don't build a sustainable business, who will develop
| the software?
|
| the overwhelming majority of development on things like
| grafana, loki, tempo are done by grafana labs employees.
| plus, we are the main contributors behind other OSS projects
| that we didn't create and don't own (like prometheus and
| cortex).
|
| [note: am co-founder/ceo at grafana labs]
| andrewstuart2 wrote:
| Neither earning money nor having a viable business model
| are bad things, but that's about as straw as a strawman
| argument comes. A business model existed before these
| changes. As far as I can tell, though, it's not _captured_
| the value that the founders and investors seem to think
| ought to be their wealth.
|
| Grafana Labs and all these other companies have recieved
| both value add and goodwill free marketing from open source
| contributions and communities, and I don't see these
| companies being at all interested in figuring out who/what
| they've gained value from, beyond the currently existing
| company, in order to make a profit and benefit the founders
| and shareholders.
|
| I'm not against AGPL. I'm against the relicensing of
| software made in good faith against one model of OSS being
| discontinued and basically forked by the most prominent
| for-profit company that have hitherto received the
| significant benefits of both contributions and goodwill
| that being more freely open source brings.
|
| By relicensing you've probably significantly reduced the
| number of companies willing to run future versions of your
| software, and the number of companies willing to build
| businesses off of extending it and offering that value add,
| while still potentially contributing changes upstream.
| You're going to slowly eat away at that good will and the
| number of people asking for your product internally, since
| fewer and fewer people will remember the benefit from their
| last gig.
|
| I could be wrong here, only time will tell, but I honestly
| don't think this is a move that increases the long term
| sustainability of your business model. If anything, I think
| it's going to be detrimental in the long term. Perhaps even
| in the short term.
| tshaddox wrote:
| > do you think that earning money or having a viable
| business model is a bad thing?
|
| Nope, but I kinda thought the whole idea behind open source
| is that no one company or group of companies/licensees gets
| privileged access to or control over the software,
| including any company that happens to have the same name as
| the piece of software.
|
| I realize that "open source" and "free software" and other
| related labels mean many things to many people, and some
| people have very strong opinions about what does and
| doesn't qualify, so I'm not trying to be prescriptive about
| what these terms "really" mean, but to me this is a pretty
| important almost self-evident part of it. If you want to
| sell proprietary software just do that!
| ankmathur96 wrote:
| I don't believe this is a realistic take on open-source.
| There's not a single successful modern OSS project that's
| not basically controlled by a single organization (or was
| not at some point in its conception). Control can take
| multiple forms: most of the time, it's directional to the
| project, since the roadmap of the company managing the
| project dictates what gets done. Sometimes, it's in the
| form of how you can use the project. The great thing is
| that you can always fork the project and create a version
| for which the new rules/direction does not apply. The
| challenging part is making that a project where active
| development is actually happening.
|
| Certainly, there's things like the Linux Foundation that
| serve as places where projects can live without formal
| control by a single organization, but in practice, orgs
| that commit most of the code control things (for better
| or for worse - I'm not saying this is a good thing)
| tshaddox wrote:
| > I don't believe this is a realistic take on open-
| source. ... The challenging part is making that a project
| where active development is actually happening.
|
| Well, yeah, that's just the most obvious gut reaction
| everyone has when they first hear about open source
| software: Why in the world would anyone put work into
| software that's free for everyone to use? My impression
| is that open source advocates have put tons of work into
| explaining why this can and does actually work and can
| result in software that's _better_ than proprietary
| alternatives.
| yawaramin wrote:
| > I kinda thought the whole idea behind open source is
| that no one company or group of companies/licensees gets
| privileged access to or control over the software,
| including any company that happens to have the same name
| as the piece of software.
|
| That is not, at all, the idea behind open source. The
| idea behind open source is, basically, 'you are free to
| do whatever you like with the source code, as long as you
| credit us for our work and don't hold us responsible for
| any effects of using the work'. That's it. There is
| nothing about companies, corporations, licensees, who has
| control, who has what name, etc. All of that is
| irrelevant to open source at its core.
|
| It's true that many people add on an open governance
| model (e.g. Rust) and mistakenly think that that is part
| of open source. It's not though.
| tshaddox wrote:
| > There is nothing about companies, corporations,
| licensees, who has control, who has what name, etc.
|
| That's exactly what I said.
| DetroitThrow wrote:
| I'm glad you were able to find a FOSS license that's able
| to support your business. I think grafana lab's use of AGPL
| will help encourage its adoption by other businesses
| wanting to make money in free software as well.
|
| For other's who are interested, here's a faq from grafana
| including a discussion about "Why AGPL and not SSPL?":
| https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-
| relic...
| xbar wrote:
| Very much this.
|
| As a commercial consumer of FOSS, AGPL has been troubling
| for me. As a non-commercial hacker, AGPL has been fine
| for me: GPL is fine here, and distribution as defined by
| SaaS or tarball is equivalent; I share back.
|
| My opinions are that non-commercial FOSS projects
| probably shouldn't choose AGPL but that small-ish
| commercial FOSS projects (like Grafana, et al) probably
| should so that big commercial entities don't eat their
| lunch.
|
| AGPL seemed like a tool that was mostly ahead of its time
| but is nice to have now.
| mqus wrote:
| I agree.
|
| AGPL is nice and all but for contributors this does not
| really matter at all because of the CLAs.
|
| I will never contribute to projects which reserve the right
| to relicense, e.g. take ownership over my contributions,
| however small or big they are. I think companies will do the
| same.
|
| If they would remove the CLAs, they would signal to companies
| and contributors that they are serious in providing an open
| ecosystem, to which other people contribute willingly "for
| free". But currently they are not, likely because they fear
| competition.
| nopzor wrote:
| thanks for saying the AGPL is nice; we think it strikes the
| right balance.
|
| but, i'm curious to understand your perspective here.
|
| do you mean to say that you'd never contribute to an apache
| licensed project?
|
| anything that is apache licensed can be relicensed by the
| project, even if there isn't a CLA
|
| [note: am co-founder/ceo at grafana labs]
| SuperQue wrote:
| The problem is CLAs.
|
| They are a much higher barrier to entry for a lot of
| contributors. No, they're not all the same, but they make
| it harder. Each CLA needs to be reviewed and approved by
| company lawyers. It's kinda like creating a brand new OSS
| license that way.
|
| To use a concrete example, the Google open source CLA is
| awful. At my previous job our lawyers refused to sign off
| the Google CLA. One of my engineers wrote a patch that we
| wanted to get upstream. Since, it would be generally
| useful.
|
| Basically, the patch could never be merged, because we
| had a legal stalemate between us and Google.
|
| I would highly recommend using
| https://developercertificate.org/ instead. This is what
| we use for Prometheus. It's also used for GPL projects
| like Linux. It's simple, standard, and used widely.
| shawnz wrote:
| I think they are saying that they don't want to give the
| project owner permission to relicense their contributions
| to an incompatible license. Relicensing to a compatible
| license should be no problem.
| staticassertion wrote:
| > Now they need the relicensing in order for the business
| model to remain viable.
|
| This is exactly what the parent is saying though. They're
| going through this process to ensure that their business
| remains viable and they can continue to build and support the
| project.
| judofyr wrote:
| I still think this sentence here is not quite precise
| enough:
|
| > All of the most important software of our lifetime is
| going through this relicensing effort as the creators
| attempt to capture the value of what it enables.
|
| To me this sounds like the relicensing is done so that a
| few programmers _finally_ can get paid for their hard labor
| while maintaining critical software we 're all using.
| What's _actually_ happening here is that some creators have
| convinced a few investors that they 'll be able to give a
| huge return on invest by building up a sales department
| around the product. And now the realize that they're not
| able to accomplishing that with their original license.
|
| It's a perfectly acceptable _business_ strategy, but it 's
| not necessarily the _only_ way of running an open source
| project.
|
| I'm still hoping that we (the open source community) can
| find even better ways of ensuring high-quality software
| remain open source without being so dependent on current
| mindset of investors.
| [deleted]
| yjftsjthsd-h wrote:
| > Hopefully over time rather than having everyone choose their
| own licenses we end up with some form of standardisation.
|
| Yes; if you're going to do this, then using AGPL is _so_ much
| better than flavor-of-the-week license.
|
| > If the core companies maintaining them did not do this they
| would eventually die and these projects would slowly rot.
|
| It sounds like you're suggesting that anything but hard-
| copyleft is doomed to die out, which is a somewhat hard
| argument to make in a world with lots of counterexamples
| (postgres, the assorted BSD OSs, kubernetes, Android).
| bostik wrote:
| Your choice of counterexamples highlights an important
| aspect. Three of the four are in fact outliers: Kubernetes
| and Android are both financially backed by Google. Android as
| a strategic advantage across a global market, Kubernetes as a
| plumbing layer enabling more businesses operate logically
| _like_ Google. Sure, it 's a CNCF product since 2016 or so,
| but it still enjoys Google's backing.
|
| Postgres? They have a very specific governance model - a
| single company can not employ over 50% of the core
| contributors, to guarantee that the direction of the product
| is not taken over even by accident.
| dcow wrote:
| Also, the CNCF _is_ essentially Google by another name.
| streetcat1 wrote:
| Far from it. looks what happen with istio.
| caniszczyk wrote:
| that for sure is false... Google helped start CNCF but
| now plays a small part in its governance, they are just
| one board member like the 30+ others... they have no
| special voting rights...
|
| https://www.cncf.io/people/governing-board/
|
| they still do quite a lot of heavy lifting though in
| contributing to a variety of CNCF projects if you look at
| the numbers: https://all.devstats.cncf.io/d/5/companies-
| table?orgId=1
| yawaramin wrote:
| What happens to CNCF if Google backs out of it tomorrow?
| Including all funding?
| wmf wrote:
| Governance won't help if you have no contributors at all
| because there's no revenue coming in.
| lacker wrote:
| _Three of the four are in fact outliers: Kubernetes and
| Android are both financially backed by Google._
|
| Is that really "outlier" behavior? More and more important
| open source projects are prominently backed by a single
| large tech company. React, TensorFlow, TypeScript, Go, etc.
|
| If you just look at the last decade, there has been more
| important work done as "single-sponsor open source" than
| under the GPL.
| bostik wrote:
| While I want to disagree with you on the general
| principle (and gen220's sibling comment points out
| several really nice longer-term examples), I will
| certainly admit that you have a point. Cloud providers
| eating the margins, investing in streamlined operations
| and in general making the earlier on-prem consulting work
| less attractive has had an effect.
|
| But I do note that your examples are from quite a narrow
| sector. TypeScript, Go and React are all languages.
| TypeScript is a nice facade over JavaScript, and React is
| ... well, a very powerful DSL.[ss] Go is very much a
| Google project, developed perhaps more out in the open
| than in a traditional open-source sense.
|
| As I understand, TensorFlow was originally an internal
| Google project, which they at some point decided to open
| up. It may have had something to do with their TPU cloud
| offering or not. If we wanted to compare low-level
| language or domain material, we should probably take a
| look at something like Boost. People who do C++ tell me
| that Boost is a pretty good approximation of C++
| standards' evolutionary playground. And if we're going
| for new languages, shouldn't we also include Rust? It was
| backed and promoted by Mozilla, but how much of its
| development was driven _solely_ by Mozilla, and how much
| was done by the interested community at large?
|
| ss: Our frontend team will probably want to roast me for
| that one, but there isn't much visible JS left in modern
| React code. Not for my eyes, at least.
| reader_mode wrote:
| Replace React with angular, replace Go with .NET which is
| a platform, and it's not just the language entire stacks
| in .NET are available as OSS (fronted, backend,
| distributed computing).
| ctvo wrote:
| > But I do note that your examples are from quite a
| narrow sector. TypeScript, Go and React are all
| languages. TypeScript is a nice facade over JavaScript,
| and React is ... well, a very powerful DSL.[ss]
|
| > ss: Our frontend team will probably want to roast me
| for that one, but there isn't much visible JS left in
| modern React code. Not for my eyes, at least.
|
| Can you clarify what you're talking about here with
| regards to React? I can see calling JSX a DSL, but React
| is a language now? And there's no JS / TypeScript in your
| React code base?
| TeMPOraL wrote:
| > _but React is a language now?_
|
| In a way, it is. Whenever you write some module in your
| project, you're effectively designing a language. Every
| function you add is a new verb, every type you define is
| a new noun[0] - and the relationships between them form
| the grammar. It may sound trivial, but I think it's an
| important and underappreciated point. Modularizing and
| abstracting is done by building languages on top of other
| languages.
|
| We usually make a distinction between what is a "library"
| or "module" and what is a "language", by... it's hard to
| capture the distinction exactly, but my guess is that we
| reserve the term "programming language" for languages
| that a) define a large, highly composable set of building
| blocks, and b) have complex translation into a lower-
| level language, ultimately yielding executable code.
| Whatever the distinction could be, in reality, it's a
| spectrum.
|
| --
|
| [0] - Well, a piece of a noun phrase. Maybe. I'm not a
| linguist.
| yawaramin wrote:
| That's not what was asked. The query was, 'Is _React_ a
| language now ', i.e. specifically React, not just a
| general query like 'In general, is programming a process
| of designing little custom languages to solve problems'.
| TeMPOraL wrote:
| So to answer explicitly: in many ways, yes it is.
| twic wrote:
| You get it. Making lots of money cannot be a result of
| open source. But open source can be a result of making
| lots of money.
|
| The ultimate fate of the wave of companies switching to
| AGPL and similar licenses now will be the proof (or
| disproof!) of this.
| cryptonector wrote:
| Sometimes open source helps. SQLite3 is a good example.
| Being open source (and very good) helped it become one of
| the -if not the- single most-used pieces of software in
| the world, but having a closed-source 100% branch
| coverage test suite helped establish a monopoly on
| development of SQLite3 and prevented hard forks. End
| result: big tech had to sign up for the SQLite
| Consortium. It's... not a unicorn, and I've not idea how
| much D. R. Hipp and friends get paid -- certainly they
| get paid enough to continue doing their awesome work, and
| maybe they get paid like the rock stars that they are,
| but probably nothing like what they'd be worth if they
| could really monetize SQLite3 and IPO. The SQLite devs
| are probably very happy, is my guess.
|
| But yes, on the whole it's true: most open source
| projects aren't SQLite, and most aren't going to many any
| money just because they are open source. Open source is a
| business tool.
| mikepurvis wrote:
| So TypeScript is Microsoft, and React is Facebook, but
| all the rest of those are Google. Shouldn't we be a bit
| concerned about that?
|
| Like, it seems like it _should_ be fine, given that
| TensorFlow is part of their core AI mission, and they 're
| heavily invested in Go, and Android probably isn't going
| anywhere. But people once thought that Java and MySQL
| were safe in the hands of Sun, too.
| cardanome wrote:
| A few monopolistic corporations having dictatorial power
| over key technologies is a dystopian nightmare.
|
| Those projects have ultimately the interests of the
| corporations in mind not of the users.
|
| Ever wonder why overcomplicated technical solutions are
| hyped so much? Why does everyone and their dog need to
| run Kubernetes? Why is it all Maschine Learning instead
| of good old fashioned methods that would do much better?
| Well those corporation have just the fitting cloud
| computing offering!
|
| Sure many of them happen to be useful and are simply for
| increasing the prestige of the company but let's not act
| like it is a good thing.
| nkassis wrote:
| > "Ever wonder why overcomplicated technical solutions
| are hyped so much? Why does everyone and their dog need
| to run Kubernetes? Why is it all Maschine Learning
| instead of good old fashioned methods that would do much
| better? Well those corporation have just the fitting
| cloud computing offering! "
|
| Simpler explanation than some nefarious plan. Software
| engineers love to play with the coolest new thing over
| working with some proven solution that might have worked
| well enough. I think these corporation just exploit that
| with cloud offering. They don't really get to pick what
| people like (they try but suck at it) but have the money
| and resources to exploit whatever ends up being the
| popular new thing anyway.
| JackFr wrote:
| > A few monopolistic corporations having dictatorial
| power over key technologies is a dystopian nightmare.
|
| I think "dystopian nightmare" overstates it. Monopoly
| control over particular technology is also a working
| definition of the the patent system. Hey, wait a minute
| ...
| MayeulC wrote:
| > _A few monopolistic corporations having dictatorial
| power over key technologies is a dystopian nightmare._
|
| These corporations are eating the world. They need not
| keep their source code closed, we're all employees,
| generating revenue for them.
|
| One of the only reasons to keep source code closed is to
| retain your competitive advantage. They need not that
| when there's no competition, or a very slim chance of
| some appearing one day.
|
| I'm joking, but it sounds a bit more true than I
| expected. Also, mind you, I'd rather have them publish
| code than not.
| ethbr0 wrote:
| If we want to bark up this tree, a larger problem is
| FAANG inventing technologies that assume you have
| _equivalent baseline competency and maturity_.
|
| Which leads to companies that do not (eg no CICD or data
| architecture standard) adopting tools that assume they do
| (k8s & tensorflow).
|
| (And yes, I realize this is because most folks who work
| at the former aspire to jump ship to the latter)
|
| Say what you want about Microsoft, but they do a much
| better job of meeting the customer where they are
| (dumpster fire) instead of where Microsoft is.
| api wrote:
| Problem: the letters "G, P, L" are toxic to a huge number of
| companies. This has nothing to do with the controversy around
| Stallman. It's because Microsoft spent over a billion dollars
| in the 1990s mis-educating the market that GPL software is
| "viral" and if present can "infect" non-GPL software with the
| GPL license.
|
| The problem would go away if you renamed the license to
| something else. It's that stupid.
|
| A lot of the flavor of the week licenses exist for this
| reason, as well as to address some of the weak corner cases
| of the AGPL.
| dkarras wrote:
| Curious about how the GPL is not viral... Unless you go
| through the hoops of making sure GPL code is sectioned
| (through a shared library or whatever) in your codebase,
| then your software becomes GPL, no? I mean sometimes you
| can avoid it so that the GPL project stands at an arms
| length to your own code but it is not always trivial. You
| just don't get to include the code in your project and not
| get "infected". The fact that you can sometimes circumvent
| the infection does not mean it is not viral because I
| believe it violates the "spirit" of the license anyways.
| simion314 wrote:
| I think you are wrong here, if I have 2 files, first is
| GPL and the second is proprietary and you steal them from
| me and use them then what license is your code now ?
|
| The correct answer is that your code stealing is not
| transforming the product into GPL or into my proprietary
| license. If I catch and ask for money from you you have
| more options with the GPL code then with my proprietary
| code. With the GPL code you can just GPL your code
| changes, maybe the entire product but you are not forced
| to pay me anything. With the proprietary license though
| you don't have the option and I can make you pay.
|
| So if you like that much the "infectious" word, you
| should add an "optional" modifier , you can always not
| GPL your changes, remove the "stolen" code , pay damages?
| (not sure if this ever happened).
|
| What I observer the issues with GPL like software is lazy
| developers and companies that would like to "npm install"
| solutions and skip doing the work.
| __david__ wrote:
| Your software never "becomes" GPL, no matter what. That's
| the problem with the "viral" label, it's somewhat of a
| misnomer that implies that anything that comes into
| contact with it gets infected and suddenly all your
| private IP _has_ to be released and anyone can just take
| it an fork it.
|
| In reality, your proprietary code can only be GPLed if
| you explicitly release it under that license.
|
| What people are confusing is that it is a violation of
| the GPL to release binary code that links (statically or
| dynamically[1]) with GPL-ed code without also releasing
| that code under a compatible license. This is where the
| "viral" label comes into play, since the easiest way to
| link against GPL code is to just make your code GPL as
| well. But it _does not_ mean that if you mess up and
| release a binary blob with GPL code in it that you've
| given up all rights to the non-GPL parts.
|
| [1] LGPL allows dynamic linking, plain GPL doesn't
| distinguish.
| slabity wrote:
| > A lot of the flavor of the week licenses exist for this
| reason, as well as to address some of the weak corner cases
| of the AGPL.
|
| I'm interested in what the 'weak corner cases' of AGPL are
| considering it was pretty much made to correct some
| weaknesses in the GPL.
| api wrote:
| It doesn't adequately handle the SaaSification case,
| which is when someone hosts the software behind a
| paywall. It only handles the "Tivoization" case when
| someone ships the software inside a closed source box.
| kelnos wrote:
| Are you sure? AGPL was written expressly to deal with
| SaaSification. Wikipedia seems to agree with me, at
| least[0]:
|
| "Both versions of the Affero GPL were designed to close a
| perceived application service provider (ASP) loophole in
| the ordinary GPL, where, by using but not distributing
| the software, the copyleft provisions are not triggered.
| Each version differs from the version of the GNU GPL on
| which it is based in having an added provision addressing
| use of software over a computer network. This provision
| requires that the full source code be made available to
| any network user of the AGPL-licensed work, typically a
| web application."
|
| The non-Affero GPLv3 handles Tivoization, FWIW.
|
| [0]: https://en.wikipedia.org/wiki/Affero_General_Public_
| License
| SXX wrote:
| GPLv3 also added patent grant which is super important if
| you deal with software built by corporations.
| slabity wrote:
| Isn't the purpose of GPLv3 to handle Tivoization and AGPL
| was made to handle server-side sort of use-cases?
|
| If I use AGPL-licensed software in a SaaS type of
| environment, I still need to release the source-code even
| if I'm not distributing the software directly, correct?
| pmontra wrote:
| Correct.
| vinceguidry wrote:
| > Problem: the letters "G, P, L" are toxic to a huge number
| of companies.
|
| Too. Effing. Bad. These companies can either figure out how
| to work with FSF-authored licenses or they can go make
| their own alternatives. I have no sympathy for them.
|
| Or for devs that make excuses for this attitude. They
| deserve to be force-pushed onto software like when Apple
| decided to ship zsh instead of bash because they didn't
| want GPLv3 in their OS. Or that whole Rails brouhaha last
| month.
|
| Companies should not be trusted with permissively licensed
| software. You don't get to play shell games with public
| access.
| skipants wrote:
| GPL is "toxic" to the companies I work at because using
| GPL-licensed code would force them to disclose the source
| of their proprietary software.
|
| There's not much else to it.
| [deleted]
| sokoloff wrote:
| The GPL is neither long nor complex. If a company won't use
| GPL software because of Microsoft's efforts, but would use
| that software under an identical license called something
| else, I think that company will experience many other
| difficulties on their journey as well.
|
| For shrink-wrap software, GPL can be an issue. For hosted
| software, it's generally not (which is why all the desire
| to make other licenses, including AGPL).
| matkoniecz wrote:
| > Problem: the letters "G, P, L" are toxic to a huge number
| of companies.
|
| Even if true, why it is problem? Company so misinformed is
| not going to be helpful anyway.
| rover0 wrote:
| It does not stop all those companies using linux. The Jeff
| Bezos days are over.
| nine_k wrote:
| Postgres looks like the only interesting entry here.
|
| K8s and Android have a major corporation backing them, which
| extracts value from them in its internal operation anyway.
| They are such products that using them by competition
| commoditizes said competition. Android on like 95% of phones
| outside China has very important proprietary parts, making it
| hardly compatible with a bunch of top-tier apps.
|
| BSD OSes don't do excessively well, with regard to market
| share and mind share. They are reasonably healthy though.
| atat7024 wrote:
| "What people want" is not what I want.
|
| Market share/mindshare is almost an inverse measure of
| quality at this point!
| dec0dedab0de wrote:
| _Market share /mindshare is almost an inverse measure of
| quality at this point!_
|
| If you only compare things above a certain quality
| threshold, That's true of any creative endeavor. Not too
| many people will say that Mcdonald's has the best
| burgers, or the pop singer of the week is their absolute
| favorite.
| whimsicalism wrote:
| This is what might be described as the 'hipster'
| sentiment distilled to its base axiom.
|
| Not necessarily knocking it, though!
| topaz0 wrote:
| It's only hipster sentiment if it is on principle ("this
| is popular -> I don't want it"). It sounds to me like
| just an observation in this case ("it so happens that the
| most popular things are the ones I want least"). The
| "almost" clarifies this.
| gen220 wrote:
| SQLite, Vim/Emacs, Linux, everything in GNU coreutils.
|
| All of the Apache projects (some to more/less an extant
| than others).
|
| Most programming language implementations (e.g. CPython).
| Memcached. WireGuard. SQLAlchemy. Web Frameworks like
| Flask, Django, Rails, on and on.
|
| There are many open source technologies that do not seek to
| capture the value they create with licensing hijinks.
|
| I don't think it's an accident, that the ones that persist
| across generations are generally not structured as VC-
| backed firms, who care a great deal more about "value
| capture" than the average programmer capable of building
| such foundational systems. Usually "value capture" is
| correlated with "consumer harm", and so they're replaced
| over time.
|
| From your example, K8s will definitely outlive Google. Hard
| to say about Android.
| nine_k wrote:
| I did not mean to say that open-source software (broadly,
| MIT-licensed) and free software (broadly, GPL-licensed)
| don't do well! They do, and I'm happy about it. Some have
| commercial entities around them, but most don't.
|
| What I was trying to say is that FOSS was never about
| capturing commercial value, and always about capturing
| the value of the freedom to inspect, share, and tweak.
|
| In this regard, going AGPL is preferable to what Mongo or
| Elastic did. They basically turned to commercial "source-
| available" offerings, much like mainframe software from
| 1970s.
| bostonvaulter2 wrote:
| > I did not mean to say that open-source software
| (broadly, MIT-licensed) and free software (broadly, GPL-
| licensed)
|
| Sorry, but free software IS open-source software. I take
| issue with how you're presenting these. Perhaps a better
| term would be liberally licensed software, as opposed to
| copyleft.
| nine_k wrote:
| Agreed; one is a subset of the other. I tried to say
| something like "open-source in general, and its more
| strictly licensed copyleft subset,..".
| gen220 wrote:
| Ah yeah! We totally agree! I was finding it hard to
| respond to your comment initially because I didn't know
| which point you were trying to make, mentioning Android
| and K8s.
|
| I totally agree that the "we are now AGPL" route is
| preferable.
|
| FWIW MongoDB was already AGPL, but that wasn't enough for
| them I guess, they wanted more money. Old HN thread on
| the topic: https://news.ycombinator.com/item?id=18229452
| gqewogpdqa wrote:
| Why the toxicity? AGPL was deemed by many to not be clear
| about what it was trying to accomplish. As I read in the
| various exchanges and articles around the time SSPL came
| out, I think they were just trying to clarify AGPL, not
| getting any more restrictive than AGPLs intent. And how
| would moving from a license that said you couldn't run a
| service bureau for free to something that says more
| clearly that you can't run a service bureau for free make
| MongoDB more money?
| Dylan16807 wrote:
| > From your example, K8s will definitely outlive Google.
| Hard to say about Android.
|
| What leads you to say that? I wouldn't be surprised if
| kubernetes is dead in 20 years. I would be very surprised
| if google is dead in 20 years.
| BoysenberryPi wrote:
| Frankly I'd be surprised if Kubernetes wasn't dead in 20
| years.
| ethbr0 wrote:
| Imho, K8s eventually evolves into an OS for running K8s,
| then gets productized on {non-x86-64}
| edoceo wrote:
| not looking forward to the k8s-arm-soc enabled bootloader
| (tightly integrated to systemd of course) to run k8s-os
| to run k8s-system to run docker.
| gen220 wrote:
| It's just my opinion and I'll be happy to be wrong
| (because it means something better will have supplanted
| it).
|
| But I don't think there's a significantly-simpler, mature
| abstraction for doing container orchestration, than K8s.
|
| K8s' main advantage/stickiness factor, is how abstract
| and modular it is. It's an opinionated Kernel that gets
| most things right and has a huge ecosystem of tools built
| around this kernel.
|
| It has a very similar set of stickiness factors to Linux,
| imo, although the origin story couldn't be more different
| of course.
|
| I think if anything replaces K8s, it'll take a Linux-like
| shape. But K8s gets enough things correct (licensing,
| api, modularity) that it'll be hard to replace it
| wholesale.
| valyala wrote:
| I fully support this statement. I'm core developer of
| open-source monitoring solution - VictoriaMetrics [1]. It
| is licensed under Apache 2 and we have no plans to change
| the license, since it may complicate user experience.
| VictoriaMetrics makes "value capture" by more future-
| proof means:
|
| * By providing easy-to-setup-and-operate solution
|
| * By focusing on the performance and minimal resource
| usage
|
| * By providing good integration with other monitoring
| solutions
|
| [1] https://github.com/VictoriaMetrics/VictoriaMetrics
| yarcob wrote:
| Well, OpenSSH for example is an OpenBSD project, so it's
| not like nobody uses their stuff.
| nine_k wrote:
| Everybody does! Some likely even publicly deploy modified
| versions without upstreaming them. But the authors don't
| mind, and don't ask for payment.
| soenkeliebau wrote:
| >Yes; if you're going to do this, then using AGPL is so much
| better than flavor-of-the-week license.
|
| I'm not sure I agree. Yes, standardization is a good thing
| and AGPL is the "known evil", but having read it I do think
| that it is a very very complex piece of text - personally I'd
| go so far as to say that it is close to incomprehensible and
| would prefer pretty much anything else.
|
| But even aside from that the sheer number of companies that
| point blank ban AGPL licensed software from being used in
| their stack could be used as an indicator as well. Though
| this may be due to the common misunderstanding that it is a
| viral license, which just goes back to my prior point on it
| not being clearly worded.
|
| I won't even mention alternatives, I'm sure they all have
| issues, it is a complex topic, but if it were up to me the
| AGPL would not be my first license choice.
| platz wrote:
| If companies want to ban AGPL, well that's their
| perogative.
|
| Alternatively, catering to those companies wouldn't bring
| relevant benefits to the project anyway
| soenkeliebau wrote:
| Arguably selling support/services to a company using that
| product would help pay for developers that work on the
| product, which to me sounds like a benefit.
|
| With the AGPL that would require dual licensing, and that
| draws flak as well.
|
| I think the notion that OSS means there cannot be any
| money involved simply cannot hold true anymore these
| days. Software has become extremely complex and requires
| dedicated developers working on it - and they need to
| eat.
|
| We are currently seeing a lot of companies changing their
| licensing model for a reason - because there is not
| currently a middle ground between OSS and a working
| business modell that the OSS crowd doesn't hate.
|
| That being said, I'd love to be proven wrong here!
| viraptor wrote:
| There are corps which have a (close to) blanket ban on
| AGPL, but still submit patches to open source projects.
| HP would be one of them.
|
| I don't think it's a big loss though.
| yjftsjthsd-h wrote:
| The question is whether the alternatives are any better;
| IMO, this is unlikely (all the others I've seen make
| tradeoffs that I'd consider poor, personally).
|
| I think the virality and companies not liking it is the
| license working as intended, honestly; it's _supposed_ to
| be viral, that 's the _point_ of copyleft, and obviously
| companies take issue with that (although I agree that some
| of this might be misunderstanding scope / what it
| infects), but that's not a bug, it's the license doing its
| job and companies making decisions based on that.
| soenkeliebau wrote:
| My personal opinion (and it is really just that - I
| cannot prove anything I say here) is that for a lot of
| those companies it is actually the risk of not being able
| to tell exactly what the AGPL would affect that is the
| main factor.
|
| As I said, I'm explicitly not mentioning any alternative
| here because they all have issues, but the AGPL's wording
| is much more complicated than most and that (perceived)
| insecurity around it is my main criticism.
| cryptonector wrote:
| Open source is a business tool. There are many business
| models where open source can be useful. PG has such a vibrant
| user _and_ developer community that it pays to be a
| freelancer in that community and there's room for lots to
| play. SQLite3 is very much the opposite: it has _no_
| developer community outside the core team, but the business
| model is the SQLite Consortium, which pays for the core team,
| and the closed-source test suite whose existence prevents
| hard forks.
|
| It makes sense to use attractive-to-end-users licensing at
| first and later switch to a license that helps lock in
| support bucks. Call it bait-n-switch if you like, but even
| the SQLite folks did it, only they didn't do it with the
| _license_ but with the _test suite_ -- either way they made
| it really difficult to play in their space and/or fork.
| swyx wrote:
| > using AGPL is so much better than flavor-of-the-week
| license
|
| license noob here - can you elaborate on why exactly it is so
| much better?
| supercheetah wrote:
| It closes the server loophole in which companies will use
| and modify Free software they're using just on their
| servers, but never make those changes available to clients,
| which is not restricted by just the regular GPL.
| johannes1234321 wrote:
| AGPL is a license qualifying the criteria of OSI's
| OpenSource definition and FSF's Free Software definition.
|
| A key point there is that a user can use the software quite
| freely without restrictions only with the caveat that
| modifications have to be made available to users. (AGPL is
| slighqtly more complex)
|
| Many of the "modern" licenses allow to look at code, but
| prevent distribution and/or modification and/or usage. They
| typically aim for any "proper" usage requiring a commercial
| license and not giving the guarantee that code can be fixed
| in case the original vendor stops working on it.
| gibba999 wrote:
| Another major issue is remixing and license
| compatibility. AGPL is part of an ecosystem. Anything
| MIT, BSD, current GPL, etc. will freely mix with AGPL.
|
| Most of the other licenses, I can't use in any of my
| projects without running into license compatibility
| issues.
| zokier wrote:
| Notably AGPL is also DFSG free, meaning that AGPL
| licensed software can be included in Debian and its
| derivatives. I believe its also fine in other major
| distros (RHEL/SuSE etc).
| bosswipe wrote:
| I don't value OSI's stamp of approval since they were
| explicitly founded to coopt FSF's effort and make it more
| corporate friendly. Obviously corporate lawyers would
| disagree with me.
|
| A license that allows all typical freedoms except "use
| the software to start a SaaS using proprietary
| infrastructure" is fine by me.
| klelatti wrote:
| Proprietary infrastructure = All infrastructure
| essentially.
|
| So you're fine with a license that can't be used for
| SaaS. So basically you're happy for the commercial
| internet to be powered by proprietary software - with all
| that would mean for free software.
| bosswipe wrote:
| That's pretty much the same as AGPL. A tell about OSI's
| biases is that AGPL and SSPL are basically the same but
| since Amazon's propaganda engine ramped up against SSPL
| it was labeled as somehow completely out of bounds.
| josephcsible wrote:
| > AGPL and SSPL are basically the same
|
| Are you serious? Once you look past the most superficial
| level, they're not even close.
| [deleted]
| SXX wrote:
| How are they pretty much the same? AGPL only require the
| changes to the software itself to be shared under AGPL
| and it's apply the same requirement for everyone.
|
| SSPL require to release source code for every piece of
| your infrastructure if your business model seems like
| Amazon. This is descrimination which both FSF and OSI are
| not allow.
| ufo wrote:
| While there are significant ideological disagreements
| between the OSI and FSF, when it comes to FOSS licenses
| their definitions are mostly equivalent. There are very
| few licenses that are recognized by the OSI but not by
| the FSF, and vice-versa.
| yjftsjthsd-h wrote:
| I don't care _so_ much about the AGPL specifically, but it
| 's a single known license, rather than every time I find a
| new project having to find out what "interesting" license
| they cooked up _this_ time.
| swyx wrote:
| yes but afaict SSPL was kiiinda becoming a de facto "f
| off AWS" license that was generally becoming standard.
| thats all any of these vendors want, they're not coming
| up with new licenses just for shits and giggles.
|
| standards evolve over time, it was entirely possible that
| Grafana could have thrown its weight behind SSPL and
| helped legitimize it more.
| josephcsible wrote:
| > Grafana could have thrown its weight behind SSPL and
| helped legitimize it more.
|
| Which would not have been a good thing in any way, so I'm
| glad they didn't do that.
| ocdtrekkie wrote:
| This would've been nice. I think we are not far from the
| OSI having to recognize that SSPL is the future whether
| they like it or not, and possibly moving from
| obstructionist to a more constructive point, where they
| help evolve the SSPL to address their concerns, while
| recognizing that it is a copyleft open source license.
| josephcsible wrote:
| A license doesn't get to be called open source just
| because it's popular. Look how popular Windows is. Is it
| open source too?
| ocdtrekkie wrote:
| The only thing that differs between SSPL and the AGPL in
| terms of being open source or not is that one particular
| group of people has decided one is Open Source(TM) and
| one is not.
| josephcsible wrote:
| > one particular group of people
|
| I assume you mean the OSI. But it's not just them with a
| problem with the SSPL. Debian and Fedora both reject it
| too, independently, for being non-free.
| api wrote:
| Anything not hard-copyleft (GPL, AGPL) or source-available
| (BSL etc.) is going to be embraced, extended, and SaaSified /
| paywalled. Eventually the open version might get abandoned
| since its authors will get tired of providing free labor to
| billion dollar cloud companies.
|
| I don't think you'll see a lot of major projects under super-
| liberal licenses in the future. You will see such licenses
| for libraries and other components.
| indigochill wrote:
| > I don't think you'll see a lot of major projects under
| super-liberal licenses in the future. You will see such
| licenses for libraries and other components.
|
| And that seems fine, at least if you subscribe to the Unix
| philosophy of composability. Honestly, I love Django, but
| for some projects I'd love even more to use just Django's
| ORM without all the other stuff (which I also like, but is
| irrelevant for some projects).
| valyala wrote:
| IMHO, companies change their product licenses from BSD-like
| licenses to custom source-available licenses because of the
| fear they couldn't compete on the market. The license
| change doesn't protect the company from losing the market.
| Moreover, it increases the speed of company abandonment
| because of bad public message.
|
| Full disclosure: I'm CTO at VictoriaMetrics [1], we are
| happy with Apache 2 license and have no plans to change it.
|
| [1] https://github.com/VictoriaMetrics/VictoriaMetrics/
| dcow wrote:
| If you use a GPL library then your main work becomes GPL.
| da_chicken wrote:
| That's true -- well, you're _obligated_ to release the
| work under GPL -- but quite a lot of libraries are LGPL
| licensed which allows a proprietary application to link
| to it.
| tarsinge wrote:
| We are talking about products here.
| rover0 wrote:
| If you use a GPL library and don't make the main work GPL
| you're committing copyright infingement. Your work will
| never magically become GPL.
| yjftsjthsd-h wrote:
| > Anything not hard-copyleft (GPL, AGPL) or source-
| available (BSL etc.) is going to be embraced, extended, and
| SaaSified / paywalled. Eventually the open version might
| get abandoned since its authors will get tired of providing
| free labor to billion dollar cloud companies.
|
| FreeBSD is 27 years old. Postgres is 24 years old. SQLite,
| which is _placed in the public domain_ , is 20 years old.
|
| You will forgive me not holding my breath.
| fader wrote:
| I think that OSX co-opting BSD is a perfect example here,
| honestly.
| josephcsible wrote:
| This seems to lump relicensing to better FOSS licenses like
| AGPL in with relicensing to bad non-FOSS licenses like the
| Commons Clause, SSPL, BSL, Redis Source Available License, and
| Anti-996 License. You're right about the former, but the latter
| is screwing over the community.
| xyzzy_plugh wrote:
| Serious question: How is the _community_ impacted by SSPl,
| BSL, etc? The average end-user who makes no modifications and
| is not reselling as-a-service is fine, there is no additional
| burden with either AGPL or the non-OSI-compliant licenses.
|
| How does the AGPL screw over the community _less_ than the
| other licenses? AGPL is problematic for a slew of reasons,
| lots of corporations (whether or not you agree that for-
| profit enterprises make up the bulk of the "community" is a
| separate discussion) disallow it entirely (mostly thanks to
| Google's precedent).
| gibba999 wrote:
| The community is impacted because there isn't an
| intellectual commons to build from.
|
| The OSI or FSF-approved licenses form an ecosystem. I can
| have a project which mixes AGPL, GPL, and BSD code. I can
| make that part of the next version of Ubuntu. I can borrow
| bits of code. It all works together. If the goal is to have
| a computer running free software, AGPL builds towards that
| goal. If the goal is to use the code in new and unexpected
| ways, AGPL builds there.
|
| The non-OSI licenses are walled gardens. Even the ones
| which nominally allow remixing require me to drop a few
| grand on a lawyer before remixing them (more grand if it's
| international).
|
| AGPL is toxic to some corporations for mixing into their
| proprietary projects, but the commercial dual-license takes
| care of that. Most corporations don't mind spending money.
|
| AGPL also gives a long-term sustainable pathway if the
| original vendor goes under or goes evil.
| formerly_proven wrote:
| I don't see how AGPL is really problematic in any way for
| something like Grafana.
|
| Most people, and companies, that use this will just run an
| unmodified Grafana container, maybe with some plugins (not
| of their own). AGPL doesn't come into play here (the
| software is not modified).
|
| This change would really only impact a company that takes
| Grafana, puts a bunch of patches on top of it and wants to
| offer that as a SaaS. Those guys could still even do that,
| they'd just have to publish their patches. Or, quite
| possibly, just pay for a commercial license - a lot of
| GPL/AGPL software is actually dual-licensed, with more ore
| less "dowhateveryawant"-style, paid licenses.
|
| All of this sounds fair to me.
| shawnz wrote:
| Blocking competition among providers of your app as a
| service is a burden for users. Users would benefit from
| being allowed to use the provider which best meets their
| needs, rather than being forced to use the provider who
| happens to be allied with the copyright owner.
|
| AGPL tries to ensure that third-party providers are at
| least sharing their development efforts to the same extent
| that those efforts were shared with them. AGPL doesn't try
| to give anyone an unfair advantage at providing the
| software as a service, not even the copyright owner.
| jrv wrote:
| What I don't like about changes like this is that it makes it
| impossible to reuse any Grafana/Loki/Tempo pieces or libraries in
| any more permissively-licensed code without forcing that whole
| project into the AGPL as well. That doesn't only hinder
| competitors (which seems to be the legitimate goal), but also
| hinders interoperability and an open ecosystem evolving where
| people freely exchange bits and pieces of code to make things
| work together. I know that some parts of the codebases have been
| exempted from these changes (see
| https://twitter.com/TwitchiH/status/1384566382180896769), but
| those are only some, and they may change over time...
| josephcsible wrote:
| IMO, the ideal end-state from a software freedom perspective is
| that all software becomes AGPL. This change is a step in that
| direction, not only with the directly affected products, but
| for the reasons you mentioned, an additional pressure for more
| things to switch to it. Do you not like that end goal, or do
| you just think the side effects of the change outweigh the
| benefits of getting closer to it?
| jrv wrote:
| I think it's both a completely unrealistic end goal (we live
| in the real world), and I also think that the AGPL puts you
| into a hole where you can never get out of again if you
| decided that you now need different constraints. So I really
| much more prefer permissive licenses.
|
| Funnily just before you wrote this comment, I also tweeted
| just that :) :
| https://twitter.com/juliusvolz/status/1384599249082626052
| josephcsible wrote:
| > I think it's both a completely unrealistic end goal
|
| I know :( I just meant it's the ideal we should strive
| towards, even if we never fully reach it.
| jrv wrote:
| If this incremental step led to a better world already, I
| would maybe agree... but I think it makes the whole
| ecosystem worse and worse, until some far-away tipping
| point is reached where almost everything is AGPL and can
| reuse each other again. And even then I'm not sure I'd be
| happy with the *GPL, as now you can't back out of it
| again in case you later discovered that it was the wrong
| decision, without getting the permission by all copyright
| holders.
| dec0dedab0de wrote:
| If you're the copyright holder you can relicense anytime
| you want. You're never stuck.
| jrv wrote:
| Yeah, which is why typically those companies make
| external contributors sign a CLA that allows for
| copyright assignment and relicensing. Which is annoying
| if you contribute to a company-owned project under a
| permissive license to help make it big and successful,
| and then they change the license under you. But yeah,
| then they could switch it around in both directions if
| they get all the rights signed away to them.
| nopzor wrote:
| you realize that if you contribute to a company apache
| project without a CLA, they can change the license out
| from under you to _any_ license that they want, right?
|
| [note: am co-founder/ceo of grafana labs]
| pvorb wrote:
| I think that by putting your software under AGPL the only
| effect you'll see is that it will be used less.
| sangnoir wrote:
| Unless you are using your software as a resume and need
| more Github stars to land you interviews, this is a fine
| result if it gets you more money. Companies like money more
| than they like clout - and it won't help them to have a
| billion users and then be undermined by "AWS Grafana" and
| slowly go out of business. I much prefer companies choosing
| the AGPL over going proprietary, using a franken-license or
| going out of business because Amazon sucked out all the
| oxygen.
| jrv wrote:
| Yep, already thinking about alternatives to Grafana in the
| long term now...
| josephcsible wrote:
| Why? If your software is already all available under
| permissive licenses, what does Grafana's new license
| require of you that you weren't already doing?
| jrv wrote:
| Oh nothing for now, and there's likely not going to be a
| viable alternative around for a while. But long-term, I
| don't see Grafana as part of the openly sharing ecosystem
| anymore, as with them being under the AGPL, but most
| other relevant OSS projects in the space being under
| permissive licenses, the whole idea of code sharing now
| goes out of the window (or rather, becomes one-way). I
| don't like the long-term implications of this for the
| ecosystem.
| pvorb wrote:
| Maybe I want to keep my software under a permissive
| license? AGPL would also infect my code, no? And what if
| we're talking about proprietary code that doesn't have
| much to do with Grafana and only uses it for monitoring?
| saagarjha wrote:
| You can keep your software under a permissive license, as
| long as you ship it under the GPL.
| gpanders wrote:
| If you're only _using_ Grafana, but not modifying it and
| re-distributing it, then the AGPL places no obligation on
| you.
|
| You only have to license your own software as AGPL if it
| is a derivative work of another AGPL licensed program.
| pvorb wrote:
| Thanks. Misunderstanding by me. I got the term "linking"
| wrong.
| iFire wrote:
| What is the biggest fork of Granafa I can use that is non-share-
| alike?
|
| Edited:
|
| Oh, I can't say this... I leave it up for posterity and a note to
| myself then.
|
| http://www.paulgraham.com/say.html
| josephcsible wrote:
| Is there a specific conflict like ZFS-on-Linux that you want to
| avoid, or are you just asking "how can I most benefit from
| other people's work without letting anyone else benefit from
| mine?"
| iFire wrote:
| Exactly. This is the ZFS-on-Linux situation.
|
| I prefer to keep all my code as much as possible mit and I
| share them on Github. This is my mode of operation.
|
| Grafana makes me unable to use MIT for that use.
| josephcsible wrote:
| I think you misunderstand the ZFS-on-Linux situation. The
| problem with that is that ZFS is licensed under the CDDL,
| and Linux is licensed under the GPL, both of which are FOSS
| licenses, but there's no legal way to combine them. In your
| situation, it sounds like there is a legal way to combine
| them, and you just don't like the license that it would
| require you to release your code under.
| zxzax wrote:
| >keep all my code
|
| Huh? Grafana isn't your code, it's someone else's code that
| you'd be using. Unless I misinterpreted, and you are a
| Grafana contributor. If you are, you could dual license
| your contributions under AGPL and MIT, if you wanted.
| yjftsjthsd-h wrote:
| Without knowing what they work on, one obvious case is
| code that interacts with grafana; extensions, plugins,
| whatever. For that matter, it's perfectly possible to
| maintain your own personal patchsets without being a
| "contributor" per se. Niche, but plausible.
| justincormack wrote:
| Plugins don't seem to have been relicensed looking at
| https://github.com/grafana/grafana/blob/HEAD/LICENSING.md
| iFire wrote:
| The AGPL3 license means that all my MIT code I distribute
| in a package will be considered AGPL3. So I can't combine
| Grafana, and my original work and improve both.
|
| This is a stated purpose of GPL3 / AGPL3. I am happy to be
| told I am wrong and it is possible.
| aidenn0 wrote:
| IANAL, but pretty sure you can license all of your code
| MIT, while also making it part of an AGPLv3 system;
| someone else can _already_ distrubute your MIT licensed
| code under AGPL3, since that would comply with the terms
| of the MIT license.
| aloisdg wrote:
| Yes you can. The purpose of (A)GPLv3 is that someone else
| cannot benefit from you work if you cant benefit from
| theirs. It is a matter of leveraging cooperation.
| devmor wrote:
| If you are not offering a product built on top of Grafana
| as a network-available service, then there is no
| difference between the new license and the previous GPL3
| license for you whatsoever.
|
| If you are, then your obligation would change to
| specifically making only that work which builds on top of
| the Grafana code available to others for free, along with
| the AGPL3-licensed Grafana code. You are not required to
| license that code that you wrote in any way, with the
| caveat that others may freely use it.
| Macha wrote:
| The previous license was Apache 2.0, not GPLv3
| devmor wrote:
| My mistake, regardless, Apache2.0 is GPL3 compat.
| blendergeek wrote:
| It depends on what you mean by "combine". If you are
| releasing a Linux distro that has as one piece of
| software Grafana, you'll be fine.
|
| If your software is in effect an extension of Grafana,
| you will need to release source code under AGPLv3.
|
| https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
| iFire wrote:
| Exactly. This is my understanding.
|
| Edited: Or pick a fork and live on it forever.
|
| Edited: Or write my own Grafana
| devmor wrote:
| This conflicts with everything you've said so far on this
| topic. I don't think you do understand.
| josephcsible wrote:
| What is your code? A fork of Grafana? Plugins for it? Or
| something else?
| sideeffffect wrote:
| If I contribute a code under the new CLA, is Grafana Labs allowed
| to relicense that contribution under a non-copyleft license, like
| Apache Public License 2.0, without my further permission?
|
| If yes, than it's a really bad bad thing and I hope they change
| it.
|
| CLAs that permit relicensing for a project that already uses
| permissive license is fine and fair. But doing that on a project
| with a copyleft license is a bad taste. It would enable Grafana
| Labs to give Grafana to a party X which can then give it to party
| Y, where X isn't required to give all the necessary freedoms to
| Y.
|
| https://opensource.com/article/19/2/cla-problems
|
| https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
| justincormack wrote:
| The new CLA doesn't seem to allow relicense. The old one [1]
| allowed relicense under OSI approved licenses.
|
| [1]
| https://web.archive.org/web/20200311075025/https://grafana.c...
| tlynchpin wrote:
| RIP grafana
|
| ^^ this is not a good contribution to HN, not much substance.
| (edit)
|
| Many people who use Grafana will see this news and will stop
| planning on using Grafana and start planning on doing something
| else. That has nothing to do with Grafana, that is a common
| reaction to AGPL.
|
| In theory, AGPL is fine under circumstances blahblahblah. In
| common practice in commercial settings (in my experience), GPL is
| poison and AGPL is radioactive poison.
| mtmail wrote:
| I'd say a SaaS competitor build on top of graphana is more
| affected https://www.hostedgraphite.com/
| pritambaral wrote:
| Unless they were making money based on their proprietary
| modifications to Grafana, Loki, or Tempo, they aren't
| affected much beyond being required to publish links to the
| source code.
|
| If, however, they _were_ making money off of proprietary
| modifications, and they wanted to keep such modifications
| proprietary, they now have the choice to fork Grafana (and
| Loki and Tempo respectively) as of a pre-AGPL version.
| the_duke wrote:
| "Amazon Announces Grafana Fork , Promises Amazing Things for the
| Community" (2021/05/08) [1]
|
| On a more serious note: there is a bit of a trend in the
| licensing world. Mongo or ElasticSearch changes, or cool new
| projects like redpanda [2] launching with BSL.
|
| Open source is still a very young business model. One that has
| provided a tremendous amount of value over the past decades, but
| we still need to figure out how to build sustainable businesses
| with it. Be it open core, more restrictive licenses, copyleft,
| dual licensing, ...
|
| I just really hope that we don't slide back into the world of
| proprietary closed source. The danger is certainly there, and it
| will hit smaller companies the most.
|
| [1] https://aws.amazon.com/grafana/
|
| [2] https://github.com/vectorizedio/redpanda
| rustc wrote:
| Mongo and ElasticSearch are completely different though.
| Related to those licenses: Has there been any clarification of
| what exactly you need to release for free if you use them to
| offer a SaaS?
|
| > If you make the functionality of the Program or a modified
| version available to third parties as a service, you must make
| the Service Source Code available via network download to
| everyone at no charge, under the terms of this License.
|
| > "Service Source Code" means the Corresponding Source for the
| Program or the modified version, and the Corresponding Source
| for all programs that you use to make the Program or modified
| version available as a service, including, without limitation,
| management software, user interfaces, application program
| interfaces, automation software, monitoring software, backup
| software, storage software and hosting software, all such that
| a user could run an instance of the service using the Service
| Source Code you make available.
|
| Source: https://www.mongodb.com/licensing/server-side-public-
| license
|
| I can think of a hundred questions based on that text. If I use
| S3 to store data for my Mongo SaaS, do I need to call Bezos and
| buy the complete source code of S3?
| zokier wrote:
| > If I use S3 to store data for my Mongo SaaS, do I need to
| call Bezos and buy the complete source code of S3?
|
| Yes.
| ece wrote:
| I have for a while now thought that the ethical source
| licenses are at least trying to do exactly what open source
| licenses are trying to do, just within a human rights
| framework.
|
| The SSPL and other source available licenses on the other
| hand basically just take away the ability to make a
| meaningful fork, making the project proprietary. Sure it
| makes business sense, but someone might still feel the need
| to make an FOSS alternative.
| gqewogpdqa wrote:
| That doesn't make sense as far as I can tell. You would
| need to release the source code of the managed service you
| built around MongoDB.
| shawnz wrote:
| Just to be clear, had Elastic chosen to relicense Elasticsearch
| under AGPL, there would likely be no issue with Amazon's usage
| of it and I doubt Amazon would have forked it in that case.
|
| The problem for Amazon was strictly due to SSPL, not copyleft
| licenses in general.
| justincormack wrote:
| "AWS is a strategic partner, and given the commercial
| relationship AWS has with us for AMG, AWS and their AMG
| customers are not impacted by this change. We hope that other
| XaaS providers follow AWS's lead in working with open source
| software companies in similarly sustainable ways."
| https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...
| lunfard00 wrote:
| Amazon is the biggest leecher in the industry. They haven't
| open-sourced any meaningful project back to the community and
| they even prevent its employees to work in any of them[1] on
| their free-time.
|
| [1]:
| https://www.reddit.com/r/cscareerquestions/comments/3axbeh/i...
| alexeldeib wrote:
| I think firecracker is pretty meaningful.
| the_duke wrote:
| Firecracker is a fork of Googles crossvm, not an original
| Amazon project.
|
| I bet it wouldn't be open source otherwise.
|
| Also, it's a more convenient and secure shell around qemu.
| It's valuable, but bit that meaningful.
| nine_k wrote:
| To be fair, Free Software was never a business model. It was a
| licensing model that forced to cooperate even such users who
| have incentives to grab the code, amend it, and disseminate the
| _closed-source_ altered version. Free Software is about freedom
| to know exactly what you are running, and to share it. This us
| the value it tries to capture.
|
| Various business models can be built around it. A license that
| restricts closed-source cloud use, like AGPL, still preserves
| the openness at least. It can be combined with a dual
| commercial license.
| josephcsible wrote:
| Amazon forking ElasticSearch to keep its old license is a good
| thing, since ElasticSearch's new license is a proprietary
| visible-source license. Grafana's new license is still FOSS, so
| it's really not a fair comparison.
| [deleted]
| hutrdvnj wrote:
| While it is true that Grafana's new license is still FOSS not
| every company, public cloud provider is willing to accept the
| AGPLv3 license[1]. Hence a fork with the old license is not
| unlikely.
|
| [1] https://opensource.google/docs/using/agpl-policy/
| sitkack wrote:
| Google has the same OSS philosophy as Microsoft and the
| rest of the software community needs to pressure Google to
| change its stance on the AGPL.
| josephcsible wrote:
| True, but my point wasn't so much about the likelihood of a
| fork as whether or not it would be a good thing.
| crazypython wrote:
| That document is based on lies. AGPLv3 does not force you
| to make code running on a different server open-source.
| papito wrote:
| Elastic made a massive blunder by open-sourcing Kibana.
| SumoLogic just took it and builtnon that. You open-source the
| underlying technology - _not the product built on top of it_.
| burmanm wrote:
| Kibana was open source before they formed the company.
| jchw wrote:
| I don't want to weigh in here with a huge value judgement on
| whether this is the right decision. However, I do want to say
| that what they're saying regarding SSPL vs AGPL is totally right.
| One of the biggest sticking points with SSPL is that it's not
| even really _plausibly_ open source, and it tries to create
| restrictions that implicate software that is not even "linked"
| with the program that is licensed under it, which calls into
| question whether it's even legally enforceable.[1]
|
| AGPL is somewhat controversial, but the reasoning for AGPL to
| exist is chiefly to protect the end user's rights, however
| misguided that may be in your opinion. In this case Grafana
| presumably retains the copyright to these programs, so presumably
| they are not beholden to these restrictions in any way. On the
| other hand, though, it does mean that other providers will have
| to distribute their patches back to the community, which is
| pretty much the entire goal of copyleft open source in the first
| place.
|
| In any case, this is, in my opinion, a lot better than SSPL or
| the Timescale license.
|
| [1]: https://www.processmechanics.com/2018/10/18/the-server-
| side-...
|
| edit: wording regarding AGPL was changed, because the claim that
| considering AGPL as not open source is "somewhat controversial"
| isn't quite accurate; it's more correct to say the license itself
| is simply controversial.
| akulkarni wrote:
| (Timescale founder)
|
| We actually designed the Timescale License to be _less_
| restrictive than AGPL. It contains no virality. It just
| prevents public clouds from offering TimescaleDB-aaS.
| jchw wrote:
| I prefer AGPL despite that, mainly because I don't believe a
| license that discriminates on use cases in such a direct
| manner could be compatible with either GPL or DFSG. It's hard
| to directly compare virality vs use-case discrimination as
| far as restrictiveness goes. However, I don't believe there
| is a good argument that such licenses can be considered open
| source.
| akulkarni wrote:
| That is fair, and we do not claim that Timescale License is
| open source. (Our Apache 2 core codebase however is open
| source.)
| josephcsible wrote:
| If the Timescale License is less restrictive than AGPL, then
| why not dual-license your product under the Timescale License
| and AGPL? Wouldn't that give everyone the best of both
| worlds?
| pritambaral wrote:
| > _less_ restrictive than AGPL. It contains no virality.
|
| Heads up: calling out the virality of copyleft licenses as a
| "restriction" is a common tactic used by the anti-FOSS
| brigade -- this includes the likes of Microsoft under Steve
| Ballmer that famously called the GPL "a cancer". So it seems
| like you're re-using old FUD tactics, even if you don't
| intend to.
|
| Putting that aside, what you claim also happens to be an
| established point of argument that has been already heavily
| debated upon in the FLOSS community, specifically by the
| permissive licenses' side; and they actually have some truth
| to the claim. Your claim, instead, is nowhere near as strong
| as theirs.
|
| Permissive licenses take away virality, sure, but add little-
| to-no restrictions of their own. Your license, OTOH:
|
| 1. Doesn't take away nearly as much virality -- Derivative
| Works of code under the TSL are still subject to the TSL; and
|
| 2. Adds its own set of restrictions -- quite a few of them,
| actually.
|
| ----
|
| If your argument was that you "designed the Timescale License
| to be less restrictive than AGPL _specifically on the
| question of virality_", you'd be right. Because the TSL also
| adds a bunch of restrictions, your original claim does not
| quite stand up.
| akulkarni wrote:
| Thank you, I appreciate this thoughtful comment.
|
| And to those who keep downvoting my comments simply because
| they don't agree with them - I always welcome thoughtful
| discussions. :-)
| gibba999 wrote:
| And ergo, I'd never use TimescaleDB. It's not less
| restrictive in any objective sense; it has different
| restrictions. It's apparently less restrictive to you, but
| it's much more restrictive to me.
|
| Why not toss in an AGPL license option? You wouldn't be
| discounted off-the-bat by folks like me. I build open source.
| Timescale is not open source. Timescale won't mix with GPL
| code. I use plenty of GPL code. GPL/AGPL are known
| quantities. Your license requires legal review.
|
| As a footnote, I do pay for hosted versions of most of the
| databases I use.
| akulkarni wrote:
| We do offer an Apache 2 only binary of TimescaleDB which
| includes our open source core (and excludes the Timescale
| Licensed features). In fact, many companies (Azure, Digital
| Ocean, Ali Baba, etc) offer this Apache 2 version to their
| customers.
| PeterisP wrote:
| The freedom to run the software for any purpose is #1 on the
| list of software freedoms that would be called open source.
| No ifs, no buts, no checking whether you qualify - software
| is free if and only if you can run it for any purpose,
| everything else comes only after that basic freedom. Various
| viral conditions only affect the licensing of developer
| changes (while still not restricting the developers right to
| make and use these changes), but violations of this condition
| impose restrictions also on non-developer users on non-
| modified code.
|
| Timescale license does not provide that, so obviously it's
| more restrictive than even the most viral of open source
| licences.
|
| To be specific, the sentence "the customer is prohibited,
| either contractually or technically, from defining,
| redefining, or modifying the database schema or other
| structural aspects of database objects," spits in the face of
| all the ideals of open source. I can respect your decision to
| choose such a license, there are understandable practical
| arguments for that, but I can't respect you calling _that_
| open source - if you consider that users should be restricted
| with what they can do with their data schemas, if you include
| an explicit anti-user-freedom clause, legally mandating
| software developers to be hostile to their own users - then
| at least have the guts to openly say that you are against
| open source (because of all the valid reasons you have, I 'm
| not denying that, you don't have a duty to be pro-open-
| source), instead of misleadingly labeling your license as
| such.
| mfreed wrote:
| Hi PeterisP, just to avoid any confusion:
|
| The sentence you quote is actually meant to -technically-
| establish a basis for what it means for somebody to
| run/offer TimescaleDB as part of a value added service
| (very much allowed) versus a company like AWS offering
| TimescaleDB purely as a DBaaS offering (not allowed).
|
| There are many, many thousands of companies that use or
| embed TimescaleDB as part of their service or product
| offerings, serving huge numbers of customers. We're
| extremely supportive of their ability to do so. We have no
| "enterprise features" that are excluded or held back only
| to paid users.
|
| What we aren't supportive of is AWS running "TimescaleDB-
| as-a-Service" as part of AWS RDS. Because we know they do
| that!
|
| The clause you are quoting helps define some of the legal
| nuances how we get there, ideally in ways that an engineer
| would understand. In particular, what it means to be a
| value added service/product versus just "TimescaleDB-as-a-
| Service".
|
| The alternative legal formulations of this can be found in,
| e.g.
|
| - Confluent Community License ("Licensee is not granted the
| right to, and Licensee shall not, exercise the License for
| an Excluded Purpose. For purposes of this Agreement,
| "Excluded Purpose" means making available any software-as-
| a-service, platform-as-a-service, infrastructure-as-a-
| service or other similar online service that competes with
| Confluent products or services that provide the Software.")
|
| - Polyform "Shield" License ("Any purpose is a permitted
| purpose, except for providing any product that competes
| with the software or any product the licensor or any of its
| affiliates provides using the software.")
| https://polyformproject.org/licenses/shield/1.0.0/
|
| These are all getting to similar places, but just putting
| more emphasis of the legal definition of "competition",
| which we thought would frustrate engineers with its
| vagueness.
| SAI_Peregrinus wrote:
| > a company like AWS offering TimescaleDB purely as a
| DBaaS offering (not allowed).
|
| That restriction makes the license not Open Source. Open
| Source licenses MUST allow anyone to run the software,
| for any reason, by definition. Even "as-a-Service". It's
| a perfectly fine restriction to have, but it shouldn't be
| called an Open Source license.
| cevian wrote:
| And we never call it Open Source!
|
| (Timescale engineer here)
| DetroitThrow wrote:
| For what it's worth, TSL is a great source-
| available/restrictive-for-clouds license in my opinion,
| and I'm glad Timescale went the direction of moving from
| a more restrictive license to a more permissive license
| rather than the other way around.
|
| While AGPL is a value-add for many, TSL isn't as
| ambiguous in some regards and provides a lot of nice "we
| won't sue you for this" clauses for users. Clear
| communication regarding its FOSS status will only help!
| akulkarni wrote:
| I appreciate this debate, but where do we label the
| Timescale License as open source?
|
| Incidentally, that clause exists as a clear line for value
| added products and services. Some companies have a
| restriction that says, "You can't compete with us." That
| approach struck us as arbitrarily blurry. We took a clear
| approach that says DML (inserting, querying data) is
| permitted, but not DDL (creating tables). Again, this is to
| clearly restrict TimescaleDB-aaS providers and not other
| companies building true value added products / services on
| top (e.g., IoT platforms, SaaS companies).
| PeterisP wrote:
| I apologize, I was sloppy at skimming the licence, it
| actually does clearly and properly delineate the open
| source and source-available, describing them
| appropriately.
| globular-toast wrote:
| Who I earth would argue that AGPL isn't open source? The kind
| of people who think open source = free lunch I suppose. It's
| probably the most open source licence there is.
| jchw wrote:
| Maybe it isn't so controversial that it is called 'open
| source' as it is simply controversial. Though GPLv3 + AGPLv3
| improves one of the worse problems, which is compatibility
| with GPL-licensed code.
|
| edit: And FWIW, I have dropped this claim from the post with
| a note, especially since it was not my point anyways.
| josephcsible wrote:
| How is it debated whether AGPL is open source? Who says it
| isn't?
| sneak wrote:
| I feel that the AGPL actually reduces the software freedom in
| a misguided attempt to close the ASP "loophole", as if
| offering an API from a private fork is something to be
| prevented.
|
| I am a proponent of software freedom, and resultantly I view
| the AGPL as nonfree.
| josephcsible wrote:
| What's your definition of software freedom exactly?
| sneak wrote:
| If I download some open source free software, and modify
| it so it does something differently on my computer,
| simply running "systemctl start httpd" should not
| potentially bring down the machinery of state copyright
| enforcement against me for not publishing my private
| patches.
|
| Freedom includes freedom to have privacy. Not
| distributing any software, my privacy should not be
| violated.
|
| Running an ASP off a private fork is not "loophole", any
| more than, say, using free software to make missiles or
| killing machines.
|
| I feel like the AGPL is just anticapitalist fist-shaking.
| pritambaral wrote:
| > Freedom includes freedom to have privacy.
|
| You have that. The AGPL provides rights to _users_ of
| your software; that's it, no one else. If _you don't
| provide_ the modified software to someone, they can't
| demand your private patches. No one can "bring down the
| machinery of state copyright enforcement" against you,
| unless you interact with them first and provide them your
| modified software and they use it.
|
| And even when you do that -- when you provide your
| software to someone -- they still can't demand that you
| "publish" your private patches. Only that you give to
| _them_ the modified software under the same rights that
| you received the original software. Only to _them_, not
| the public. No publishing required. _They_ are free to
| publish the software they received, of course, as were
| you when you first received the original software; but
| you aren't obligated to publish it.
|
| ----
|
| The only difference between AGPL and GPL is that the
| definition of what constitutes "distribution" of software
| is extended. The AGPL changes only "distribution" and
| nothing else in the GPL.
| sneak wrote:
| Yeah, and running a business on my own computer by
| providing API services to someone is not distribution of
| software. Running an API business shouldn't force me to
| distribute anything to anyone.
| josephcsible wrote:
| Consider "Service as a Software Substitute":
| https://www.gnu.org/philosophy/who-does-that-server-
| really-s...
|
| Do you consider it a problem? If not, why not? If so,
| what other than the AGPL do you propose to fix it?
| sneak wrote:
| No, I don't consider it a problem at all. Nothing is
| being used improperly or against the spirit of free
| software when software freedom is exercised (by a service
| provider) - that's the whole point.
|
| I really think the whole AGPL is simply sour grapes,
| because most GPL-using businesses have not figured out
| how to become profitable. ("open source is not a business
| model.") The anti-corporate, anti-business types see
| people exercising their software freedoms and using free
| software to make money, and think it's a problem that
| needs to be stopped.
|
| It's interesting that TPTB have ruled such "ethical
| source" licenses as nonfree - you're not allowed to
| restrict Freedom 0 to say that users aren't allowed to,
| say, use the software to produce bombs. That's not a free
| software license.
|
| Using it to generate revenue however, is seen as a
| "loophole" to be "closed".
|
| I don't see a license that forbids the generation of
| revenue by selling access to a service API using a
| private fork as any less nonfree than one that forbids
| the production of bombs.
| jchw wrote:
| It seems like this one sentence of my message has become the
| focal point of it, which was not the intent. However, I
| corrected it to be more close to the truth, which is to say
| that it is merely controversial, not necessarily that its
| status as an open source license is debatable.
| zokier wrote:
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721
| might be good background reading
| devmor wrote:
| How is it debatable whether AGPL is open source? Who is
| debating this? AGPL is so open source that it legally forces
| open source if you try to close it.
|
| Anyone debating that it's not has a screw loose.
___________________________________________________________________
(page generated 2021-04-20 23:00 UTC)