[HN Gopher] Why we picked AGPL
___________________________________________________________________
Why we picked AGPL
Author : philippemnoel
Score : 219 points
Date : 2024-08-12 17:39 UTC (2 days ago)
(HTM) web link (blog.paradedb.com)
(TXT) w3m dump (blog.paradedb.com)
| karmakaze wrote:
| > Elasticsearch alternative built on Postgres
|
| Without horizontal scaling it's more like a hosted/queryable
| Lucene.
| grobbyy wrote:
| A key issue for me is API compatibility. It's nice to do simple
| and scalable, but you can't have both at once.
|
| API compatibility message I can run simple for small setups and
| scalable for large ones. That's nice and something I strive for
| in software I build.
| nsonha wrote:
| doesn't look like the case here as they don't even have an
| API (to be drop-in replacement for ES)
| philippemnoel wrote:
| We have some API-compatibility in faceted search. But yes,
| we are not (today) a drop-in replacement for ES. We have
| many migrations from ES/OpenSearch and users find that
| converting their code over is well worth the savings in
| maintenance, no-ETL and increased uptime, though.
|
| That said, we may one day add ES API compatibility if we
| can :)
| nsonha wrote:
| is there a place where I can read about what ParadeDB
| actually does? Surely you do more than just pre-install
| the extensions? Do you also develop the extensions
| yourself? Do you support RAG? The last question may not
| make sense as I am new to this space.
| philippemnoel wrote:
| Blog author here. That's fair! We'll add horizontal scaling
| eventually, but for now, our customers (including some large
| brands!) have not needed it. Turns you single nodes are
| remarkably powerful nowadays
| iaaan wrote:
| Every so often I run through the common set of licenses to
| double-check which one I want to personally use for my projects
| (both commercial and for fun), and I always end up back at AGPL.
| For me, it just strikes the right balance between open-source and
| restricting corporations from disproportionately profiting off of
| my labor.
| aaron695 wrote:
| > and restricting corporations from disproportionately
| profiting off of my labor.
|
| This is anti the ethos of GPL [1]
|
| And that's fine, you choose a list or rules that fitted with
| your wants, you don't have to respect A/GPL.
|
| But time and time again we see most people on HN not respecting
| the A/GPL ethos they clam to follow and not understanding what
| A/GPL will mean in practice.
|
| > disproportionately profiting
|
| Off Topic to GPL. Corporations have provided more value to the
| world than any person. Which is almost a tautology since
| corporations are just groups of people working together.
| "Disproportionately profiting off of my labor" would mean they
| are providing amazing resources to people who need them.
|
| You sound like you don't want others to succeed. Which is
| different to you need to make money to live.
|
| [1] The legal/logical issues we see with AGPL are from trying
| to get the license to match the ethos. It's commendable they
| did stick it out.
| Dylan16807 wrote:
| It can't be anti _and_ off topic at the same time.
|
| I think trying to prevent disproportionate profit by big
| companies is plenty compatible with the ethos. The ethos of
| GPL is all about the end user, after all.
|
| > would mean they are providing amazing resources
|
| No it doesn't mean that.
| guappa wrote:
| > Corporations have provided more value to the world than any
| person
|
| If by value you mean: "have increased gini coefficient", then
| yes, corporations have done that.
| thelastparadise wrote:
| Do you intend for companies to _use_ your software, just not
| resell it? Or do you not even want them to use it?
| pxc wrote:
| > For me, it just strikes the right balance between open-source
| and restricting corporations from disproportionately profiting
| off of my labor.
|
| A purely F/OSS company could potentially profit way more from
| your code than you do and still comply with the license. You'd
| be free to reincorporate their code back into yours, of course.
| But code isn't money.
| sedansesame wrote:
| That sounds proportionate to me. They get to make profits,
| and I get to use their improvements if they also benefit me.
|
| This can foster more community than if MIT code were to be
| taken and locked behind closed doors, for profit and to no
| benefit for the devs that made it possible.
| kazinator wrote:
| > _The AGPL license permits free use, modification, and
| distribution of software, provided that distributed, derivative
| works of the software are released under the same license._
|
| Here is the rub: free software permits unconditional use.
|
| The GPL without the A, or MIT or BSD licenses are not EULAs; they
| place restrictions or conditions on redistribution, not on use.
| (With regard to use, they have only certain liability disclaimer
| clauses.)
|
| The AGPL restricts use; it is an EULA: end-user license
| agreement. The antithesis of free software.
| dafelst wrote:
| Genuine question, how does AGPL restrict use? From my reading
| of it, it is only ensuring that any modifications to the source
| code must be made available if you "distribute" the software,
| where distribution now includes hosting it as a service.
|
| It seems more or less in the original spirit of GPLv2 but
| updated for a SaaS driven world. If you consider v3 restrictive
| then you must also consider v2 restrictive, just in a more
| narrow way.
| kazinator wrote:
| Running a program, as a service or not, _isn 't_
| redistribution. It is use.
|
| The original spirit of the GPL is about identifying people
| doing bad things we don't like and trying to prevent them.
| All those bad things have to do with redistribution, not with
| using the program.
|
| The AGPL is still about identifying people doing bad things
| we don't like, except now those people are just running the
| program.
|
| This is no different from Adobe, Apple, Microsoft, ...
| identifying people using their software in ways they don't
| like, and crafting their EULA terms to turn those activities
| into a license violation.
|
| A free software license simply cannot dictate uses, like
| where and how you run the program, and who can access it from
| where.
|
| A free software license can only use copyright law, and only
| be concerned with copying.
|
| EULAs go beyond coypright; they try to connect non-copying
| activities to copyright by the doctrine that if the user
| engages in the forbidden activities, their license is
| terminated (and thus it becomes copyright infringement for
| them to continue to have a now unlicensed copy of the
| software).
| dafelst wrote:
| I'm still not following - you're talking about restrictions
| on use, but what restrictions on use does AGPL apply? What
| can I not do with AGPL software? What are the forbidden
| activities you reference?
|
| The only caveat seems to be making the source code
| available to users of the software, which is also the case
| with GPLv2, just under narrower conditions.
|
| I have no dog in this race, nor any particular attachment
| to any particular license, I'm just trying to better
| understand what these restrictions are that you're
| referencing.
| kazinator wrote:
| > _which is also the case with GPLv2_
|
| No it isn't; under the GPLv2, the source code must be
| available to those to whom compiled code has been
| redistributed. Whether they are users doesn't matter.
|
| The restrictions are that if you violate the license,
| your use of the program is infringing.
|
| > _What can I not do with AGPL software?_
|
| You cannot change it and run it yourself, without hosting
| the source code.
|
| You cannot combine an AGPL program with proprietary code
| and operate it, because you cannot release the
| proprietary code.
| Avshalom wrote:
| >You cannot change it and run it yourself, without
| hosting the source code.
|
| Yes I can. It's only if I let other people use my changed
| code that they become entitled to a copy.
|
| >You cannot combine an AGPL program with proprietary code
| and operate it, because you cannot release the
| proprietary code.
|
| hmm, gotta say that sounds like the proprietary code is
| the thing infringing on my usage.
| kazinator wrote:
| Well no, someone combining the proprietary code with the
| AGPL code infringes if they run that code such that it is
| exposed to visitors.
| pxc wrote:
| Depending on the license of the proprietary software and
| who is creating the software derived from both of them,
| that derivative work could easily be in violation of
| _both_ licenses. lol
| meiraleal wrote:
| >> What can I not do with AGPL software?
|
| > You cannot change it and run it yourself, without
| hosting the source code.
|
| So your point is that people should be free to take
| whatever they want for free and dont't contribute back?
| I'm glad there is a license made to put a limit on people
| like you then
| kazinator wrote:
| I've spent thousands of hours writing code which is under
| the BSD license. Nice try trying to make the argument
| about me.
|
| (I've not put anything under even the dubious GPL license
| in over 15 years, and never will.)
|
| Yes, a free software license must not require people to
| "contribute back", or anything of the sort.
|
| For instance, a "free for non-commercial use" license is
| not free. Even the people who came up with the AGPL
| understand this, and go to great pains to explain it.
|
| I understand the social problem that the AGPL is trying
| to combat, whereby visitors are held captive by saas
| applications over which they have no visibility or
| control.
|
| The AGPL approach is to use the power of a non-free
| license against the problem which makes it a cure worse
| than disease, and repugnant to developers of truly free
| software.
|
| It's almost certainly the case that the saas problem
| _cannot_ be engaged via software licensing terms, if
| those terms are to amount to a free software license.
|
| I don't have a better idea, either, but that doesn't
| change the fact that the AGPL is a non-free license which
| crosses over into governing use rather than just
| redistribution.
|
| Also one issue is that the AGPL doesn't actually solve
| anything. Visitors having the source code to my evil saas
| platform doesn't solve the problem that they're locked to
| it. It doesn't solve the problem that I can change the
| code at any time and they cannot. Or that I can shut it
| down and wipe out their data, or share it with third
| parties. An AGPL conforming application also need not
| provide visitors with any way to export their data.
| meiraleal wrote:
| > Also one issue is that the AGPL doesn't actually solve
| anything. Visitors having the source code to my evil saas
| platform doesn't solve the problem that they're locked to
| it. It doesn't solve the problem that I can change the
| code at any time and they cannot. Or that I can shut it
| down and wipe out their data, or share it with third
| parties. An AGPL conforming application also need not
| provide visitors with any way to export their data.
|
| Please enlight us about how the BSD license do it much
| better in this area. You first complain that AGPL is
| restrictive now complain that it should restrict even
| more? I agree with you, maybe it is time for another
| version of AGPL that includes data sovereignty. Let's
| make it more difficult for corporations to profit from
| FOSS free labor, not more easy.
| kazinator wrote:
| > _Please enlight us about how the BSD license do it much
| better in this area._
|
| It doesn't, but it's a starkly free license which lets
| you do almost anything you want, short of plagiarism.
|
| > _should restrict even more_
|
| Nope; I'm explaining that it's ineffective against the
| key harms that may be perpetrated by SaaS. No license is;
| licensing is the wrong tool.
| mattl wrote:
| > Yes, a free software license must not require people to
| "contribute back", or anything of the sort.
|
| This was in fact Stallman's original vision for Emacs.
|
| https://www.oreilly.com/openbook/freedom/ch06.html
|
| "It is distributed on a basis of communal sharing, which
| means that all improvements must be given back to me to
| be incorporated and distributed."
| quectophoton wrote:
| > You cannot combine an AGPL program with proprietary
| code and operate it, because you cannot release the
| proprietary code.
|
| Question (IANAL), but isn't it also the case that you
| can't combine AGPL code with GPLv2 code? Like maybe you
| write a patch that glues Minio's (AGPL) and Git's (GPLv2)
| source code (I just picked the two first projects that
| came up when searching for those licenses).
|
| Maybe your glue patch can be dual-licensed and that
| specific patch wouldn't have any problems.
|
| But since (1) both licenses are viral and require that
| everything touched by them is licensed under that exact
| license; and (2) you are unable to change either
| project's license; then it seems to me that you would be
| unable to release your patch since it wouldn't be
| considered independent.
|
| Or if you can release your patch as a separate project
| somehow, I think you still wouldn't be able to host this
| modified version of Minio because you can't satisfy both
| licenses at the same time.
|
| So, expanding on your message:
|
| >> What can I not do with AGPL software?
|
| > You cannot change it and run it yourself, without
| hosting the source code.
|
| > You cannot combine an AGPL program with proprietary
| code and operate it, because you cannot release the
| proprietary code.
|
| (My addition) "You cannot combine an AGPL program with
| other _open source software_ , unless their license is
| compatible with AGPL (e.g. MPL 2.0 or GPLv3)."
|
| My understanding might be wrong though, because IANAL and
| these licenses are unapproachable to a mere mortal like
| me, but I just wanted to point out that AGPL also
| prevents combining with other open source software even
| if their license is another GNU license.
| sgarland wrote:
| > Running a program, as a service or not, _isn 't_
| redistribution. It is use.
|
| Hard disagree. You're redistributing the software in a
| manner for people to easily use it.
|
| If you rip a movie you own, there's no distinction that I'm
| aware of in copyright law between hosting the .ISO on an
| FTP server and hosting the .MKV as a stream. They're both
| redistributing, it's just that one is designed for
| ephemeral consumption.
| kazinator wrote:
| That's broadcasting. The recipient of a stream can
| capture the film to create their own .MKV they can
| further stream or pass on.
|
| Equating the running of a program with broadcasting is
| the kind of sophistry we might expect from Apple or Adobe
| or Oracle or their ilk.
|
| Certain portions of a service program may be broadcast,
| like for instance certain string literals carrying text
| that appears at the remote end point. The bulk of the
| software is not transmitted. It transmits and receives
| messages, which are mostly not that program. The remote
| end cannot recover a copy of the program from these
| messages. Some bits of literal data, but none of the
| code. (There are obvious exceptions, like programs
| transmitted to web browsers for local execution.)
| randomdata wrote:
| _> They 're both redistributing_
|
| Well, yes. While perhaps some metadata is lost, the
| content that is worth fighting for is captured in both
| cases. Practically speaking, there is no difference
| between the original source, an ISO rip, and an MKV rip.
| At least to the untrained eye, they are in every way
| equivalent. They both are redistribution, indeed.
|
| That is not the case for SaaS in question. What you
| download during use can in no way be reconstructed into
| its original form. You can't use the software for a while
| and then, from what you've collected, start running the
| software on your local machine. The artifacts of use are
| _very_ different from the software itself. To stick with
| your analogy, watching a movie on Netflix does not give
| you a copy of their server software. Distribution has not
| occurred.
| tzs wrote:
| That analogy does not work because in all the cases you
| describe a copy of the movie ends up with the viewer.
|
| When you connect to a remote server over a computer and
| upload data and receive back results produced by the
| server software you do _not_ receive a copy of the
| program. You receive a copy of the output that the
| program produced.
| graemep wrote:
| > The AGPL is still about identifying people doing bad
| things we don't like, except now those people are just
| running the program.
|
| Its the same "bad thing" as distributing a modified binary
| without the source. Its a way of denying end users access
| to the source code.
|
| You can do whatever you like with AGPL code, as long as you
| make the source available.
|
| it is VERY different from saying "you cannot do this with
| your software". It is just changing the conditions under
| which make source available is required to keep up with how
| people use software has changed.
|
| AGPL is nothing like a EULA. It is a license, not a
| contract. It is very similar to the GPL
| kazinator wrote:
| The AGPL is absolutely a EULA.
|
| The user of a program is the one who installs it
| somewhere and runs it.
|
| Outside people interacting with the program are visitors.
| They don't have the source code because they don't have
| the program at all in any form. It has not been
| distributed to them.
|
| The source code to the program doesn't even do them any
| good. They cannot use that to prevent harms perpetrated
| by the operators of that application.
| graemep wrote:
| A EULA needs to be a contract. THe AGPL is clearly not a
| contract nor does it meet the basic requirements for an
| enforceable contract in common law countries. Can you
| show me where I am wrong about this?
|
| > The source code to the program doesn't even do them any
| good. They cannot use that to prevent harms perpetrated
| by the operators of that application.
|
| It does. It means they can run their own instance instead
| of being permanently tied to the operator of the service.
| It means they can modify and run the software.
|
| > They don't have the source code because they don't have
| to program at all in any form.
|
| That is sophistry. For the type of software AGPL is
| designed for the functionality provided is the same as it
| would if they had their own install. It is called
| "software as a service" for a reason.
|
| The reason the AGPL exists is because the rise of SAAS
| has made the distinction you are making meaningless.
|
| > They don't have the source code because they don't have
| to program at all in any form.
|
| Users of GPL software do not "have to program". The point
| is they can. The same is true with AGPL.
| kazinator wrote:
| Sorry that was a typo we should have said "do not have
| the program" (corrected).
|
| But no the same is not true of the user of the AGPL. The
| GPL user having the source code and being able to program
| or hire somebody is utterly meaningful. That user
| controls the installation of the program. They would like
| the program to do something differently, or not to do
| something unwanted. With the buildable source code they
| can achieve that.
|
| The visitor to the AGPL application have access to the
| source code has no meaning at all. They don't have the
| administrative access to replace the implementation (and
| even if they did, that was just create conflict with the
| other ivisitors).
|
| The ability to set up your own clone instance its
| completely meaningless. For example suppose that's some
| government service website is using AGPL software. What
| do you gain by downloading the software and running your
| own instance? That's not where your data is; you can't
| use that cloned instance to communicate with the service
| agency.
|
| It is the AGPL that's using outdated concepts in a new
| context where they don't make sense. (Licensing helped us
| win the open source war in the 1990s and 2000s, so it'll
| work this time too right?)
|
| You also may be thinking of the software of being
| something like a photo editor or word processing
| application that is hosted, but in which the visitor
| works with only their own files in isolation from other
| visitors, and from the site operators. I don't think
| that's the main target for the AGPL. That may be called
| "strawman AGPL". I tend to agree that the AGPL may be
| effective in this limited situation. But effective is not
| the same as free. A "free for personal use" software
| license is also effective at achieving the aims of its
| purveyor but isn't free.
| aeaa3 wrote:
| > The ability to set up your own clone instance its
| completely meaningless
|
| Isn't that the whole point?
| jenadine wrote:
| Yes. But that point doesn't help the users since they
| don't have the data.
| kazinator wrote:
| It helps in strawman cases when users have the data, and
| the platform doesn't have social features. For instance,
| oh, an online photo editor used by the user in isolation,
| on either local files or easily downloadable files. User
| doesn't like that instance, so they find the AGPLed
| source code and run their own, bringing all their files.
|
| (Why, in that situation, would the user be entitled to
| the custom modifications in that instance they are
| abandoning? If you don't like that instance for whatever
| reason, but like the features, tough luck. Code your
| own.)
| aeaa3 wrote:
| Why would the user be entitled to the commercial SAAS
| platform's custom modifications?
|
| Because the platform provider didn't pay for the
| database's commercial license.
| kazinator wrote:
| > _A EULA needs to be a contract._
|
| Nope. It can just be a piece of text you agree with when
| opening a classic mass-marked app in a shrink-warpped box
| ("shrink-wrap EULA") or a dialog box with text where you
| have to click that by using the software, you agree with
| the licensing terms.
|
| Exactly the same as when you deploy an AGPL program for
| visitors, you are agreeing to its EULA.
| chii wrote:
| which is exactly what a contract is.
|
| It's an agreement between different parties.
| tzs wrote:
| > A EULA needs to be a contract. THe AGPL is clearly not
| a contract nor does it meet the basic requirements for an
| enforceable contract in common law countries. Can you
| show me where I am wrong about this?
|
| https://perens.com/2017/05/28/understanding-the-gpl-is-a-
| con...
| pxc wrote:
| It might be a ULA, but it's hardly an EULA. The party
| hosting a web service is not an _end_ user. The end user
| is that party 's _customer_.
| fweimer wrote:
| The AGPL does not restrict running the program. Only if you
| run modified versions, things get complicated.
|
| That being said, I think the AGPL is only appropriate for
| programs that come with a built-in source redistribution
| mechanism that ensures that modified versions automatically
| comply with the source code redistribution requirement.
| kazinator wrote:
| You realize that would create a problem for some
| organization whose idiot employee combined proprietary
| code with the AGPLed program and the thing automatically
| redistributed the whole infringing mess to the world.
|
| Even if there were safeguards against such a situation,
| someone would blow past them.
| remram wrote:
| > Running a program, as a service or not, isn't
| redistribution. It is use.
|
| This is not how I see it at all. The ones using it are the
| users, and if they sit across the network you are
| distributing it in a very tangible sense.
|
| The idea that the admin running a service is the one doing
| the "use" and not the users of your service is debatable to
| say the least.
| warkdarrior wrote:
| So when you compile a program and distribute over the
| network as a binary, you are also distributing the
| compiler that created the binary?
| progval wrote:
| From section 13 of the license
| (https://www.gnu.org/licenses/agpl-3.0.en.html):
|
| > if you modify the Program, your modified version must
| prominently offer all users interacting with it remotely
| through a computer network [...] an opportunity to
| receive the Corresponding Source of your version [...]
|
| From the Merriam-Webster dictionary:
|
| > interact, verb: to act upon one another
|
| When distributing a binary from a compiler to a user, the
| user does not act upon the compiler. So the user is not
| interacting with the compiler, so you don't need to
| distribute your modified compiler's code any more than
| you would with the GPL.
| kazinator wrote:
| That's not what is in question. Of course if you someone
| has reason to comply with section 13 of the license, then
| users who download the code are having the code
| distributed to them.
|
| The disputed claim is that users who interact with a
| remote program are, by that interaction, being
| distributed the program.
|
| The GNU AGPL itself explicitly disagrees with this; check
| its definition of "propagate" and "convey".
| remram wrote:
| Depending on the license of the compiler, yes, the binary
| is related to the compiler in some way. In practice it
| literally contains code from the compiler.
| kazinator wrote:
| The admin uses the software, regardless of who else is
| regarded as a user.
|
| Among the users, the admin is the one saddled with use
| restrictions by the license.
| chii wrote:
| The users of the software (not just the admin who is
| serving the software over a network) has the right under
| AGPL to request for the source.
| kazinator wrote:
| That is false; the license doesn't speak about any such
| right.
|
| Rather, the copyright holder of the AGPLed work is
| exercising _their_ right to dictate the following:
|
| _[Y]our 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._
|
| Under the AGPL, the visitors to the program need not
| request the source; it must be prominently available for
| them to obtain in a self-serve manner. No mention is made
| that they have any kind of right. They are not parties to
| the license at all. A copyright license can only grant
| rights to licensees.
|
| By the way, "all users interacting" could be interpreted
| to literally mean all users, including users who visit
| the login page, but do not have an account (and are not
| authorized to have one due to not belonging to the
| organization that runs the service).
| lmm wrote:
| > The original spirit of the GPL is about identifying
| people doing bad things we don't like and trying to prevent
| them. All those bad things have to do with redistribution,
| not with using the program.
|
| It's not. It's about making sure users can fix the bugs in
| the software they want or need to use, and share those
| fixes with others. Rules about redistribution are a means
| to that end.
|
| The GPL was originally written in an era of mainframes and
| terminals, the idea of running a program via some
| intermediate system is not novel. But no-one in that era
| would have dared try to argue that a program hadn't been
| distributed to you because it was running on a machine in a
| different building rather than one under your desk.
|
| > This is no different from Adobe, Apple, Microsoft, ...
| identifying people using their software in ways they don't
| like, and crafting their EULA terms to turn those
| activities into a license violation.
|
| If you make your equivalences broad enough then anything is
| equivalent to anything else. "This license is written in
| text, making it no different from that license that is
| written in text".
|
| > A free software license can only use copyright law, and
| only be concerned with copying.
|
| You're confusing ends and means. The free software movement
| was actively opposed to copyright law and wanted software
| to be uncopyrightable. But that was no reason not to use a
| copyright license that served their goals.
| kazinator wrote:
| The GPL is not simply about fixing bugs. It's about
| preventing the existence of versions of the program in
| which you cannot easily find or fix bugs, and the
| underlying ideology that they should be no such programs.
| And not only bugs but deliberate undesirable or malicious
| behavior. The problem with closed source proprietary
| software is that you don't know what's hiding in the
| binaries.
|
| If software were uncopyrightable, they would still be
| binaries without source code, which you would have to
| reverse engineer to find out what harm they perpetrate
| actively or possibly through their security flaws.
|
| Moreover, if you wrote a piece of free source code,
| anyone could do anything with it they wish, including
| removing your name, and not attributing you in any way in
| the documentation accompanying the compiled code.
|
| Stallman was a control freak who insisted that people
| modifying his code give back the contributions to the
| project. In the world without copyrighted programs he
| would have had no leg to stand on, and he knew that. A
| world in which programs are not copyrighted would need
| laws which ban the distribution of binaries without
| buildable source code, and all the tools needed to build
| it and their source code.
|
| A program is not distributed to you if someone else
| installed it on a machine you don't own and you're just
| borrowing that machine. It doesn't matter if you're
| physically at the console, we're at a remote dumb
| terminal or smart client. The program was distributed to
| your school, company or friend or whoever.
|
| I don't think that even the people who drafted the AGPL
| believe the nonsense doctrine that the visitors to a
| server have been distributed the software. That's just
| something invented by the downstream AGPL apologists.
| (And of course vendors of proprietary software like the
| doctrine also. If you buy a program and let 10 people use
| it via remote access to your machine, they would like the
| legal system to believe that those people were
| distributed the program and that you should buy ten more
| licenses). The doctrine is not required for the AGPL to
| work. The software distributed to the individual or
| organization installing it and running it for visitors.
| The license is concerned with the behavior of that
| individual or organization, and uses the power of
| copyright to make their permission to have a copy of the
| program conditional on their usage behavior. The visitors
| to the running application are not parties to the
| license.
|
| The GNU AGPL contains these definitions:
|
| > To "propagate" a work means to do anything with it
| that, without permission, would make you directly or
| secondarily liable for infringement under applicable
| copyright law, except executing it on a computer or
| modifying a private copy. Propagation includes copying,
| distribution (with or without modification), making
| available to the public, and in some countries other
| activities as well.
|
| > To "convey" a work means any kind of propagation that
| enables other parties to make or receive copies. Mere
| interaction with a user through a computer network, with
| no transfer of a copy, is not conveying.
| levkk wrote:
| > The AGPL restricts use; it is an EULA: end-user license
| agreement. The antithesis of free software.
|
| This is a common misconception about Free software. It's not
| about freedom of its users or authors, it's freedom of the
| actual code to be available for others.
|
| For example, MIT license allows users to take the code and
| modify it without releasing modifications. This traps the new
| version of the software, possibly forever, inside a single
| organization.
| xboxnolifes wrote:
| It's my understanding that the MIT license has no such
| restriction on publishing modifications. The only restriction
| is that existing code must stay MIT licensed.
| kazinator wrote:
| Firstly, GPLed programs with proprietary modifications can
| easily be trapped inside single organizations.
|
| The original MIT-licensed program continues to exist and be
| available regardless of the proprietary versions and
| embeddings.
|
| A copyleft license just asserts, using copyright power, that
| such things should not exist.
|
| MIT and BSD licenses just allow certain works to legally
| exist that copyleft advocates think should not exist. The
| copyleft is concerned with squelching the existence of
| things, whereas the MIT and BSD licenses mostly promote
| existence.
|
| (They are concerned with squelching the existence of
| plagiarism: an author's name and copyright notice removed
| from the source code work, and possibly replaced with
| another. Also, squelching the situation where the compiled
| work is accompanied by documentation which neglect to give
| attribution to the presence of that BSD-licensed code.)
| sfink wrote:
| > The original MIT-licensed program continues to exist and
| be available regardless of the proprietary versions and
| embeddings.
|
| > A copyleft license just asserts, using copyright power,
| that such things should not exist.
|
| Well, a copyleft license asserts that proprietary versions
| and embeddings _of the licensed software_ should not exist.
| GPL software doesn 't assert anything about the existence
| of BSD-licensed software. Or at least, not unless you link
| them together into one thing.
|
| It is true that rms would prefer that such works not exist.
| (Or that's how he felt originally, at least.) But the GPL
| is silent on the issue, as it has to be. There's no clause
| saying "the author promises not to release any software
| with a non-copyleft license, nor to name a child Dorothy,
| nor to eat the flesh of an aquatic mammal."
| Tomte wrote:
| > This is a common misconception about Free software. It's
| not about freedom of its users or authors, it's freedom of
| the actual code to be available for others.
|
| That's wrong. Free software is all about freedom for users.
| Stallman wrote whole essays explaining that.
|
| Of course, back in his time, pretty much every user was also
| a programmer. But he is still very clear about that point,
| never writing about programmers when he means users.
|
| It's also why people still fight their silly argument whether
| BSD or GPL is "freer". The BSD camp optimizes for developer
| freedom, the GPL for user freedom. Both camps think everybody
| sees the world their way (philosophically), so the other camp
| must be wrong and stupid.
| hi-v-rocknroll wrote:
| Code lacks agency. It's not a person.
| tivert wrote:
| > Here is the rub: free software permits unconditional use.
|
| I think you're wrong.
|
| > The GPL without the A, or MIT or BSD licenses are not EULAs;
| they place restrictions or conditions on redistribution, not on
| use.
|
| The GPL, at least, puts restrictions on use: you can't use the
| software in certain ways (e.g. use in a binary firmware blob)
| _unless_ you distribute it in source form to the end users.
|
| > The AGPL restricts use; it is an EULA: end-user license
| agreement. The antithesis of free software.
|
| The AGPL does exactly the same thing as the GPL, just with a
| stronger distribution requirement: if you distribute access to
| end users, you must distribute it in source form to the end
| users.
|
| The GPL was designed for the binary distribution age of
| software, the AGPL is the GPL for the SaaS distribution age.
| The GPL alone cannot satisfy Free Software goals in the new
| age.
| kazinator wrote:
| > _can 't use the software in certain ways (e.g. use in a
| binary firmware blob)_
|
| Yes, you can. You can combine a GPLed program with whatever
| you want; you just can't _redistribute_ the result if the
| combination runs afoul of the GPL.
|
| _redistribution_ is not use. Use is running the program,
| reading the program, trying changes and such.
|
| You can combine GNU Bash with proprietary code and let users
| remotely log in to your box to try it.
|
| > _if you distribute access to end users_
|
| There is no such thing. Copyright law does not recognize
| "distributing access". The program is not being redistributed
| when it executes and exchanges messages with remote stations.
|
| "Distributing access" also reminds me of the idea of someone
| hearing the sound of your coins jingling, or smelling your
| cooking: as in from the famous case of Ooka_Tadasuke that
| circulates as a popular parable:
|
| https://en.wikipedia.org/wiki/Ooka_Tadasuke#Famous_cases
| tivert wrote:
| Honestly, I'm getting the impression you're too being too
| rigid with definitions: anchoring too strongly in the
| incidental specifics of GPL as being "free software" while
| ignoring its goals.
| olavgg wrote:
| AGPL doesn't restrict use:
|
| "You are not required to accept this License in order to
| receive or run a copy of the Program."
| kazinator wrote:
| I would say that's an unhelpfully misleading statement in the
| license.
|
| There exist obvious circumstances of the program's use with
| which the license doesn't concern itself, and does not speak
| to, and so in those circumstances the user is not required to
| enter into the license.
|
| A redistributor must enter into the license because it's a
| derivative of the GPL, and so it has requirements related to
| distribution.
|
| A user who runs the program in such a way that visitors
| communicate with it from remote stations obviously is
| required to enter into the license also and comply with its
| requirements.
|
| The license is applied to programs for which this would be a
| typical use.
| kazinator wrote:
| I looked at the context of this.
|
| It's in a section whose purpose it is to make it clear that
| you don't have to accept the license just have a copy of
| the program, but that if you convey the program your
| implicitly accepting with the license, that license being
| the only basis for your permission to redistribute.
| rpdillon wrote:
| > The AGPL restricts use; it is an EULA
|
| It does not. You can absolutely host AGPL software as a
| service, you just have to share any modifications you made with
| those that use the service.
| remram wrote:
| Agreed. In other words, the terms restrict what you can do
| _when you modify_ not when you run. It is also not directed
| at end users (the "EU" of "EULA") but at the developer or
| sysadmin.
| kazinator wrote:
| Sure, and you can absolutely use Photoshop, if you paid for
| it, and promise not to reverse engineer anything.
|
| Or, what do you think usage restrictions are or look like?
|
| If you don't share those modifications then you must not host
| that software such that it communicates with visitors; that's
| a restriction.
|
| The modifications that you are required to share cannot be
| any arbitrary modifications; anything you add has to be AGPL
| compatible.
|
| If the modifications combine the software with GPL-
| incompatible pieces, then you _cannot_ share those
| modifications, which means there is no legal way to host that
| software for visitors.
| rpdillon wrote:
| Copyright covers four rights. The right to copy, the right
| to modify, the right to distribute, and the right to
| perform publicly.
|
| The GPL places restrictions on a combination of the
| modification and distribution aspect, which says that if
| you modify the software and distribute it, then you must
| also include source code.
|
| AGPL is more strict and says even if you just want to
| modify it and use it, you must supply the source code to
| the people who are using it. The important point here is
| that this is not triggering on use of the software (as EULA
| implies). It is only triggered after modification. And
| modification is something that is covered by copyright.
| kazinator wrote:
| It's triggered on use of the modified software. Not just
| any use but use in such a way that network visitors
| interact with the software. If you don't use the software
| that way, the requirement doesn't apply even if you
| modified it.
|
| If you've not modified the software, interested visitors
| can just get the source code from the same upstream, so
| why would it be required of you to host it.
|
| However the following situation could arise and I don't
| see how the license addresses it. You visited a site
| running some AGPL service which was modified by those
| site operators. You decide to clone your own instance
| using their modified code. Since you're not modifying
| anything yourself you're not required to host that code.
| Now suppose that original site shuts down and disappears.
| The upstream for that modified code is no longer
| available. Are you on the hook for hosting it now? You've
| not modified anything yourself.
| rpdillon wrote:
| Nope. Section 10:
|
| > Each time you convey a covered work, the recipient
| automatically receives a license from the original
| licensors, to run, modify and propagate that work,
| subject to this License. You are not responsible for
| enforcing compliance by third parties with this License.
| purpleidea wrote:
| > The antithesis of free software.
|
| Those who oppose the GPL are precisely the people it was
| designed to protect against.
|
| I think we found a good example of your wishes here. You are
| against the GPL if you have an ulterior motive to make
| something proprietary and avoid contributing back!
| kazinator wrote:
| My comment was about the AGPL, not about the GPL.
|
| Though I don't favor the GPL for my own code, I would not
| call it "antithesis of free software". The GPL does not
| impose any use restrictions, and meets a reasonable
| definition of a free license in other ways also.
| tzs wrote:
| It also seems to violate criteria #10 of the OSI's Open Source
| Definition:
|
| > 10. License Must Be Technology-Neutral
|
| > No provision of the license may be predicated on any
| individual technology or style of interface.
|
| It has provisions that only apply to people who are interacting
| with the software remotely over a computer network. If they are
| interacting using some other technology those provisions do not
| apply.
| sfink wrote:
| I think you're 90% right in what you say here and in following
| comments, but I think you're skewing things in a way where I
| end up disagreeing with your conclusions.
|
| > Here is the rub: free software permits unconditional use.
|
| Why are you using the term "free software" here, when it has a
| well-defined meaning that is very much what you get with
| copyleft and the GPL and _not_ what you get with BSD /MIT? I
| think you mean "open source", specifically open source _as
| opposed to_ free software. Your terminology makes a lot of the
| conversation here unnecessarily hard to follow.
|
| > The AGPL restricts use; it is an EULA: end-user license
| agreement. The antithesis of free software.
|
| I don't see the AGPL as the antithesis of OSS at all, even
| though I agree that it is activated by a condition that
| pertains to use, not just redistribution. But that's the
| mechanism, not the goal. Just like the GPL relies on copyright
| law to have its effect, AGPL relies on what you're calling a
| EULA. (I don't disagree, and to me a EULA _is_ a contract, but
| whether it 's exactly the right term doesn't seem important.)
| GPL isn't alone in depending on copyright; the BSD license does
| just as much.
|
| > Running a program, as a service or not, isn't redistribution.
| It is use.
|
| Agreed, but "redistribution" vs "use" is a mechanism argument.
| The intended purpose of the GPL was to allow a developer to
| write software whose future evolution is freely shared. The
| redistribution mechanism doesn't even accomplish this 100%: in
| particular it allows branchless twigs off of the evolutionary
| tree as long as they are indeed branchless (i.e., not
| distributed to anyone else who makes further modifications).
| That goes counter to the goal of free software, but is an
| acceptable loss because those twigs are irrelevant to the rest
| of the evolutionary tree.
|
| But there's a loophole here when the GPL is applied to server
| software: if the software only runs server-side, then the
| redistribution mechanism no longer works. You could modify your
| copy, and give that modified copy to someone else who also
| modifies it. You would have to share your modifications with
| that person, but not to anyone else. _Your twig can grow
| branches._ Neither of you are redistributing the software to
| anyone else, so you aren 't bound by the GPL to make your
| changes available to anyone else, and certainly not to the
| original authors.
|
| The AGPL attempts to plug that hole using an extra mechanism:
| adding a restriction saying that you have to make your changes
| available not only if you're redistributing the software, but
| also if users are talking to the running code[1].
|
| > This is no different from Adobe, Apple, Microsoft, ...
| identifying people using their software in ways they don't
| like, and crafting their EULA terms to turn those activities
| into a license violation.
|
| Sure. Those same companies depend on copyright law as well. But
| the purpose of the AGPL has _nothing_ to do with people using
| the software in ways that the license chooser doesn 't like;
| its purpose is wholly concerned with the evolution of the
| software and therefore the changes being made to it. That
| purpose is achieved via the mechanism of adding conditions
| based on usage.
|
| > suppose that some government service website is using AGPL
| software. What do you gain by downloading the software and
| running your own instance? That's not where your data is; you
| can't use that cloned instance to communicate with the service
| agency.
|
| That is correct. AGPL does not solve this problem. If you're
| locked into a service, then having the full version of the
| AGPLed code does you very little good. That is described as
| "Service as a Software Substitute (SaaSS)" in the AGPL
| explainer at https://www.gnu.org/licenses/why-affero-gpl.html
|
| The free software folks had to punt on that problem. They
| "solve" it by saying: don't use those services. Which is hardly
| a satisfying answer, but nothing else is currently possible.
| Any solution would require regulation and legislation (eg data
| portability laws).
|
| > I understand the social problem that the AGPL is trying to
| combat, whereby visitors are held captive by saas applications
| over which they have no visibility or control.
|
| Incorrect (see above). Though I think some AGPL supporters did
| (and probably still do) think that the AGPL helps with that. I
| guess it does, in trivial cases.
|
| > Also one issue is that the AGPL doesn't actually solve
| anything. Visitors having the source code to my evil saas
| platform doesn't solve the problem that they're locked to it.
| It doesn't solve the problem that I can change the code at any
| time and they cannot. Or that I can shut it down and wipe out
| their data, or share it with third parties. An AGPL conforming
| application also need not provide visitors with any way to
| export their data.
|
| This is all correct. Well, except the first sentence, because
| the AGPL _does_ solve one thing: it ensures that the evolution
| of a piece of software is freely accessible.
|
| Or maybe two things, though the second was not part of the
| original intention afaik: the ElasticSearch/OpenSearch
| situation. The original author develops something that their
| business depends on and does not want to end up competing with
| their own code. AGPL ensures that nobody can take their code,
| add some features to it, and then win their customers with the
| enhanced proprietary version. The original author will at least
| have access to all of the modifications that anybody makes, so
| competition will need to be on a different basis.
|
| [1] It seems like it would have been more straightforward to
| keep the AGPL conditions based on redistribution, and say that
| you have to release your changes to _everyone_ if you
| distribute your version to _anyone_. Would that even work? You
| 'd have a transaction from A->B that induces a requirement on
| A->the world. But it would have avoided making conditions based
| on use rather than just redistribution. I dunno, IANAL. It
| would still allow someone to change the version that they're
| running without releasing the changes, unlike the current AGPL,
| but that's no worse than the situation with GPL'd client-side
| software and doesn't seem like a problem worth solving.
| kazinator wrote:
| When I'm using the term "free software", I mean this:
|
| https://www.gnu.org/philosophy/free-sw.html#four-freedoms
|
| Straight from the gnu's mouth!
|
| "The freedom to run the program as you wish, for any purpose
| (freedom 0)."
|
| > _But the purpose of the AGPL has nothing to do with people
| using the software in ways that the license chooser doesn 't
| like_
|
| Yes it is. If you wrote a network program, and you
| specifically don't like the idea that someone can modify it
| and then host that modified version for users without letting
| them have the source code, then the AGPL is a tool that
| nicely expresses your intent.
|
| Licenses don't care about their intent. People analyze what
| they do and use them accordingly.
|
| For instance, the GPL has turned out to very nicely suit
| corporate interests. The copyright holder of a GPLed software
| component has a competitive edge over the licensees. They
| have to abide by the license and release all their changes,
| which you can help yourself to; meanwhile, you can have a
| proprietary version in parallel.
| sfink wrote:
| > Straight from the gnu's mouth! > > "The freedom to run
| the program as you wish, for any purpose (freedom 0)."
|
| That gnu's mouth spoke 3 other clauses, and finished up
| with:
|
| > A program is free software if it gives users adequately
| *all* of these freedoms. [emphasis mine]
|
| >> But the purpose of the AGPL has nothing to do with
| people using the software in ways that the license chooser
| doesn't like > > Yes it is. If you wrote a network program,
| and you specifically don't like the idea that someone can
| modify it and then host that modified version for users
| without letting them have the source code, then the AGPL is
| a tool that nicely expresses your intent.
|
| Ok, let's stick with "The freedom to run the program as you
| wish, for any purpose". We're talking about running the
| software here, not modifying it or hosting it. You _can_
| run the program as you wish. For any purpose -- what
| purpose are you claiming is disallowed? "For the purpose
| of running it on my server without giving out my changes"
| is not about running it, that's about something incurred as
| a result of running it. Which is unfortunate, I agree; it
| would be nicer if all obligations were only incurred when
| distributing it. But that still doesn't restrict the
| running part.
|
| But never mind, this is too much of a semantic argument at
| this point. I was trying to understand why the AGPL bothers
| you more than the GPL. I get the argument that it triggers
| a condition based on usage rather than distribution, but
| given that the condition does not restrict the usage, I'm
| not sure why you care. Is it a principle? I agree that it
| feels a little messy, but given my understanding of the
| core goal of copyleft licenses, it actually feels to me to
| be pretty close to a minimal encroachment beyond the GPL
| that still satisfies the original goal of the GPL for
| server-side software.
|
| > For instance, the GPL has turned out to very nicely suit
| corporate interests. The copyright holder of a GPLed
| software component has a competitive edge over the
| licensees. They have to abide by the license and release
| all their changes, which you can help yourself to;
| meanwhile, you can have a proprietary version in parallel.
|
| Yeah, and my previous message didn't adequately cover this
| part. AGPL+CLA has a purpose and expresses an intent beyond
| the intent behind GPL. I'm personally more concerned with
| the evolution of the software I and others release, even if
| I find this corporate usage of the AGPL somewhat
| fascinating. If I understand correctly, your philosophical
| objections to the AGPL aren't based on this corporate
| scenario either, though?
|
| You care about restrictions on usage and want as few
| restrictions as possible, so a corporation building upon
| BSD code internally without releasing changes doesn't
| bother you. But AGPL does bother you, because that
| corporation (or any other user) would need to consider the
| requirements of running that code. Do I have that right?
| (Or strictly speaking, running _and_ modifying the code,
| since there are no requirements placed upon just running it
| if you haven 't changed anything.)
| keskival wrote:
| The point of an OSS license in these kinds of situations is
| pretty simple:
|
| They need to pick a license which is salty enough so that big
| corporations cannot use it, but have to buy a special license
| from the authors.
|
| Meanwhile they can support and benefit from the open source
| community without bureaucracy, and get a maximal userbase to
| create content on the web about this stack, and have a maximal
| number of people who know this stack and want to use it.
|
| AGPL is perfect for this.
| zelphirkalt wrote:
| Where there is a will, there is a way. Big corporations could
| use the license and stick to its terms, but no, they don't want
| to. Better in their view to just take take take and never give.
| What they don't see however, and what is on no ones quarterly
| number sheet, is all the talent they don't attract.
| k__ wrote:
| Which is funny, as enterprise customers have no issue in
| buying closed source software, but the moment they see a GPL,
| they lose their mind.
| hi-v-rocknroll wrote:
| No, that's a gross mischaracterization based on ignorance.
| It only applies to AGPL because it prevents SaaS services.
| And because it can't be proven that an AGPL app isn't
| required as part of a SaaS service to function, then it
| can't be used anywhere in a MAANG shop.
| dgb23 wrote:
| I thought the point of copyleft was mainly to protect the
| freedoms of users.
|
| But apparently it's also used as a filter of who can interact
| and benefit from it.
|
| But I don't really understand all of it.
|
| One thing I always wondered about selling separate licenses
| alongside GPL:
|
| Can the authors (holding the copyright) distribute code under a
| different license when there were external contributors under
| GPL?
| keskival wrote:
| By default the contributors also hold copyright and need to
| consent to the separate licensing.
|
| However, this is typically solved by using a contributor
| licence agreement (CLA) where all contributors click through
| a form before submitting a PR where they declare that they
| own the copyright for the PR and they give a license for the
| organization to relicense the work and derivatives. Sometimes
| the whole copyright is transferred to the organization in
| these agreements.
|
| I didn't check but according to some comments here the CLA in
| this case is already embedded into the AGPL license.
|
| In principle this scheme guarantees that the original
| organization always has special rights over all of the open
| source community, as they can dual license all the derivative
| works.
| dgb23 wrote:
| Thank you!
|
| This might be a viable licensing scheme for Swiss
| government contractors now. The federal government requires
| open source licenses for all software projects as of last
| year or so.
|
| (A)GPL+CLA might be a good way to ensure the interests of
| the both the Swiss people and the flexibility or
| competitiveness of contractors, allowing them to retain
| proprietary licenses where needed or wanted.
|
| Follow up:
|
| Am I correct in thinking that this might slightly hinder
| contributions on one hand, but ultimately anyone could
| still maintain an _independent_ fork?
|
| Or in other words: Would contributions to a fork still
| require signing the CLA and essentially allow the original
| authors to dual license any such contributions?
| itsgabriel wrote:
| Contributions to a fork could be done under just the
| AGPL, without any CLAs (also to the original repo, but
| those won't be accepted). Then the entire fork is
| effectively AGPL only. I don't think any original CLAs
| would apply to the fork, unless the fork owner is the
| same legal entity/successor as defined in there. Same
| goes for the original authors, they'd need CLAs from all
| fork contributors.
| nox101 wrote:
| > Can the authors (holding the copyright) distribute code
| under a different license when there were external
| contributors under GPL?
|
| No, if any contributions were made under the GPL, they'd have
| to get permission to change the license to AGPL from every
| contributor or remove their contributions.
|
| Most projects like this require you license your
| contributions in a way that lets them sell non-AGPL licenses
| (see their Contributor License Agreement) https://cla-
| assistant.io/paradedb/paradedb
|
| So basically they can do whatever they want with your
| contributions.
| matheusmoreira wrote:
| Absolutely. As the copyright owners, the authors of the
| software can always sell permissions to corporations. This
| allows software to become free. Stallman himself has suggested
| this to corporations:
|
| https://www.gnu.org/philosophy/selling-exceptions.html
|
| People have pointed out to me that the above is not quite the
| same as what happens today with people building proprietary
| SaaS platforms. So I emailed Stallman to ask about the ethics
| of it. This was his reply: > It is my
| understanding that as the copyright holders > they have
| the right to do it without any problems. > They leverage
| the AGPLv3 to make it harder for their > competitors to
| use the code to compete against them. I see what you
| mean. The original developer can engage in a practice
| that blocks coopertation. By contrast, using some
| other license, such as the ordinary GPL, would permitt
| ANY user of the program to engage in that practice. In a
| perverse sense that could seem more fair, but I think it is
| also more harmful. On balance, using the AGPL is
| better.
| PhilippGille wrote:
| They looked at 4 licenses (Apache, Business Source License, AGPL,
| Elastic License) representing different categories.
|
| I think the Mozilla Public License represents another category
| and should always be evaluated as well. (or the Eclipse Public
| License or CDDL are similar)
|
| They are less permissive than Apache in that they require
| contributing back (as in open sourcing _changes_ under same
| license), but more permissive than AGPL in that you can
| _statically_ link an MPL licensed library into your project
| without having to open source your project.
| graemep wrote:
| LGPL also allows that.
|
| What MPL is missing AFAIK that AGPL does have is requiring
| making source/changes available when providing the software as
| a network service.
| PhilippGille wrote:
| No, LGPL has specific requirements for static linking. When
| your product is usually a Go binary that you can publish as
| is, using an LGPL library makes it tricky.
|
| And re network service, I don't see the MPL tying the
| requirement to making changes available to a method of
| distribution.
| graemep wrote:
| Good point. I am used to thinking in terms of thinks that
| are dynamically linked.
| michaelsbradley wrote:
| Static linking with LGPL is possible for proprietary
| software; the requirements are sometimes misunderstood:
| If you statically link against an LGPLed library, you must
| also provide your application in an object (not necessarily
| source) format, so that a user has the opportunity to
| modify the library and relink the application.
|
| https://www.gnu.org/licenses/gpl-
| faq.html#LGPLStaticVsDynami...
|
| So, relinkability is the key. For some platforms and
| toolchains that may be impractical but for others not so
| much.
| jenadine wrote:
| The LGPL is great for software libraries written in C,
| but doesn't really work for any other programming
| language. It uses concepts like object files and linking
| that assumes C. Even in C++ which is closely related you
| get issues with templates (users can't easily replace
| that code by their own since it is inlined in the
| binaries)
|
| Many programming languages don't even have the concept of
| dynamic linking or object files that can be shared.
| JohannesSuenden wrote:
| I love the AGPL. I can't imagine it becoming popular for generic
| business functionality in library form, but for highly-
| specialized libraries (in my case scientific with industrial
| applications) it was everything I was looking for --- not least
| because automated license scanners flag it and scare potential
| parasites away. It's also a great choice for complete pieces of
| software (such as DBs, as in this case) to offer a free tier for
| communal benefit, provided you're genuinely willing to let the
| project develop a life of its own if the open source community
| finds reason to mobilize around it.
|
| For academic use AGPL compliance is a natural part of life
| anyway, for non-profits it's a little bit of effort but there's
| no fundamental objection, and when companies get involved it
| ensures that either my collaborators and I get a payout for SaaS-
| ification/proprietarization, or that it only gets used in
| internal tooling, which means that money gets redistributed to
| labor (often also to us via consulting fees or custom development
| arrangements anyway, since we know the code best).
|
| It's a model for software development that I can really get
| behind.
|
| Best of luck to you!
| philippemnoel wrote:
| Blog author here. I couldn't agree more. Thank you for your
| kind words and for sharing the academic perspective of using
| the AGPL - super interesting!
| mroche wrote:
| I'm a fan of AGPL as well, but there's a point of possible
| confusion for GNU license variants I personally run in to and
| maybe others as well. It may be worth specifying which
| variant of the AGPL you are using, e.g. AGPL-3.0-only or
| AGPL-3.0-or-later.
| philippemnoel wrote:
| That's fair. We use AGPLv3. I haven't seen any AGPL project
| that wasn't using v3, so we decided to keep it short for
| readability, but you bring up a very good point.
| jillesvangurp wrote:
| I'm actually not a fan of this restrictive license and the even
| more restrictive contributor license that is in place here
| which is what enables them to sell closed source versions of
| the software and potentially close source entirely (as other
| companies have done). AGPL without this is not very practical
| for companies as it makes selling commercial licenses
| impractical and is a bit of a turnoff for commercial users.
|
| > Grant of Copyright License. Subject to the terms and
| conditions of this Agreement, You hereby grant to the Company
| and to recipients of software distributed by the Company a
| perpetual, worldwide, non-exclusive, no-charge, royalty-free,
| irrevocable copyright license to reproduce, prepare derivative
| works of, publicly display, publicly perform, sublicense, and
| distribute Your Contributions and such derivative works.
|
| If you are happy to contribute code and then have them take it
| and sell it under a closed source license; or at a later stage
| just decide to relicense the whole thing as closed source; go
| for it. But most external contributors probably wouldn't like
| this.
|
| Usually the effect that this has is that the OSS contributor
| community is pretty much exclusively employees of the company
| involved. I can't imagine third party companies agreeing on
| working on this or paying their people to work on this. Why
| would they?
| ebiester wrote:
| If you need something else, you pay for it.
|
| Open source does not necessarily mean open contribution. It
| may turn you off, but the tradeoff is that you can make the
| changes you need and run for your purposes. If your purposes
| is to make closed source software with it, you will need to
| pay for that privilege.
|
| win-win!
| sangnoir wrote:
| > If you are happy to contribute code and then have them take
| it and sell it under a closed source license; or at a later
| stage just decide to relicense the whole thing as closed
| source; go for it.
|
| Isn't this a core feature of the "unrestrictive" licenses
| you're a fan of? If you don't like freeloaders, BSD-/MIT-
| style licenses are even worse because they allow _anyone,_
| not just the maintainers, to sell your contributions in a
| closed-source product.
| Vegenoid wrote:
| Yes. I think what makes some people unhappy is the
| perceived inequality: you can do whatever you want with my
| contributions, but I can't do whatever I want with the
| software.
|
| But there simply has to be control and restrictions over
| the use of software for it to be commercially viable (in
| almost every case).
| sangnoir wrote:
| > But there simply has to be control and restrictions
| over the use of software for it to be commercially viable
| (in almost every case).
|
| True. But not all software _has_ to be commercially
| viable, arguably the most useful /critical and yet
| valuable isn't - currently my list is Linux, git,
| Postgres, Python, dozens of Python libs (perhaps
| thousands, if I go down the dependency trees).
|
| Declaring my biases: I'm partial to GPL licenses and
| believe providing value to users is more important than
| making life easier/profitable to developers. IMO, the
| difference between GPL-style and BSD-style licenses is
| not being "restrictive" or not, but _who_ gets
| restrictions (end users and developers being on opposing
| ends).
| philippemnoel wrote:
| While I agree with you that these are non-commercial, by
| now many of them have very big commercial backings. Many
| Postgres core contributors work at Microsoft, AWS, etc.
| who make billions of dollars selling Postgres-as-a-
| Service today.
|
| Those projects aren't inherently commercial, and great
| software can be built by passionate hobbyists, but often
| times the two go hand-in-hand
| kragen wrote:
| you can also just not accept code contributions from other
| people
|
| > _If you are happy to contribute code and then have them
| take it and sell it under a closed source license; or at a
| later stage just decide to relicense the whole thing as
| closed source; go for it. But most external contributors
| probably wouldn 't like this._
|
| bsd and mit licenses also allow this without a cla (that's
| the whole reason for using them instead of a strong copyleft
| like the gpl) and they seem to be very popular
| gspr wrote:
| I have no experience with the AGPL, but I really really like
| the idea of it. However, I get worried when I read takes like
| Hector Martin's [1]. In essence, he argues that it becomes very
| easy for the end-user to make even the most trivial of
| modifications to AGPL code _or stuff associated to it_ and
| accidentally violate the license 's quine requirement.
|
| Do you have any insight on this?
|
| [1] https://bugs.gentoo.org/737708
| bityard wrote:
| Hector built up a strawman in that bug, and not a very good
| one. I'm surprised the Gentoo devs were as patient with him
| as they were, given he kept trying to argue his personal
| interpretations which are not in line with how the AGPL is
| generally understood by Gentoo and other distributions. And
| some of the things he claims are just plain wrong.
| philippemnoel wrote:
| The best way to avoid any such issue is to contribute changes
| to the upstream project, which is our goal with the choice of
| license. We're hoping for a centralized ParadeDB project from
| which everyone can benefit.
| Hamcha wrote:
| Correction: they chose AGPL with a poison pill (CLA) so they can
| benefit from it and take it away whenever they want more.
| tgma wrote:
| This.
|
| The AGPL deception is you brand yourself as community-minded.
| As long as you don't rely on external contributions that's
| fair. But what the AGPL startups don't emphasize is they
| require you to either assign your copyright to them or give
| them extra privileges to your contributions to be able to
| relicense it under non AGPL (if they don't they don't know what
| they are doing).
|
| AGPL is also not considered a very safe license by large
| organizations even if you want to run it internally unmodified,
| alongside the rest of your application. Many big companies have
| blanket bans on AGPL.
| jay_kyburz wrote:
| What happens if you (the contributor) fork the project, make
| a really great feature in your own fork, make it available as
| the license requires, then the startup integrates changes
| from the fork back into their own project. Does this then
| prevent them from ever changing the license away from AGPL?
| tgma wrote:
| Yes. If they do it they will be able to license the form
| back as AGPL but that wouldn't let them license the new
| thing under their commercial license (effectively useless
| commercially). At that point they are a peer with you.
|
| Some startups may not know this or knowingly violate this.
| goodpoint wrote:
| > Does this then prevent them from ever changing the
| license away from AGPL?
|
| No, as long as they either remove the contributed code or
| distribute it in a way that is compatible with AGPL
| lmm wrote:
| > The AGPL deception is you brand yourself as community-
| minded. As long as you don't rely on external contributions
| that's fair. But what the AGPL startups don't emphasize is
| they require you to either assign your copyright to them or
| give them extra privileges to your contributions to be able
| to relicense it under non AGPL (if they don't they don't know
| what they are doing).
|
| There's nothing specific to the AGPL or startups here, it's a
| common model. The FSF themselves require copyright assignment
| if you want to contribute to FSF projects.
| tgma wrote:
| The model is equivalent. Everything else is different.
|
| FSF's structure, purpose, history and guardrails against
| non-hijacking make it distinct from a startup whose purpose
| is to claim "open source" but preclude Amazon and keep
| their revenue stream. Nothing against them or their
| business model; it's their prerogative, of course. So is
| the community and customer's read on their future actions.
| To claim you should assume they are the same is
| preposterous and/or fooling yourself. Criminals and police
| officers both have guns too. Doesn't make them identical.
| teddyh wrote:
| Firstly, you are wrong. The FSF does _not_ require
| copyright assignment. It is up to the individual software
| projects to decide if they require them or not.
|
| Secondly, _don't_ equate the FSF with any other company.
| The FSF is in the unique position in that the FSF could
| _change the GPL_ if they wanted to. If you use the GPL
| /AGPL, the FSF is inherently trustworthy; therefore, it's
| completely reasonable to also trust the FSF with a
| copyright assignment.
| powersnail wrote:
| > The FSF is in the unique position in that the FSF could
| change the GPL if they wanted to.
|
| They can publish new versions of GPL if they want to.
| They can't retroactively change the terms that users of
| the software and contributors agreed to.
|
| Just like any code owners who has the complete control of
| copyright can publish their code under a different
| license.
| richardwhiuk wrote:
| GPL includes a line which allows it to be used under any
| future version of the GPL.
|
| So if you license under GPLv2, the FSF can create GPLv5
| and add whatever clause they like in it.
| zzo38computer wrote:
| That is only if the license of that software says they
| can use later versions of GPL; it is not automatic.
| powersnail wrote:
| If I accept their license on 2024-08-14 to use their
| software, they can do whatever they want to the license
| after that, but they won't be able to revoke my license
| to use the code as of 2024-08-14 under the license
| present to me on 2024-08-14.
|
| No update on the license can retroactively change what I
| agreed to.
| tgma wrote:
| Importantly, GPL does not include such line. That line is
| not part of the GPL. Critical software such as Linux
| famously do not have that and are not GPLv3 for example.
|
| The Author can choose to license the Copyrighted Work
| under various licenses. The common boilerplate that many
| Authors of GPL software choose to use is a boilerplate
| that says they are licensing their Work under GPL version
| X or any later versions supplied by FSF. That boilerplate
| is Author's declaration of license contract and not the
| license itself.
|
| Basically the Author is directly saying (not through the
| GPL text) that "I trust FSF to come up with future
| licenses and call whatever they want GPL version Y [Y>X]
| and I'll be willing to license my work under that license
| sight-unseen also."
| lmm wrote:
| > Firstly, you are wrong. The FSF does not require
| copyright assignment. It is up to the individual software
| projects to decide if they require them or not.
|
| The FSF requires copyright assignment for many (possibly
| no longer all?) of their own projects, e.g. GnuTLS. Of
| course it's up to an individual project whether it
| requires it (how could the FSF possibly control what some
| unrelated project does?), but on those projects that the
| FSF themselves run (or at least many of them, and
| traditionally it was all of them), they require it.
|
| > The FSF is in the unique position in that the FSF could
| change the GPL if they wanted to. If you use the
| GPL/AGPL, the FSF is inherently trustworthy;
|
| They cannot change the GPL. They can publish new version
| of it, and recommend that you license your project with a
| term that permits it to be used under those new versions,
| but this is not obligatory (and notably e.g. the Linux
| kernel does not).
| goodpoint wrote:
| There is no deception. You are perfectly free to use, modify
| and redistribute AGPL stuff. You can publish your changes
| without signing the CLA.
| gumby wrote:
| Their github repo just says AGPL 3.0. Can you point me to the
| other constraining terms are? This would be quite interesting
| (like the "Open Core" people). And when I say "interesting" I
| don't mean a positive feature.
| dns_snek wrote:
| The project is licensed under AGPL, but outside contributors
| have to sign away their rights with CLA if they wish to
| contribute to the main project. It's in CONTRIBUTING.md [1]
|
| > In order for us, Retake, Inc. (dba ParadeDB) to accept
| patches and other contributions from you, you need to adopt
| our ParadeDB Contributor License Agreement (the "CLA"). The
| current version of the CLA can be found here.
|
| https://github.com/paradedb/paradedb/blob/6b829681190684f241.
| ..
|
| > You hereby grant to the Company and to recipients of
| software distributed by the Company a perpetual, worldwide,
| non-exclusive, no-charge, royalty-free, irrevocable copyright
| license to reproduce, prepare derivative works of, publicly
| display, publicly perform, sublicense, and distribute Your
| Contributions and such derivative works.
|
| https://cla-assistant.io/paradedb/paradedb
| growse wrote:
| The duplicitous language is a bit slimy here.
|
| "In order for us, Retake, Inc. (dba ParadeDB) to accept
| patches and other contributions from you, you need..."
| makes it sound like their hands are tied, you must assign
| copyright, there's no other option.
|
| In reality, this is a (contributor-hostile) choice they
| made. They could have made different ones.
| mperham wrote:
| Like what? Be specific. If you are not a lawyer, please
| say so.
| richardwhiuk wrote:
| Not requiring a CLA and only requiring a DCO. (IANAL
| fwiw)
| gumby wrote:
| But you aren't assigning copyright, you're getting a
| license to bundle the contribution with the rest of the
| package.
|
| And they don't feel safe including a patch without a
| license to use it. Not an unreasonable position to take.
|
| The wording is explicit (italics mine):
|
| > You hereby grant to the Company and to recipients of
| software distributed by the Company a perpetual,
| worldwide, non-exclusive, no-charge, royalty-free,
| irrevocable copyright _license_ to...
| warkdarrior wrote:
| Yes, the CLA says that you give them a license for them
| to in turn sublicense your code to others in any way they
| want.
| pxc wrote:
| When you contribute code to an AGPLv3 project _without_ a
| CLA, you are _also_ giving them a license to use your
| code. The name of that very license is... 'APGLv3'!
|
| The CLA means you're giving them an _additional_ license:
| one that lets them do things that the AGPLv3 wouldn 't,
| like use your code in proprietary software.
|
| This is common for FOSS-maintaining organizations that
| want to use dual-licensing as part of their revenue
| strategy. Users (including organizationswho are
| comfortable publishing any downstream changes they might
| make under the terms of the copyleft license use the free
| version. Users who are not can instead choose to purchase
| a proprietary license, like they would with closed-source
| software.
|
| Often there's some hope that as users of F/OSS, the
| developers and users are overlapping groups, and there's
| enough alignment of interests there to provide some level
| of assurance that the developers (or publisher, in the
| case of a corporation or collective entity) won't
| suddenly make drastic changes without user input. (Often,
| too, that isn't actually the case.) A CLA can give the
| developer the ability to make such drastic changes as
| taking a copyleft project and creating a closed-source
| fork. In cases where the development work is supplied
| predominantly by a single commercial entity, that means
| that they can essentially orphan the project out from
| under you, leaving the open-source version of their
| software an unmaintained vestige of a proprietary
| commercial offering, at any time.
|
| So CLAs involve a lot of trust or a lot of risk. Some
| companies have set up non-profit foundations to be the
| official stewards of their dually-licensed software so
| that the chief/commercial maintainers of the software can
| leverage the dual-licensing revenue strategy while
| fostering strong community trust. See, for example, the
| Free Qt Foundation. When Google wanted a CLA as insurance
| against patent litigation for Kubernetes, they did a
| similar thing and set up the Cloud-Native Compute
| Foundation so that Kubernetes could have a 'trustworthy
| CLA', so-to-speak.
|
| I hope that clears up both why upstream developers might
| sometimes want a CLA of this kind and why downstream
| developers can sometimes be leery of them.
| gumby wrote:
| TL;DR: my quick read is that they are trying to do the
| right thing.
|
| My not super-close reading is that this is actually
| reasonable (but note: I wrote the original GNU blanket
| assignment back around 1989 or 1990 so you may consider my
| perspective bogus).
|
| This agreement says that you confirm that you have the
| right to license your contribution (that what you wrote
| isn't actually your employer's), and that they can use it
| without restriction, even if there's something patented in
| the submission. It doesn't stop you from using the code for
| something else. But you can't come back later and say "hey,
| yank out these lines of code which I sent you long ago".
| It's not even an assignment -- you retain ownership.
|
| If I were doing this, personally, I might add something to
| the effect of "btw if the company tries to change the
| license in a way incompatible with the AGPL 3.0 or later
| versions this license I have you becomes void" but that
| could implicitly be in there (if explicit, I missed it in
| my quick read).
| dns_snek wrote:
| Interesting. I think concerns about legality of
| contributions are completely understandable.
|
| But doesn't this CLA in particular (and most CLAs out
| there generally) assign the company behind it a license
| to distribute all contributions under any license they
| wish? Specifically the part that I quoted where
| contributors give them an "irrevocable copyright license"
| to "sublicense" their contributions?
|
| As far as I understand, this allows them to unilaterally
| re-license the project as a whole (to proprietary or non-
| free open source) without asking contributors for
| permission.
|
| The only way I'd agree to a CLA is if it included
| explicit language that ensured that they couldn't do
| this, e.g. "You hereby grant [...] under the terms of the
| AGPL v3 license", but I'm not a lawyer.
| the_mitsuhiko wrote:
| > As far as I understand, this allows them to
| unilaterally re-license the project as a whole (to
| proprietary or non-free open source) without asking
| contributors for permission.
|
| That's generally how CLAs work, to enable re-licensing.
| For many commercial AGPL projects that's also needed
| because the copyright holding entity will sell/provide
| non AGPL versions to customers that legally cannot use
| AGPL software.
| thisislife2 wrote:
| Note that they can't "take it away" completely. The AGPL
| ensures that the community AGPL licensed code will always have
| to be open source, and that anybody else can use it too. So a
| developer who has contributed to an AGPL codebase cannot be
| denied access to it. Due to the AGPL license, any code will
| always be open source and thus the CLA cannot claim exclusivity
| over the contributed code and prevent its (re)use by the
| developer in any manner.
|
| The only concern then is ethical - will the developer be
| monetarily compensated if the product makes money? I believe
| they should be. Other open source developers may disagree.
|
| Note also that for a commercial open source project, a CLA can
| offer some legal protection - by signing a CLA a developer
| declares that they own the copyright on the code, which reduces
| the liability of the commercial venture behind the open source
| product if someone contributes "pirated" code.
| trueismywork wrote:
| You don't need CLA for legal protection, Developer
| certificate of origin is enough. https://en.m.wikipedia.org/w
| iki/Developer_Certificate_of_Ori...
| philippemnoel wrote:
| We've looked into the DCO before. It turns out CLAs are
| more common and easier to deal with, thanks to a tool like
| cla-assistant.io. We ended up opting for it for the sake of
| simplicity.
| notpushkin wrote:
| You can use DCO legal text with CLA Assistant though!
| saul-paterson wrote:
| It's not a good argument, smoking was once very common
| and still is common in many parts of the world.
|
| https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
| quectophoton wrote:
| Is this actually legally binding? What would be the
| difference w.r.t. informed consent, between DCOs and the "I
| have read and accept the terms and conditions" checkboxes
| from most websites?
|
| It also gives me similar vibes to the Do-Not-Track HTTP
| header since both can be enabled by default.
| thyristan wrote:
| DCO is something like "Signed-of-by: me myself
| <me@example.com>" you have to actively add to your
| contributions, which is usually a conscious and willful
| act that is far more complex than blindly ticking a box
| (or even leaving a pre-ticked box ticked). Since that bar
| is higher, I think the legal weight should be higher.
|
| CLA-Assistant is also similarly simple to fill out, so
| that can't be the difference there...
| johnny22 wrote:
| The linux kernel relies upon one, so I can't imagine it
| wouldn't be.
| the_mitsuhiko wrote:
| > The AGPL ensures that the community AGPL licensed code will
| always have to be open source, and that anybody else can use
| it too.
|
| That's true in the sense that there will always be an AGPL
| version, but it's not true that "anybody else" can use it to.
| In many situations you need to acquire a non AGPL license
| from the original copyright holder to be legally able to use
| the software in certain environments. That's why CLAs are
| important so that there is always a copyright holder that can
| give you a non AGPL version.
| wittystick wrote:
| In practice, projects that take this approach do the majority
| of development in house, and external contributions are small.
| It makes sense that a company that may have spent several years
| developing a product can sell commercial licensing. The only
| alternative way to monetize AGPL works is to provide services
| and support.
|
| Nobody is forcing anyone to give away their rights. You can
| always distribute contributions under AGPL in a forked repo.
|
| The alternative is that if you're making meaningful
| contributions then it's in the company's best interest to hire
| you full time to do it.
|
| Contributing upstream can benefit the ecosystem around the
| project, and the money that comes from commercial licensing
| also benefits it. In some cases the project would die if it
| didn't have the commercial side. They're not running a charity
| and if they aren't generating enough revenue they'd likely be
| working on something else rather than maintaining a FOSS
| project that doesn't make any money.
| pxc wrote:
| I love single-license-per-project F/OSS companies like Red
| Hat, but they're rare. I'm attracted to companies who are so
| committed to F/OSS as a practice that their software is
| copyleft and they don't require a CLA.
|
| But dual-licensing is a tried-and-true strategy and the basic
| premise is very clear and very fair: share your downstream
| changes or pay a fee. And a CLA is required to make that
| work.
|
| Something commenters here seem to miss is that all
| permissively licensed software is vulnerable to the same kind
| of maneuver that copyleft+CLA software is. If MIT or Apache
| don't scare you, neither should GPL+CLA.
| tgma wrote:
| There are clear differences. [Let's say I am not a
| competitor and Amazonifying them] I can keep using a
| permissively licensed software or a fork of it at the
| moment they pull the rug and keep using it in the same
| manner; I just don't get future updates. I cannot fork AGPL
| and use it commercially in any reasonable manner.
|
| Even worse, let's say I am a paid customer for their
| support and run on their proprietary license. Once they rug
| pull or jack up the prices or whatever, I cannot fall back
| to AGPL hosted locally. If it were permissive I would have
| had other options.
|
| AGPL I fully respect as Free Software. AGPL+CLA, however,
| is not your friend and is pure deception. If you are a
| sufficiently large commercial entity, you are probably wise
| to act as if it is proprietary. In fact, it might be
| slightly worse as folks are sometimes cavalier in accepting
| contributions without proper copyright license/assignment
| and they pass them on to you under their paid license and
| expose you to some risk.
| lmm wrote:
| > I can keep using a permissively licensed software or a
| fork of it at the moment they pull the rug and keep using
| it in the same manner; I just don't get future updates.
|
| That part is exactly the same under AGPL, no?
| tgma wrote:
| Strictly speaking you are correct. I concede that from an
| individual licensee perspective. The scenario I had in my
| head is under permissive, if the community forks, they
| would be on par with the original author. Under AGPL+CLA,
| if the community forks, the original author can sell
| "usable" licenses but the fork community will be stuck to
| developing an AGPL-only solution, which is a practical
| hinderance for the new community gaining any ground at
| all.
| pxc wrote:
| > I can keep using a permissively licensed software or a
| fork of it at the moment they pull the rug and keep using
| it in the same manner; I just don't get future updates. I
| cannot fork AGPL and use it commercially in any
| reasonable manner.
|
| You can fork it and use it in and as free software
| forever. This is only 'unreasonable' if you're a
| proprietary software vendor. The complaint of a
| proprietary software vendor strikes me as somewhat ironic
| here: what, the same deal that you give to your own
| customers for your own product is one you simply 'can't'
| take yourself because it's not 'reasonable'?
|
| > If you are a sufficiently large commercial entity, you
| are probably wise to act as if it is proprietary.
|
| But right about this. In the scenario you describe,
| you're a customer under the _proprietary_ license-- the
| kind of dependency your proprietary software product has
| on the software is the same kind it might have on any
| other proprietary software. The AGPLv3 version is not a
| backup option for you.
|
| And it's true that the dual-licensing game the original
| vendor has set up is one that only _they_ will ever be
| allowed to play.
|
| If my company were considering purchased dual-licensed
| AGPLv3 software, I'd give advice like the following:
|
| > It's great for the wider public that there is an open-
| source version of this exact same software our there. But
| what we're considering buying here is not that-- what
| we're considering buying is proprietary software. For us,
| all that the availability of that open-source license
| means is that this is proprietary software whose source
| code would be easy for us to inspect, and that upstream
| might even accept our patches for issues that we
| encounter. I think both of those things are huge
| advantages! But if this vendor gets bought out or
| shuttered, we could potentially be left in the lurch much
| as we would if the software were exclusively proprietary.
| That's often an acceptable risk, in my opinion, and it's
| certainly one that our company has deemed acceptable with
| many past and present proprietary software purchases. But
| we should note that on the assessment: if we buy this,
| we're not buying or depending on open-source software;
| we're buying and depending on proprietary software.
|
| All that assuming, of course, that the proposition is to
| use the AGPLv3 software in a user-facing, proprierary web
| service under the assumption that the copyleft component
| of the AGPL extends to that web service. If we were
| evaluating it for use in an _internal_ service, where the
| end users are our own employees, or an external-facing
| service that we 'd be comfortable releasing under the
| GPL, or we think that the way we want to use it would not
| require any license changes for us even if we take thw
| AGPLv3 version, I'd instead say something like
|
| > Ask the lawyers as always, but I don't foresee any
| problems. I think this is great and I'd love to use it.
| If our legal people aren't used to considering copyleft
| licenses, can we have them consult with the FSF or the
| SFC or the EFF or something before they make a decision
| about this? Is that a thing?
|
| Anyway, I agree with you about how being the customer
| (under the proprietary license) of a company like this is
| different from being the customer (for support services
| only) of a company who publishes permissively-licensed
| free software. I don't agree, though, that the dual-
| licensing thing is a trick! I think it's totally possible
| for everyone to go into that kind of arrangement eyes
| open and be happy with it. I hope and expect that's the
| goal for companies like that of TFA.
| tgma wrote:
| > You can fork it and use it in and as free software
| forever. This is only 'unreasonable' if you're a
| proprietary software vendor. The complaint of a
| proprietary software vendor strikes me as somewhat ironic
| here: what, the same deal that you give to your own
| customers for your own product is one you simply 'can't'
| take yourself because it's not 'reasonable'?
|
| I am not discussing ethics or morality here, just
| practicality, and yes, from the perspective of a user
| that is not primarily releasing open source. Note that
| it's somewhat different and more general than your
| characterization. I might be in another business, not
| software, but unwilling to touch AGPL within my
| infrastructure due to risk of virality. Strictly
| speaking, I am not a "proprietary software vendor" as I
| am not even in the software business, primarily.
| Nevertheless, your general point stands.
|
| I am not arguing it is bad. Simply that I would not
| characterize AGPL+CLA as "no vendor lock-in because open
| source." I put it right in the bucket of e.g. Oracle
| proprietary database. I am not saying it is bad or
| totally unreasonable. I just don't buy up the marketing
| koolaid.
| philippemnoel wrote:
| Blog author here -- I couldn't have said it better. If you'd
| like to meaningfully contribute to the project, we're hiring
| :)
| baq wrote:
| They can always pay you to sign the CLA... works both ways.
| kelnos wrote:
| Honestly I think this is fine, especially how they've done it.
| Most CLAs seem to require copyright assignment, but theirs does
| not. Outside contributors keep their copyright, but grant the
| company a license to (more or less) do whatever they want with
| it.
|
| I think we're at a bit of a crossroads here. Enough (smaller)
| companies have been bitten by the likes of Amazon monetizing
| their code and crushing the original developers' monetization
| strategy. So we see some companies turning to non-F/OSS "source
| available" type licenses instead. This is bad for the open
| source community as a whole.
|
| IMO, AGPL+commercial is a fine compromise, and companies need
| to be certain that if they take contributions from the
| community, that they can still sell commercial licenses for the
| whole product, including the contributions, without issues in
| the future. Requiring contributors to assign copyright is one
| simple way to do that, but I think the path this company has
| chosen is a lot nicer in letting contributors keep ownership
| over their contributions.
|
| For a piece of software where the expectation is that the
| company is going to be doing 90% of the work, and outside
| contributions will be relatively small, this seems entirely
| fair to me.
| matheusmoreira wrote:
| And as a result free software was released to the world which
| _everyone_ can freely use and modify under the AGPLv3 terms.
| And unlike permissive open source licenses, _only_ the
| copyright owners have the right to sell proprietary versions.
| They maximized freedom and secured a business model in one fell
| swoop. People are only required to transfer copyright if they
| want to upstream their code, they can always keep their
| copyrights by maintaining a fork instead.
|
| It's pretty much perfect. Stallman himself suggests selling
| exceptions to the GPL as a viable business model for companies,
| Qt being the number one example. I actually emailed Stallman
| and asked what he thought about this new AGPLv3 SaaS pattern,
| here's his reply: > It is my understanding that
| as the copyright holders > they have the right to do it
| without any problems. > They leverage the AGPLv3 to make
| it harder for their > competitors to use the code to
| compete against them. I see what you mean. The
| original developer can engage in a practice that blocks
| coopertation. By contrast, using some other license,
| such as the ordinary GPL, would permitt ANY user of the
| program to engage in that practice. In a perverse sense
| that could seem more fair, but I think it is also more
| harmful. On balance, using the AGPL is better.
| jay_kyburz wrote:
| I don't understand why they say
|
| "Future-Proof: Thanks to the copyleft provision, cloud vendors
| cannot easily resell our project without our consent. This gives
| us confidence in our ability to monetize without fear of
| predatory competition. ParadeDB just turned one year old, and
| we've already been contacted by four cloud providers who, had we
| not chosen the AGPL license, may have privately forked and
| distributed ParadeDB."
|
| Nothing in the license requires cloud vendors from reselling the
| project. They just need to make the source available?
|
| What am I missing?
| warkdarrior wrote:
| I think AGPL requires the whole cloud stack that's used by a
| deployment of this SW to be AGPLed as well.
| wavemode wrote:
| This is a common misconception. Nothing in the text of the
| AGPL requires this whatsoever.
|
| But it's a common enough misconception that my personal
| recommendation tends to be to just steer clear anyway, if
| you're planning to run a closed-source business. It's better
| to not get sued at all, than to get sued by someone who's
| wrong.
|
| But for reference, the only text added to the AGPL in
| comparison to the GPL is section 13 here:
|
| https://www.gnu.org/licenses/agpl-3.0.en.html
|
| In other words, if you run an AGPL database and modify it,
| you need to provide your users with the source of your
| modified version.
|
| Nothing remotely suggesting that the rest of your entire
| software stack becomes AGPL licensed. (In fact I often wonder
| how people are imagining that would even work. It would
| basically imply that you can't, for example, run AGPL
| software on a Windows server...)
| jay_kyburz wrote:
| I spent some time reading about static linking and dynamic
| linking. From the FAQ > "Linking a GPL
| covered work statically or dynamically with other modules
| is making a combined work based on the GPL covered work.
| Thus, the terms and conditions of the GNU General Public
| License cover the whole combination"
|
| If I had to guess, if you installed each application in
| your stack separately, and they simply interacted with each
| other through API calls, you could consider them "System
| Libraries" and therefore would not dragged into the AGPL.
| Example, The OS itself, Node, Postgres, and any other 3rd
| party applications. As long as you are not distributing
| them, I think they would count as System Libraries.
| > "To prevent unscrupulous distributors from trying to use
| the System Library exception as a loophole, the GPL says
| that libraries can only qualify as System Libraries as long
| as they're not distributed with the program itself. If you
| distribute the DLLs with the program, they won't be
| eligible for this exception anymore"
| wavemode wrote:
| The System Library exception isn't even needed. The key
| word in what you've quoted is "linking". If you aren't
| linking, then you aren't creating a combined derivative
| work at all.
|
| Linking in this context refers to a very specific thing:
| https://en.wikipedia.org/wiki/Linker_(computing)
| jay_kyburz wrote:
| If true, this license does nothing to mitigate the risk that
| a user may get locked into contracts they don't like, or the
| ability to continue to use the software if the developer goes
| bankrupt or is bought by a competitor.
|
| If you can't use the AGPL version now, you can't use it later
| either.
|
| And I don't see how it prevents "Cloud Vendors" from using
| it, but not everybody else as well.
| sfink wrote:
| Even if the (CLA-owning) organization changes the license,
| the last version available under the AGPL will always be
| available under the AGPL.
|
| > If you can't use the AGPL version now, you can't use it
| later either.
|
| Right. But you can use it now and later.
|
| > And I don't see how it prevents "Cloud Vendors" from
| using it, but not everybody else as well.
|
| Cloud vendors _can_ use it. What they can 't do is fork it
| and start making private changes that they do not release
| for others to use. Forking it is fine, making incompatible
| changes is fine, but keeping those changes proprietary is
| not.
|
| The AGPL defends against competition from a big cloud
| operator, but not in the way you're thinking. It does not
| prevent the cloud operator from using or even modifying the
| software. It does prevent that operator from creating a
| competitive fork that benefits from starting with the AGPL
| code but then diverges in a way such that customers will
| want to pay the cloud operator for their up to date fancy
| version _instead_ of the original project. I mean, they
| still could try to get people to pay for that, but the
| original project will have access to all of their changes
| so the cloud operator won 't have any advantages when
| selling support or a license with different terms.
| chii wrote:
| > but the original project will have access to all of
| their changes so the cloud operator won't have any
| advantages when selling support or a license with
| different terms.
|
| Those changes would be under some sort of AGPL and the
| original project cannot merge it back, while still
| maintaining their option of a commercial license.
|
| So once the original project merge any of their
| competitor's changes/forks, their project becomes AGPL
| only, and lose the ability to charge for a commercial
| license as a monetization strategy.
| jay_kyburz wrote:
| So I guess what you are saying is that the business model
| is that cloud vendors will buy a license, but only if
| they they want to make changes to the code, but not
| release those changes.
|
| So not just small changes, big changes that have a
| significant value-add, and not easily replicated. It
| assumes cloud vendors will want to start building a
| business on top of this critical dependency.
|
| It doesn't sound like a great deal for the cloud vendor.
|
| I assume we are really only talking about Amazon,
| Microsoft and Google, and the developer hopes to just get
| bought rather than messing around with licenses.
| runningmike wrote:
| Nothing. There is no need for consent. Just fork it and respect
| the agpl. You can do what you want as long as you respect the
| AGPL. So reselling is allowed.
| purpleidea wrote:
| The fact that they aren't mentioning their CLA which gives them
| extra rights that everyone in the community doesn't get means
| they're disingenuous in writing this article...
|
| As an analogy it's as if someone was selling you a new car, but
| neglected to tell you that it doesn't come with a steering wheel
| or tires.
|
| Be transparent and tell the whole story, don't be sneaky.
| jenadine wrote:
| The analogy is a bit strong. You make it sound like the CLA is
| a limitation to the product. But the CLA doesn't't limit the
| product in any way.
| contrarian1234 wrote:
| Is there some AGPL equivalent on top of GPLv2 instead of GPLv3
|
| After reading the rational for v2 for the Linux kernel, Ive
| always found v3 a bit off putting.
| lmm wrote:
| What rationale would that be? I doubt the FSF would write a
| version of the AGPL designed to let you use DRM to end-run
| around it if that's what you're getting at (you can always
| write such a license yourself, but, why?)
| contrarian1234 wrote:
| I mean ... Not to rehash all the v2 VS v3 arguments ... But
| essentially you only care about the source code being shared
| and you don't care about tivoization and forcing additional
| hardware requirements or requirements that "used code" is
| changeable by endusers.
|
| The AGPL's extension just increases any modified code's
| availability. It's extending the principles behind v2 to
| networked devices. You gotta share your changes and you can't
| cleverly avoid it by doing a SaaS instead of selling
| software/hardware
|
| It doesn't extend the v3 principles (which increase end
| user's rights). That would be to force companies to allow
| users to modify and run modified code on the networked
| device/server (which would be the networked equivalent of a
| anti-tivoization).
|
| So the AGPL's idea pairs more naturally with v2 in my opinion
| globular-toast wrote:
| The "Tivo-isation" clause? You'd want AGPL but without that
| bit? That would be strange. I doubt Linus likes AGPL either
| because, unfortunately, his relationship with the FSF is always
| going to be sour. He's one of most stubborn people on earth
| (for better or worse).
| contrarian1234 wrote:
| As I say in the neighboring comment, I think the two
| compliment each other a lot more than v3. Linus would get
| even more code contributions .. I think he'd be happy
| teddyh wrote:
| The AGPL is based on the "Affero GPL". The Affero GPL v1
| (AGPLv1) was based on GPLv2.
|
| (I also disagree with your feelings about the GPLv3, and think
| you should be using the normal AGPLv3.)
| jan_g wrote:
| I don't know about ParadeDB, but this was very off-putting for me
| in case of Minio when they switched to AGPL. If you check their
| answers to various license questions, they are essentially this:
| if you use Minio in your stack/product (for profit), then we
| recommend our commercial license or consult with a lawyer if your
| use case is covered by AGPL or not.
|
| What me and I guess many others wanted was a simple yes/no to the
| following: if I use Minio in my stack without modifications (as a
| file server that my other services interact with via an API), do
| I have to AGPL all the stuff the touches Minio or not? And they
| do not want to answer this question. I do not understand why is
| it so hard to answer clearly. I understand that the majority of
| opinions is that it's fine to use without modifications, but I
| wanted a clear statement from authors of Minio. Failing that, I
| then decided to keep the pre-AGPL version for a while and have
| transitioned away from Minio since then.
| knorker wrote:
| IANAL, but I'd also be worried that even if the project answers
| your question, maybe any one individual contributor to the
| project could sue you if they disagree.
|
| Only if the project doesn't have copyright reassignment, of
| course.
| camgunz wrote:
| No, the whole idea of the AGPL is to make you release
| modifications even if you're not distributing (i.e. a web app).
| No modifications, no release.
| dspillett wrote:
| The question isn't about modifications to the library/service
| itself, but whether with other code linking to it in any way
| is what you have considered a derivative work that should
| also be covered by the AGPL.
|
| For a library I'd say that was a definite yes. For a service
| it is someone's less clear, some provide connective tissue
| (language bindings or other access modules) under less strict
| licenses which creates an obvious break in the chain, without
| that or very definite answers to the question on the post you
| replied to it is unclear how tightly coupled you need to be
| to need to use AGPL for your own work and I would err on the
| side of assuming (because it is GPL based) _any_ coupling
| would have that effect.
|
| Not that this would put me off using LGPL, but it is just as
| disconcerting, if not more so, to commercial interests, as
| the GPL is.
| franga2000 wrote:
| The "any coupling" logic would also make anything running
| on Linux GPL, which is definitely not the case. Using
| background service such as Minio as an unmodified black box
| for data storage as part of your app is unambiguously not
| derivative work. If you were to write something like a
| management UI for Minio and offer it with your hosted Minio
| service, then I can at least see the argument, although it
| still doesn't count under my reading of the AGPL.
| actionfromafar wrote:
| The Linux GPL license has an explicit excemption for
| binaries running under Linux. So it's not a great
| example.
|
| https://github.com/torvalds/linux/blob/master/LICENSES/ex
| cep...
| camgunz wrote:
| Well that's not Op's question. They're asking "if I use
| Minio in my stack without modifications (as a file server
| that my other services interact with via an API), do I have
| to AGPL all the stuff the touches Minio or not?" (Minio is
| basically a FOSS S3) [0]. You're asking about linking,
| which is covered in the FAQ [1]:
|
| "You have a GPLed program that I'd like to link with my
| code to build a proprietary program. Does the fact that I
| link with your program mean I have to GPL my program?"
|
| "Not exactly. It means you must release your program under
| a license compatible with the GPL (more precisely,
| compatible with one or more GPL versions accepted by all
| the rest of the code in the combination that you link). The
| combination itself is then available under those GPL
| versions."
|
| [0]: https://min.io/
|
| [1]: https://www.gnu.org/licenses/gpl-
| faq.html#LinkingWithGPL
| richardwhiuk wrote:
| That's GPL, not AGPL. The AGPL license implies that
| communicating with it over the network is sufficiently to
| count as a violation.
| camgunz wrote:
| If you diff them, you'll see the AGPLv3 is essentially
| the GPLv3 with this extra clause added:
|
| "13. Remote Network Interaction; Use with the GNU General
| Public License.
|
| 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. This Corresponding Source shall
| include the Corresponding Source for any work covered by
| version 3 of the GNU General Public License that is
| incorporated pursuant to the following paragraph."
|
| Therefore, what I said about linking applies to both.
|
| To be clear, you only have to offer source code if you've
| modified an AGPLv3 program and you're distributing it
| publicly or "interacting with it remotely through a
| computer network (if your version supports such
| interaction)". Op's scenario neither modifies Minio nor
| distributes it, so they're under no obligation to offer
| source.
| goodpoint wrote:
| > if I use Minio in my stack without modifications (as a file
| server that my other services interact with via an API), do I
| have to AGPL all the stuff the touches Minio or not
|
| No and it's spelled out very clearly in the license.
| zadokshi wrote:
| No it is not clearly spelled out. So I am wondering why you
| think it is clear. Perhaps you are misunderstanding the
| problem that is being raised? I'm not sure.
| haytamoptika wrote:
| https://www.gnu.org/licenses/gpl-faq.en.html "However, in
| many cases you can distribute the GPL-covered software
| alongside your proprietary system. To do this validly, you
| must make sure that the free and nonfree programs communicate
| at arms length, that they are not combined in a way that
| would make them effectively a single program."
|
| I think you can interact with GPL/AGPL and retain your code
| propietary by:
|
| - Don't modify the AGPL program.
|
| - Run separatly, using docker container, vm etc
|
| - Interact with CLI, REST API, filesystem, database etc
|
| - Keep the AGPL interaction only to your program, non public
| consumption, minimum the surface of distirbution the code.
|
| - Keep your code non directly interact, such as avoid use
| node npm dependencies directly, avoid library linking, use
| api gateway, use thirdparty module.
| demurgos wrote:
| You linked a more general FAQ for the GPL. Would you have a
| more specific quote or link for interactions with AGPL
| code?
| misterio7 wrote:
| AFAIK, the difference between AGPL is GPL is on what
| constitutes "distribution"; what constitutes a
| "derivative" is still the same.
|
| https://drewdevault.com/2020/07/27/Anti-AGPL-
| propaganda.html
| camgunz wrote:
| "In AGPLv3, what counts as 'interacting with [the
| software] remotely through a computer network?'"
|
| "If the program is expressly designed to accept user
| requests and send responses over a network, then it meets
| these criteria. Common examples of programs that would
| fall into this category include web and mail servers,
| interactive web-based applications, and servers for games
| that are played online."
|
| "If a program is not expressly designed to interact with
| a user through a network, but is being run in an
| environment where it happens to do so, then it does not
| fall into this category. For example, an application is
| not required to provide source merely because the user is
| running it over SSH, or a remote X session."
|
| [0]: https://www.gnu.org/licenses/gpl-
| faq.html#AGPLv3InteractingR...
| ashkankiani wrote:
| "This License explicitly affirms your unlimited permission
| to run the unmodified Program."
|
| In the Basic permissions of the actual content of the
| license https://github.com/minio/minio/blob/master/LICENSE
|
| It's not that difficult to parse if you actually read it
| top to bottom instead of skimming.
| afro88 wrote:
| Github may have it wrong then? Their summary says:
|
| > Permissions of this strongest copyleft license are
| conditioned on making available complete source code of
| licensed works and modifications, which include larger
| works using a licensed work, under the same license.
|
| Note the last part: "which include licensed works using a
| licensed work"
| xyzzy_plugh wrote:
| No, GitHub has it exactly right. Ultimately this sort of
| thing has to be settled in court.
| camgunz wrote:
| At least in the EU there's some precedent where AGPLv3+
| won out, though it was through settlement and not
| judgement (and it's not super clear how contentious the
| parties were anyway) [0]
|
| [0]: https://archive.fosdem.org/2021/schedule/event/agplc
| omplianc...
| camgunz wrote:
| Yeah I wouldn't rely on their editorializing. It's best
| to just refer to the FAQ [0], which covers these
| questions.
|
| [0]: https://www.gnu.org/licenses/gpl-faq.html
| mrbluecoat wrote:
| I think the length of this HN discussion is evidence enough
| that AGPL isn't clear.
|
| In my experience, organizations that use AGPL do so to 1)
| ward off an active non-paying community with its associated
| support cost, 2) claim open source to help convince you to
| buy their software/service, 3) hire skill-vetted programmers,
| 4) allow third-party security audits, and/or 5) avoid being
| jaded by someone that can market or host their solution
| better than they can.
| camgunz wrote:
| It can also be evidence that HN posters have a poor
| understanding of GPL licenses. Pretty much all these
| questions are answered in the FAQ [0]. Your guess is as
| good as mine as to why people continually post random,
| uninformed, needlessly conservative takes on them instead
| of just doing a small amount of reading.
|
| [0]: https://www.gnu.org/licenses/gpl-faq.html
| SpicyLemonZest wrote:
| The FAQ is not at all clear about this question.
| #GPLInProprietarySystem says that you unconditionally
| cannot "incorporate GPL-covered software in a proprietary
| system", although it might be OK to ship a proprietary
| system that integrates with and depends on GPL software
| so long as "the two programs remain well separated". How
| do I know whether a particular API usage qualifies as
| well separated or not? The only standard described is
| "like the compiler and the kernel, or like an editor and
| a shell".
| camgunz wrote:
| > How do I know whether a particular API usage qualifies
| as well separated or not?
|
| The two paragraphs above what you quoted are:
|
| "However, in many cases you can distribute the GPL-
| covered software alongside your proprietary system. To do
| this validly, you must make sure that the free and
| nonfree programs communicate at arms length, that they
| are not combined in a way that would make them
| effectively a single program."
|
| "The difference between this and 'incorporating' the GPL-
| covered software is partly a matter of substance and
| partly form. The substantive part is this: if the two
| programs are combined so that they become effectively two
| parts of one program, then you can't treat them as two
| separate programs. So the GPL has to cover the whole
| thing."
|
| Two programs communicating over a socket aren't
| incorporated. They're two programs.
| SpicyLemonZest wrote:
| Again, the FAQ says otherwise. #MereAggregation says that
| this is "normally" the case, but "if the semantics of the
| communication are intimate enough" two binaries
| communicating over a socket may still be one program.
| Whether they _are_ one program is explicitly left as a
| question for judges to decide.
| camgunz wrote:
| Here's how that section starts: "An "aggregate" consists
| of a number of separate programs, distributed together on
| the same CD-ROM or other media.". Are you distributing a
| lot of apps on CD-ROMs? Have you heard of Linux
| distributions? Seems like things are fine!
|
| I'm not super interested in fielding more thin gotchas
| based on out of context quotes. There's a big difference
| between a license that's difficult to understand and a
| license that somehow summons people from the ether who
| find endless ways to deliberately misunderstand it.
| g15jv2dp wrote:
| Sorry but what does "arms length" mean? My software
| doesn't have arms. Using metaphors full of imagery is
| cute but essentially meaningless.
|
| > Two programs communicating over a socket aren't
| incorporated. They're two programs.
|
| Aren't they? So, if I want to use a GPL library, all I
| need to do is write a little wrapper program that does
| RPC over a socket, and boom, I can use a GPL library in
| my closed source program? Obviously not.
| camgunz wrote:
| > Aren't they? So, if I want to use a GPL library, all I
| need to do is write a little wrapper program that does
| RPC over a socket, and boom, I can use a GPL library in
| my closed source program?
|
| Yep. This is how MySQL/MariaDB work, for example.
| pimeys wrote:
| What about when running a wasm component in an AGPL host?
| Can the compiled wasm file be proprietary? They share the
| same memory space, but the wasm component is not compiled
| with the host.
| richardwhiuk wrote:
| That FAQ covers the GPL, not the AGPL.
| camgunz wrote:
| If you ctrl-f for AGPL you'll see it's for all of it.
| afro88 wrote:
| Is it? Doesn't it depend on whether your stack depends on it
| to function, or if it is standalone that your stack can
| connect to but doesn't rely on?
| brightball wrote:
| This feels like dealing with government agencies where you go
| out of your way to get clarification to make sure you are doing
| everything correctly, but they refuse to give a clear answer to
| they can bother you about it later.
| hitekker wrote:
| A hilarious sentiment. If it's true, then these companies
| marketing their OSS creds are merely disguising their desire
| to be the next Oracle.
| ashkankiani wrote:
| Copying reply to a child comment:
|
| "This License explicitly affirms your unlimited permission to
| run the unmodified Program."
|
| In the Basic permissions of the actual content of the license
| https://github.com/minio/minio/blob/master/LICENSE
|
| It's not that difficult to parse if you actually read it top to
| bottom instead of skimming.
| jan_g wrote:
| But you forgot to cite the next sentence:
| The output from running a covered work is covered by this
| License only if the output, given its content, constitutes a
| covered work.
|
| So, what is 'covered work'? The license says this:
| A "covered work" means either the unmodified Program or a
| work based on the Program.
|
| Do you still think it's clearly written license? To me it's
| dubious enough that I wanted an explicit answer from the
| authors of Minio. Failing to get it, I decided to move away
| from Minio.
| ashkankiani wrote:
| If the output of your program is an copy of minio then it
| is also covered by AGPL is what that means. I think it's
| just covering the case where you are redistributing minio
| in a way such as decompressing and producing the output.
|
| I still don't think it's that confusing. Unlimited running
| of it is already covered without exception. The next line
| only refers to the _output_ of the covered work.
|
| If the output of your web server is redistributing minio
| then you are under AGPL
| jasode wrote:
| _> Do you still think it's clearly written license?_
|
| Fyi... a few Google employees talked about similar
| ambiguous interpretations of AGPL's terms and clauses by
| Google's legal team review in a past thread:
| https://news.ycombinator.com/item?id=23966778
| hitekker wrote:
| Nice link. One of the key quotes:
|
| > Perhaps if random engineers stopped calling legal
| opinion FUD and falsehoods and took a moment to listen to
| the feedback from lawyers who didn't write the license,
| we'd get somewhere with finding a palatable license for
| all parties. Instead, we get a holy war.
|
| My corollary: an argument is not a document. When I need
| a strong resolution on an issue, I want in writing and in
| a single organized voice, not spread across a bunch of
| comments and commenters, whose goal is often to shout
| down doubts or to keep the peace between participants.
|
| Besides the internet, I've seen "the-argument-is-the-
| document" occasionally inside companies and very strongly
| in a hype-driven programming language.
| kragen wrote:
| this is basically talking about compilers and things like
| dumping a memory image from gforth or emacs
|
| if someone said 'no, the output from my gpl-licensed
| compiler is never covered by the gpl', then would-be
| infringers would have an easy escape from the gpl: just
| compile the compiler with itself, and its author guarantees
| that the compiled output isn't covered by the gpl! so
| that's why the fsf carefully says 'only if the output,
| given its content, constitutes a covered work'
|
| similarly, emacs or gforth has the ability to dump a memory
| image after loading up a bunch of source code and compiling
| it to bytecode; that way it can instantly load the image
| without taking the time to recompile all that code. this
| memory image includes all the code that's loaded, including
| not just your code, but also all the standard library code
| that comes with the system. but that shouldn't give would-
| be infringers an easy escape from the gpl for the standard
| library code
| Vonng wrote:
| I fully support ParadeDB's decision. For an open-source software
| company, AGPLv3 + Dual License is the most sensible choice.
|
| If you go with Apache 2.0, you're literally doing free work for
| cloud vendors.
| codelion wrote:
| This resonated with us as well, we have also chosen AGPL as
| license for our open source project - https://github.com/patched-
| codes/patchwork
| jwildeboer wrote:
| Correct title would be ,,Why we picked dual licensing with AGPL
| and a commercial license", IMHO.
|
| You can only contribute when you accept the CLA at [1] which
| gives them the right to license your contributions under said
| commercial license.
|
| [1] https://cla-assistant.io/paradedb/paradedb
| 1ilit wrote:
| I totally get this. I recently changed the license on my project
| from MIT to AGPL after getting a dm from someone interested in
| buying the project. I make absolutely no money at the moment, if
| anything I'm paying out of pocket for the domain, and don't think
| will any time soon. My only goal was to protect the project from
| getting commercialized by someone else. I've gotten questions
| about it and have been questioning whether I got too scared that
| someone might monetize what I worked so hard on.
| braza wrote:
| Honest question: For the people not intending to "build a
| business on top of an open source library" but only intending to
| do something like "I just need this library to solve an issue in
| my work job" it's not simple to not touch it at all?
|
| I had read a lot of conversations, and to be honest it's quite
| confusing for me the risk acceptance to have AGPL code in my
| codebase.
| themacguffinman wrote:
| Most major tech companies will ban it for any use because the
| virality of it isn't clearly bounded and legally it's untested
| [1]. The stakes are high at large tech companies with valuable
| IP, so downside is huge. For whatever reason, AGPL has never
| laid exclusive claim to particularly valuable projects (even in
| this project's case, it seems like they dual license so you can
| avoid the AGPL), so the upside isn't that high. So high
| downside + low upside means major players will just err on the
| side of "no".
|
| If your company has anything to lose, I'm sure it'll have a
| lawyer and you'll want to consult them on what their risk
| tolerance is. It's confusing because the license is actually
| ambiguous, most tech companies aren't willing to accept this
| ambiguity.
|
| [1] See this opinion by a Google lawyer:
| https://news.ycombinator.com/item?id=23968783
| agpl3141592 wrote:
| It's a shitty license.
|
| If you need to patch anything due to local requirements like the
| auth system you need to publish it which doesn't make sense at
| all.
| lukekim wrote:
| We chose Apache 2.0 for the Spice OSS runtime.
|
| TL;DR: Data-plane Apache 2.0, control-plane BSL.
|
| Being such a core component, we want developers to be completely
| comfortable integrating and deploying the Spice runtime in their
| applications and services, as well as running Spice in their own
| infrastructure.
|
| In addition, Spice OSS is built on other great open-source
| projects like DataFusion and Arrow, both Apache 2.0, and DuckDB
| (MIT), so being permissively licensed aligns with the fundamental
| technologies and communities it's built upon.
|
| We expect to release specific enterprise control-plane services,
| such as our Kubernetes Operator under a license such as BSL.
|
| [1] https://github.com/spiceai/spiceai
| mrwyz wrote:
| The AGPL is great, even for business. I make a living from AGPL
| software. Lots of people generally don't like it, because AGPL
| was not written to please the largest number of developers, but
| rather to protect the basic software freedoms of end-users. In a
| sense, the AGPL guarantees more freedoms, is more free, than
| other licenses such as MIT/BSD for end-users. But depends on the
| point of view.
|
| Many developers don't like to have their freedom to steal to be
| restricted by such strong terms as those imposed by the AGPL. And
| that's a good thing for you, my fellow maintainers. It's also a
| great thing for you, dear end-users.
| baggy_trough wrote:
| "freedom to steal"?
| mrwyz wrote:
| MIT/BSD and similar ones.
| baggy_trough wrote:
| I don't know what you mean.
| mrwyz wrote:
| BSD/MIT allows you to take code without any obligation to
| contribute back.
| baggy_trough wrote:
| Using code that is freely given is not in any sense
| stealing.
| mrwyz wrote:
| Only if you think taking the work of others and profiting
| from it without contributing anything back is fine.
| g15jv2dp wrote:
| The people who did the work obviously think it's fine,
| otherwise they wouldn't have licensed it under such a
| permissive licence.
| mrwyz wrote:
| Certainly. MIT/BSD more or less says: steal away (but
| retain this license notice). In some cases that's
| desirable.
| baggy_trough wrote:
| Is it stealing if somebody gives you a present and you
| accept it?
| saul-paterson wrote:
| Steal from the users of the software, yes. It's not about
| developers, it was never really about developers if we're
| talking copyleft licenses.
___________________________________________________________________
(page generated 2024-08-14 23:01 UTC)