Why we’re changing to the AGPL license
plausible.io
plausible.io
Major respect for recognizing that and not doing anything like dual licensing or CLAs (at least as far as I can tell).
EDIT: Asking because I'm genuinely interested in this issue and am currently making license choices myself - not trying to have a go!
Next step is really to consider what we want to do in the future and if necessary add a CLA before we merge next contribution.
We never planned to do any commercial licenses (we're focused on our Cloud offering) but it seems like a valid option in case of these corporations who want to resell our product but not open source their modifications.
I would definitely urge you to consider this very soon: AFAIK you can't do any commercial licenses with AGPL without A) some form of dual license and CLA or B) just never accepting pull requests from anyone.
But also, does this also apply to your own cloud hosted offering? Without sorting this out, all the software in your cloud hosting product now has to be fully open-source. And I get that's your philosophy, but would there not be any tiny bit you want to keep closed - maybe the anti-fraud stuff around your billing system, for instance?
This seems a key point that I'm very interested in, so sorry for pushing!
This is incorrect. If you own copyright on something you can transfer those rights to other people in any way you want.
I can give you a copy of my software under AGPL and another copy under a completely different license and the two things are independent from each other.
There isn't a "remove the copyleft restrictions" mechanism.
You can simply give out a new copy with a closed license that allows, for example, execution as a service, static linking, dynamic linking but no copy.
You can get around this by requiring copyright assignment from all contributors, or by making contributors sign an agreement that allows you to do what you want to do.
Looks like they are doing something like dual license? Can the company comment and clear this up?
Others can also provide hosted services, They can't get a competitive advantage with proprietary "value-adds." Usually, the authors have significant reputation and branding advantage, so unless they f- up, competitors are bottom-barrel low-cost providers.
AGPL without CLA is whom I tend to gravitate to.
It's nice, but in my opinion there is nothing wrong with doing it either. It might be even good thing if it ensures stability of the developer. If it turns out the original developer with dual licence/CLA is no longer good, community can continue from the AGPL version on its own and if the original developer wants to incorporate these new community changes, the AGPL will "infect" the dual licensed version.
If I'm buying into an open ecosystem, it's because I want an open ecosystem. I don't want a use-open-to-gain-market-dominance-and-than-milk-customers ecosystem.
AGPL is ideal for things I don't need to link proprietary code to.
What I most want is a plausible, paid, AGPL competitor to GSuite.
Yes, folks, if you don't like the idea of a corporation taking your ("software-as-a-service") code and using it to create and sell proprietary products, then maybe don't license your code under the MIT License (or any of the others which explicitly allow exactly that)!
I apologize for stating something that's common sense but apparently, as they say, "common sense ain't so common".
The MIT License is my preferred Open Source License but the AGPL is completely acceptable, too. In fact, if you (intend to) form a legal entity and sell your code as a SAAS product, the MIT License is quite likely NOT the license you should choose!
I don't blame these guys a bit for switching to the AGPL now but I can't stress enough that selecting the proper open-source license is an important decision for any "serious" project. Please make sure that you understand exactly what the terms of your chosen license really mean before you decide on it -- and if your stated goal is to "grow a sustainable open-source project", well, the MIT License (and similar) is almost certainly not the best choice.
--
ETA: Also, props to Plausible for choosing the AGPL as the license going forward. As mentioned, going closed source would have been the "easy choice". Alternatively, you could have selected something like the "Commons Clause" or one of the other recent "open-source but not actually open-source" licenses. In my opinion, the AGPL was absolutely the best choice. I've never used your product -- or even heard of it before now -- and probably never will but thank you for your contributions to open-source nonetheless!
As for scripting languages, encrypted custom loaders are relatively common.
The reason that enterprise uses Matlab (over Octave for example) is generally the availability of the various toolboxes. These are libraries that let you accomplish certain tasks easily. For instance, we use the Signal Processing toolbox regularly to prototype signal processing approaches or investigate system performance.
[1] https://serverjs.io/ => a generic well configured Node.js server, there's a chance of selling either the lib itself or plugins.
[2] https://react-test.dev/ => a WIP (frozen right now) project, it works great and integrates nicely with React libraries.
Also, for the record: if you _are_ considering LGPL, you should consider EPL or MPL license instead. The reason is that Apache Foundation and Eclipse Foundation are not happy to allow LGPL dependencies in their projects, while EPL and MPL are also copyleft with a limited scope just like LGPL.
You certainly don't need to licence it to yourself.
For example, I release my code into the public domain to the extent possible. But I am also very strongly opposed to plagiarism. Yet putting code into the public domain means people can legally plagiarize my work.
The real problem is copyright law. Copyright lasts for an absurdly long time, the DMCA which makes it illegal to circumvent copy protection is a threat to general-purpose computing, damages if you lose a copyright case can be astronomical and bankrupt anyone, copyright trolls sue people using stuff instead of using the copyrighted material to make anything themselves, etc.
Copyleft and the AGPL are a judo move that uses the strength of the copyright system against it. If enough stuff were under a strong copyleft license, maybe corporations wouldn't be so enthusiastic about the copyright system. Maybe they would rediscover the benefits of the public domain, since copyright expiring would also liberate copylefted content + software. Perhaps they wouldn't actually help reduce copyright, but they might not work so hard to stop efforts to do so.
I believe that the path to a stronger public domain leads through copyleft + the AGPL. Put your software in the public domain by reducing the power of copyright law, by shortening copyright term length, by reducing the number of things covered by copyright, by putting everything in the public domain, not just the software you control.
I've had this position for well over 10 years. I know why copyleft exists, its philosophical history and how it's intended to use the copyright system against itself. But I disagree with doing that because I want government out of the business of intellectual property altogether and I don't agree with using the copyright system against itself to do it. Fundamentally, I'm opposed to the ownership of ideas at an ideological level, so I wish to relinquish as much of that ownership as I can in today's system. And that's public domain.
We could have a longer discussion, but like I said, this is totally distinct from the argument I'm making that it's not "common sense" to consider laws and ethics the same.
I just think refusing to use copyleft is unwise on a strategic level. It smells like unilateral disarmament to me. If a warlord is rampaging through the countryside putting villages to the sword, it's not good enough to say, "Hey, I don't agree with stabbing people to death." It's great if you have a plan to stop the pillaging without stabbing anyone, but if you don't, then you need to consider plans that do involve stabbing, or at the very least fielding some stabbers. There may be times when all courses of action involve moral compromise, but inaction always favors the oppressor.
Do you have a plan for fighting copyright without using copyright? If yes, then I withdraw my objection. If not, then I ask you to consider whether using copyleft is better than nothing. The oppressive copyright system will continue doing damage without you.
Otherwise, I just try to behave in a way that is consistent with my ethics, while balancing practical matters. In this case, that means opting out of monopoly copyright interest as much as I can.
And can I just say, I really wish it were possible to have discussions about why ought to be without getting dragged into a tangent about how to get there. Like, we've gone from my taking issue with equating laws and ethics all the way to a critique of my weak activism in pursuit of demolishing the IP regime.
> plagiarism is bad but believing that something is bad doesn't equate to believing that there should be a law to restrict it.
That is pretty much my point, yes.
And this is the whole point of copyleft: turn copyright around itself to ensure user freedom.
If you pick a "public domain" license, or MIT or WTFPL you are just building upon the copyright system in a different way than GPL or some other license or closed source.
You cannot "use" it or "not use it".
Please see my other comments in this thread for more details on my position.
You cannot "use" it or "not use it".
If you pick a "public domain" license, or MIT or WTFPL you
And even if I kept my code under copyright with an attribution license, not all forms of plagiarism would necessarily violate the copyright. For example, ideas and facts generally can't be copyrighted, but one could imagine cases where they can be plagiarized.
So even if I did use a license that requires attribution, that only works insomuch as plagiarism is a violation of copyright. And as we all know, there is a ton of grey area there. But regardless of the grey area, the plagiarism itself is still unethical.
Some interesting bits are here: https://www.plagiarism.org/blog/2017/10/27/is-plagiarism-ill...
Why do you not just pick a license that forbids uses not compatible with your ethical standpoint, and chose to just not enforce the terms should they be violated? This way, companies are likely to respect your intent and preference and you don't have to make use of a legal system you don't support.
> Why do you not just pick a license that forbids uses not compatible with your ethical standpoint, and chose to just not enforce the terms should they be violated? This way, companies are likely to respect your intent and preference and you don't have to make use of a legal system you don't support.
I think that leads to a lot of grey area in terms of what people are and aren't allowed to do with my code. It also kind of presumes that I would ever try to enforce anything, which is itself not just an ideological decision but a decision to be made in light of costs and resources and will.
Since we're now getting deeper into what I personally do, I'll note that in practice, I dual license under the UNLICENSE and the MIT. I use the UNLICENSE because it's goal is to explicitly disclaim monopoly copyright interest while attempting to be a public domain dedication. I also add the MIT because some folks stopped using my code when I only used the UNLICENSE because they were too risk averse and wanted a more established license.
As an aside, an alternative to this dual licensing might be the 0BSD license: http://landley.net/toybox/license.html
It's on spdx: https://spdx.org/licenses/0BSD.html
It's approved by OSI: https://opensource.org/licenses/0BSD
Available on choosealicense.com: https://choosealicense.com/licenses/0bsd/
Unlike the unlicense, google allows it: https://opensource.google/docs/patching/
Secondly, I use the UNLICENSE because it is an ideological statement. The 0BSD is not. Dual licensing with the MIT gives me a very small activist voice while also providing a practical option for the risk averse Googles of the world.
Not a good characterization of the argument. It's a matter of negative rights vs. positive rights. The original commenter's argument was cogent.
In copyright, the default is that no one has rights to your creations but you. In licensing it as open source, you're broadening what others can do with it. It's an active choice. If granting someone X could result in them doing X where they otherwise wouldn't, and you'd be uncomfortable with that, then don't go out and invite people to do X.
The hackneyed "common sense ain't so common" aphorism is certainly something to avoid though.
> Yes, folks, if you don't like the idea of a corporation taking your ("software-as-a-service") code and using it to create and sell proprietary products, then maybe don't license your code under the MIT License (or any of the others which explicitly allow exactly that)!
As for:
> In copyright, the default is that no one has rights to your creations but you. In licensing it as open source, you're broadening what others can do with it. It's an active choice. If granting someone X could result in them doing X where they otherwise wouldn't, and you'd be uncomfortable with that, then don't go out and invite people to do X.
Well, I don't think giving people a legal grant to do X is inviting them to do X, especially in the context of permissive licenses or public domain dedications. Otherwise, you could accuse me of inviting people to do X for any value of X, no matter how pernicious.
For the reason just stated:
"It's a matter of negative rights vs. positive rights."
You're say the license prohibits certain things, which isn't true. It's copyright law that prohibits, by default, almost everything. Choosing a public license to make something FOSS is an active choice that selectively enables more use for people who follow the cultural and legal patterns you do like. That a person while doing so doesn't also enable even the uses one doesn't like is not what you're characterizing it as: an active effort to prohibit those things. Wide open, MIT-like permissive reuse is not the default.
Bottom line is that laws and ethics aren't the same. A legal grant to do something (even if it isn't the default) doesn't constitute an invitation to do something unethical.
And I stand by my characterization. The parent post was literally talking about prohibiting things one doesn't like.
Indeed. Based on your other comments in the thread, it looks like you're committed to not understanding.
> The parent post was literally talking about prohibiting things one doesn't like
The parent post was literally talking about not talking extra effort to whitelist things they don't like. There's a real difference between that and what you're saying, and whether you want to acknowledge it or not doesn't change whether that distinction exists.
Ah okay, so you're troll. Please don't bother communicating with me in the future.
If I buy a copy of a wp theme and use it am I passing it off as my own work and would it be called plagiarism?
So if you insist, I suppose change my statement from "not use the legal system at all" to "use the legal system to enforce as few things as possible given its current framework."
If you think laws and ethics are the same or should be, then I suppose that's a deeper disagreement and not one I mean to explore here. :-)
But licenses are not only for legal purpose, they also serve to communicate the authors preference for the prospective users. Of course you can communicate it otherwise, but using a common license is generally pretty easy way of doing it. But I think it is really important that the preference is communicated in some sufficiently clear and explicit manner.
If I did do that, the funny thing is that it might end up having the exact opposite effect! Human nature and all that.
I think licenses communicate legal things. Some things, like copyleft, use copyright as a hack to inject its ethics into the legal system. But that's one specific and very intentional case, and is definitely not something that is commonplace among software licenses. (Typically, when people try to do it, it has a Not Good outcome.)
No, but placing something to public domain is easily interpreted as explicit "please plagiarize", so it would be good to counter that message with something if that is not the message intended.
I've never heard of anyone interpreting public domain as any such thing. Whenever I get an idea from the SQLite source code for example, I have never for even a single moment ever considered plagiarizing it.
If public domain were really treated as you say, then movies and TV shows about Sherlock Holmes wouldn't begin (or end) with "Based on the works of Sir Arthur Conan Doyle." They'd just say, "Sherlock Holmes was conceived, written and created by Foo Johnson." But of course nobody does that, because plagiarism is unethical.
Well, there's two ways to do that.
I think we would agree that my ethics shouldn't change to match the law, because the law might be wrong.
But the law should change to match my ethics, if and only if my ethics are right. (Figuring out what ethics are right is left as an exercise)
So if I don't want my project to be used outside the terms of the AGPL, I don't see the problem with releasing it under the AGPL.
If you're against all forms of intellectual property you could just say that and clear things up.
But I'd rather not give up my IP rights before corporations do.
Yes, I am. But the validity of intellectual property isn't relevant to my argument in general I think. It just so happens to be true in my case.
I'm not sure laws should change to match our ethics to be honest. But I think that's part of the "deeper disagreement" I alluded to in my parent comment.
The only problem is that if your software becomes somehow well-known, you'll be bugged to no end to release it into any license, and you will need to develop an anti-spam filter to automatically delete these mails.
I was a little coy above. I said that I "release my code into the public domain to the extent possible." In practice, I dual license my code under the UNLICENSE (public domain, effectively) and the MIT. I do this because the UNLICENSE is unsuitable either because people are too risk averse for it or because public domain is for one reason or another not recognized in their jurisdiction.
I didn't elaborate on this in my original comment because it's not really pertinent. I think.
But yes, I can't put code out there without a license because I ultimately want people to use it. And I've made the mistake of using a license that people don't like to use before (the WTFPL). You do indeed get bugged quite a bit.
The concept of copyright existed long before software licenses and long before the (c) symbol.
It often applies automatically if you sing a song in a park, scribble an article on a napkin, paint a giraffe on your car - no matter how "casual" your artwork might seem.
I'm curious what led to the choice of the MIT license in the first place, given their goals.
I have heard the name Voltaire before but did not know who he was until I just looked it up -- and I'd wager my grandfather didn't know who he was either.
Thus, there's the issue of intent (or lack thereof). I suppose Voltaire can terminate my license if he wishes. However: a.) I have a feeling that (after being dead for 242 years) he doesn't care and b.) I very much look forward to receiving a letter from his lawyer informing me of such.
When I worked at Google (2014-2018), it was easy to get permission to contribute to open source projects as long as the license was BSD, MIT, or Apache 2.0. The more restrictive licenses like GPL 2 or AGPL, I think Google either flat out denied or you had to do a lot more work to get permission.
Now that I work for myself, I much prefer not having to ask anyone for permission to contribute to open source, but I generally default to MIT/Apache2 unless I have a reason to do otherwise, out of consideration for employees at Google or other corps who may want to participate in my project.
In that case Google's policy is what is restricting you, not the license. The AGPL doesn't say you can't contribute if you work for Google. I'm sure AGPL users (like the company in TFA) wouldn't mind if Google reversed their policy and gave their employees permission to contribute.
In this context, I don't think the distinction matters.
If I was choosing ingredients for a brownie to sell, using THC would restrict which US residents can buy my brownies. Is it the fault of the lawmakers in my customer's state? Or is it my fault for choosing an ingredient that's banned in most US states? If I'm trying to maximize sales, the question of blame is irrelevant.
From a practical standpoint, it doesn't matter whose "fault" it is that a Googler can't contribute to an AGPL project. Choosing an AGPL or similar license prevents me from receiving contributions from people who otherwise might be interested in contributing.
But from my perspective, I'm fed up enough with Google's anti-AGPL FUD that I don't mind not getting contributions from Googlers for a while. It's gotten worse than Microsoft in the nineties.
And with critical mass, Google will hopefully make a similar turn. Microsoft is now the world's largest open source contributor by some metrics. I don't know if I buy those metrics, but it's big. Same thing will happen to Google, hopefully.
Unquestionably, yes. They know exactly what kind of business they were looking to restrict with those laws, and in your analogy they stuck all the fallout from that on you. (That's not to say one shouldn't be civic-minded, but for the record I tend to avoid analogies when talking about this because they more often seem to confuse the issue than actually explain what is happening)
AGPL and the non-commercial licenses are still banned.
Edit: The Google OSS contribution guidelines are actually public, if anyone wants to take a look: https://opensource.google/docs/patching/
E: Oh it's the latter, this is pretty gross. A noncompete sure but what is this..
> As part of your employment agreement, Google most likely owns intellectual property (IP) you create while at the company. Because Google’s business interests are so wide and varied, this likely applies to any personal project you have. That includes new development on personal projects you created prior to employment at Google.
Disgusting amount of control over people's lives. Y'all need a union.
The above link [1] is for the automatic process where Google still owns the copyright (hence no AGPL or non-Commercial stuff). This works for 99% of stuff and is easy.
There's a second process called IARC [2] which lets the employee retain the copyright. It's not automatic but allows for AGPL, non-commercial, or proprietary contributions.
We also have a few AGPL projects that were whitelisted due to COVID-19 [3].
[1]: https://opensource.google/docs/patching/ [2]: https://opensource.google/docs/iarc/ [3]: https://opensource.google/docs/patching/#no-review
I wonder who Google considers to be in bad standing while also not fired. Flight risks? Maybe people who want to work on side projects?
Still pretty greasy
FWIW this is more Google being risk adverse than Google being evil. If a Google employee in their free time contributes to an AGPL project, that employee needs to open source all IP related to their contribution to the project. Depending on the specifics and how the AGPL is interpreted in court, Google could be forced to open source their internal IP.
FWIW, I believe all large companies take a similar stance on the AGPL.
This isn't the problem. The reason for contribution bans is stated in [1]:
"Our general philosophy is that we do not allow patches to projects that Google cannot use."
Absolutely false. This is simply not how copyright works!
How so? Here's what section 5 of the AGPL says[0]:
> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
As for patents which is covered in section 11:
> If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients.
The contribution of a chunk of code to an external project is just that. Anything else that belongs to google that you called "related" is not automatically subject to AGPL.
Second, in your example you are not describing where (if) any license violation happened.
Third, GPL cannot force an author to release something under threat of being arrested or something.
In case of GPL license violation, the worst thing that can happen is the termination of the license, which means that google can freely choose between not using that software, or using the original version, or using any modified version that is AGPL compliant, either developed internally or externally.
The terms of license violation are incredibly lenient compared to closed software/movies/music piracy.
(And yet we hear all this FUD around *GPL while nobody screams at the risk of a google employee using some a picture of some celebrity in a meme in a weekend project)
Why? Because this isn't about IP risk, it's about trying to kill the AGPL.
That employee doesn't even own the copyright to Google's code. If Google itself violates the license you can go after them, that's when it becomes a problem for them.
Things like the AGPL and CC-BY-NC-* are actually written by lawyers and make it clear what you actually want.
That's kinda a sad state of affairs that you're allowing corporate policy (of companies that you don't work for) to effectively dictate your licensing strategy. Not saying you're wrong to do so (it's your project; you know best), but the overall gist of it feels a little dystopian.
Ultimately Google is applying pressure -- even if unintentionally -- to the community at large: "use a license we're happy with, or you'll have a smaller pool of contributors"[0].
If AGPL was a majority license for projects like these, then Google would likely have no choice but to allow contributions to AGPL projects.
[0] Note that that's different from an individual deciding (for whatever reason) that they don't want to contribute to projects that use certain licenses (which is fine!). Google's policy forces an unreasonable restriction on their employees that their employees may not agree with, but can't argue with because of the employer-employee power imbalance.
Out of personal self-interest, I want to maximize the number of people who are eligible to contribute to my project. If it's unlikely for anyone to use my code to compete against me or form a different business without compensating me, I default to a permissive license because it allows more people to contribute.
This is not the case. The AGPL license does not exclude googlers. It's Google that excludes googlers.
This is entirely google's decision. It's obviously not a decision made to help FLOSS or FLOSS developers.
> Out of personal self-interest, I want to maximize the number of people who are eligible to contribute to my project.
I don't want to maximize the number of organizations taking my software, locking it down, renaming it and ultimately competing AGAINST my user community.
Personally however I would not spend to much energy and time worrying about that. I don't expect google to pay programmers to support my side projects, and I would be actually a bit worry if they contributed to anything critical at the place where i work. Google might find coexistence acceptable today, but if they have paid employees to work on code for a competing company (even if its just for one of their commercial products) then I would see a risk that one day they would prefer to own what they are today giving out for free.
I would love an update to moonlighting laws that acknowledged megacorps.
Have we made contributing to all allowed project/licenses more efficient over the years? For sure :-) Maybe that's what you noticed. We switched to asychronous permissions for 99%+ of all patches.
I think we have a mirroring system setup to automatically publish any internal changes.
Edit: See https://opensource.google/docs/thirdparty/licenses/#reciproc... for the public info about mirroring.
Since Amazon is frequently lumped in with Google et al., I think there is common belief that they are roughly the same. Amazon has an Outside Activity policy that covers some employees (certainly all tech employees). For the vast majority of outside work activity that triggers the policy, you simply fill out a notification form that logs an affirmation that the activity does not trigger further review.
The license of open-source software that you want to contribute to on your own time is not part of the policy that would trigger further review. In other words, so long as developing that software is permitted by the outside activity policy, you are free to develop and make software available under AGPL on your own time while being an Amazon employee.
Ultimately overtime is paid, but the first 45 hours every month are ‘included’ in the salary.
A good reading that covers this very topic really well: https://www.joelonsoftware.com/2016/12/09/developers-side-pr...
Joel Spolsky has a good article explaining the rationale:
https://www.joelonsoftware.com/2016/12/09/developers-side-pr...
>Suppose, now, you have a little game company. Instead of making software, you knock out three or four clever games every few months. You can’t invent all the games yourself. So you go out and hire a game designer to invent games. You are going to pay the game designer $6,000 a month to invent new games. Those games will be clever and novel. They are patentable. It is important to you, as a company, to own the patents on the games.
>Your game designer works for a year and invents 7 games. At the end of the year, she sues you, claiming that she owns 4 of them, because those particular games were invented between 5pm and 9am, when she wasn’t on duty.
>Ooops. That’s not what you meant. You wanted to pay her for all the games that she invents, and you recognize that the actual process of invention for which you are paying her may happen at any time… on weekdays, weekends, in the office, in the cubicle, at home, in the shower, climbing a mountain on vacation.
Presumably the employer wouldn't be happy if the designer simply had a bunch of nice design ideas and kept it in his or her head.
Instead, the designer should at some point write those ideas down and hand them over as a design document to the rest of the company. That process can provably happen during work hours, and the contents of the design document should be subject to the employment contract - since that's what the employer is paying for.
The document could, for example, have a boilerplate legal heading with "I declare all the contents herein are the sole IP of $company" or some such. Or the contract could specify that any document produced during work hours should satisfy such requirements. That would seem a safer legal protection than simply asserting the right to what the designer came up with on the previous day.
After all, if the concern is that the employee could have invented the game in the evening and then submitted it during the day - well, he or she could just as easily have invented it before their employment began and submitted it afterwards, no?
Personally, I use it as a gauge of trustworthiness of employers; I am more than understanding that if I come up with a great idea related to something I'm working on, it's probably a result of the experience I've had AT that employer and it makes sense that they have some claim to that.
However, when employers say that ANY idea I have is theirs, that's usually a bad sign.
Personally, I consider that a feature rather than a bug. There's a list of these licenses [1] and I make sure my software uses one of those on the list.
[1] https://opensource.google/docs/thirdparty/licenses/#banned
A nonviolent, voluntary and intentional abstention from dealing with google, in order to encourage google to alter an objectionable behavior.
1) Excluding Googlers, which isn't very nice.
2) Applying pressure to de-evil Google, which is very nice and benefits everyone.
I'd like to have a non-evil Google again. I really miss the old non-evil, brilliant Google. Organizations change.
Let’s have them do work as individuals instead of Google employees.
For AGPL, anything it links to must also be AGPL licensed. If a company such as Microsoft wants to use my project internally, they'd be taking on a huge liability. Does this mean any project that depends on my project needs to also be APGL licened?
Further, the terms on APGL are somewhat vague in a good-hearted attempt to prevent exploitation. What counts as 'use over a computer network'? If Microsoft developers use network disks to access my software are they screwed?
For now I'm (somewhat unhappily) considering MIT the only option.
That's the whole point of the AGPL, isn't it? This license solves exactly the problem that you want to solve. They can use your AGPL software internally as much as they want, without restrictions. But if they create a user-facing product out of it, they must make their modifications available to everybody under the same terms.
(EDIT: changed you/they on the second paragraph)
Not a lawyer, but with internal usage, anything goes as far as the AGPL license is concerned. The restrictions only kick in if they plan to distribute the software, or publish a remotely accessible interface to the software. I'm inspired by two particular resources regarding this [0][1]
[0] https://opensource.stackexchange.com/questions/1399/can-gpl-...
[1] http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePos...
So (not legal advice) your issue isn't so much that a service provider will make a user-facing service out of your code. But that many won't touch it at all because of the AGPL license.
Also note though that someone can offer a user facing service using AGPL code, they just have to distribute any other code that is part of the overall work. (Which is what a couple of the new usage-restricting non-open source licenses seek to prevent.)
which basically should not be a lot, if you do not make any modifications? i mean if I create a docker container and put them into k8s I robably only need to open source the docker container and maybe even the deployment.yaml/helm charts/whatever but thats it, everything that communicates with it via http/external interface that is not linked does not need to be open sourced.
The AGPL absolutely allows this.
It can link against GPL software:
"Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License."
I don't see how the MIT license would help you achieve this.
- an enterprise wants to purchase your service
- somebody wants to contribute to your project
- a cloud company is trying to create a service using your code
The solution is dual licensing for these. First use case is licensed under an enterprise license that does not have any AGPL like vague restrictions, still can block the company from launching a competing service
The second and third use cases are perfectly fine with AGPL.
I am not a lawyer but I think this is a viable solution.
Take HN as a website. Should every resource be seen as a seperate work or should a whole page be seen as one work. Is every sub page a separate creative work, or part of a work called HN. Is the search button, which is actually on its own seperate domain name part of the HN website? From there we can move forward like talking about middle layer and db layers and ask if those are part of HN or simply aspects which HN communicates with. Is the loadbalancer, database server, web cache, and so on part of the creative work called HN?
Personally I would draw the line to be similar to traditional web development with presentation, logic and db abstraction defining the work in terms of a website, and everything around that being simply other works which the website communicates with. That however depend on the website being a classic website, rather than say an webified version of an application. A game, an office suit, a email client, all those might have a very different scope and what defines a game as a single work may be quite different from a website that display news items with comment threads.
> if Microsoft developers use network disks to access my software are they screwed?
That condition says that the terms of AGPL goes into effect if a use access a "derivative work" over the network. Microsoft using network disks internally does not matter, as that scenario does not have a defined user. If a user download a program over NFS then technically that is over a network but both AGPL and GPL would consider that "copying" in traditional sense.
Why do you think the AGPL can’t do this?
Why shouldn't this be possible?
Yes.
In fact, they are even free to take the software, modify it, and run it for their customers as a hosted service. The key difference, however, is that the license requires that they must also let their user's download the source code of their version.
--
In "Why the Affero GPL" [0], the FSF specifically mentions:
> The GNU Affero GPL does not address the problem of Service as a Software Substitute (SaaSS).
(Here, "Service as a Software Substitute" is the FSF's term for what the rest of the world refers to as "Software as a Service". According to the FSF, it "defines the bad practice more clearly and says what is bad about it.")
Another of the FSF's articles, "Who does that server really serve?" [1], explains the problems with SaaS with regard to open-source software.
--
[0]: https://www.gnu.org/licenses/why-affero-gpl.html
[1]: https://www.gnu.org/philosophy/who-does-that-server-really-s...
I wanted to protect future potential commercial interests without stifling the spirit of open source collaboration and development.
I asked around for advice and eventually just chose GPL over AGPL because a lot of legal teams seemed allergic to AGPL and some companies even had a blanket ban on it.
I also thought that the greatest risk for my project was not an existing or future competitor: it was death by obscurity. To that end, I did not want to slow down adoption by choosing a license that screamed "$$$" or made somebody's legal team uncomfortable. In any case, if a big company wants to copy you, they will and can with the resources they can throw at it.
On the other hand, there are popular projects that do use AGPL (MongoDB) so it might not be that big of a deal in the real world :)
If you want to go with AGPL but are concerned about the dampening effect on your prospects and never being able to get off the ground because of it, then maybe go for GPL, and as soon as your project has reached critical mass, has momentum, etc, then take the opportunity to reconsider and go from GPL->AGPL. Like, as soon as possible; when there's any momentum at all.
It's also why you might consider MPL2. It's compatible with the GPL and LGPL by default, and it has an MIT (or Apache) feel, but it's essentially GPL at the file scope. And since it isn't branded with the letters "GPL", you can avoid the reflexive "nope" from potential contributors and clients.
The main thing, though, is that relicensing can be easy. Hell, you can even start off under MIT until you reach n > 1, migrate to MPL2, using it as a stepping stone to GPL, and then go full-fledged AGPL, with no CLAs or big relicensing effort required at any step of the process.
This is true for my company. Our engineers are allowed to use OSS licensed with LGPL, MPL, GPL and other copyleft licenses. But OSS with AGPL is expressly forbidden.
Thank you for releasing typesense under GPL. I was able to try out your software without fear of losing my job.
So, in other words, you succumbed to F.U.D. (Fear, Uncertainty and Doubt).
Something that needs to be said a great deal more frequently than I see it being said: Corporations are not your friend and they routinely prey upon smaller entities, chew them up and spit them out. This is par for the course. It is not some weird anomaly.
I have never gotten around to successfully putting together a compendium of examples, which frequently frustrates me because it seems fairly hard to google (at least for me) when I want to talk about this and post an article or two to support my assertion.
Small shops routinely talk like getting "some big client" is the small business equivalent of "winning the lottery." Oh, my god. This is generally the exact opposite of the truth.
Small businesses routinely learn this the hard way and many of them either actually go out of business or get smarter and harder just in time to merely have a near-death experience, business-wise.
Small businesses routinely have to change their policies after their first brush with being screwed by some large company.
This is the norm. This is the norm. This is the norm.
This is not some weird anomaly. This is not because you did something stupid or naive. This is how big companies become and remain big companies in far too many cases.
I"m not trying to vilify big companies. Doing business means dealing with the public and making money at it and that's what they know how to do.
I worked for a time at a Fortune 200 company. It was a growth experience and I don't regret working for them and I don't think they are evil.
But when you leave your little cocoon of friends and family and venture forth into a relationship to The Public, this is what you run into and that's their forte. So learn from them. Grow. And, yes, spread the word because more individuals need to hear this early and often so fewer small businesses get eaten.
I think we have a top-heavy system and we need to do more to protect the survival of small shops and medium shops and micro shops. The degree to which big companies prey upon those companies is part of why our economy is so unstable.
My product (https://httptoolkit.tech) is a debugging proxy app. The codebase is broken up into a few modules: a desktop shell, a UI, a backend component for the UI, plus a standalone proxy library and a bundle of smaller libraries that do everything from detecting & launching browsers to reparent react components around the DOM (if you're interested, they're all on github: https://github.com/httptoolkit/).
All of this is open-source, with some premium features behind a subscription (but even those are open-source, it's just you'd have to fork it to remove the subscription checks, and it's not worth the time of any professional to maintain their own fork of the whole project).
The core product is AGPL, but nothing else. More specifically, product-unique components are AGPL (the UI, the backend, etc) where there's no clear case for ever reusing them other than duplicating/forking the product, but everything else is kept under permissive licenses, mostly Apache 2. This is mainly because AGPL really limits practical freedoms in business contexts: It's harder to get sign-off to contribute to (A)GPL libraries, even in a one-off script nobody wants to risk using an (A)GPL library and it would become much harder to find contributors.
So far I've found this has worked pretty well for me, and I'd recommend it to others, including Plausible. Put only the core product-specific components under AGPL, but keep everything that might be useful to somebody building a completely different product under more relaxed licenses wherever you can to ensure you can fully engage with the open-source community.
I wonder if Plausible discovered someone else selling software based on their code?
Although my guess is that it shouldn't matter much? Most people would want Hosted Analytics. So Open Source is only there for insurance.
One company was promoting a proprietary, privacy first alternative to GA, we checked it out and several features/elements looked pretty much exact replicas of Plausible.
The other was that we got approached to help someone build a direct competitor based on our self-hosted code. They were upfront that they didn't want to pay us and they didn't want to contribute back to the project. They did offer us publicity to their "tens of thousands" of customers!
For small or midsize companies AGPL + full copyright ownership is usually the optimal solution.
That is a fair point. May be Plausible should do that too.
This is a deliberate choice from companies that want to exploit open source without giving back to the ecosystem.
That's extremely their problem.
AGPL tries to target hosted services, preventing cloud companies from taking open source components without contributing anything back.
But you know what the AGPL misses? Our data.
We need open source licenses that require the systems that make use of them to provide data export and the right to be forgotten. We should encode the GDPR into our licenses. This would prevent Facebook from taking open source and using it to lock away our data.
We should also fight back against embrace, extend, extinguish. Apple is trying to take over computing and prevent us from running our own software on our own devices. We should prevent them and anyone else trying to do this from using our software.
No right to compute on your platform? Fine. No rights to open source software.
We have to defend computing and open source, otherwise we'll all wind up using thin clients to access walled silos. And we'll be renting the access, too.
I mean, I guess you can add a clause that says "you can't use this software if you do things that the author doesn't like with it", but the point of the FSF software licenses is that they don't limit what you do with the software in any way, just how you can distribute the software itself.
This is like trying to stop child porn using the license for encryption software.
It doesn't really discuss other sorts of freedom.
I'd also note that RMS is famed for having (and sharing) many opinions, many of them specifically on the sorts of freedom we're discussing now, yet no such language has ever appeared in the FSF's licenses.
I'm still tempted to argue that if I want to run the software in whatever way I like - in this case mimicking someone else's production system, then I'm going to need access to both the source code as well as _my_ user-data so I can use the software to host my own user data.
This is precisely what GPLv3 is for. If you distribute a GPLv3 program, its users must be able to modify it and run their modified versions.
I'd imagine this is why Apple is allergic to GPLv3, but you know what... that's fine, I wouldn't want them to distribute software I write if its users aren't going to be allowed to change that. The issue so far is there's not enough GPLv3 software out there for them to care. If more people use it, that could change!
But if you care about your data the AGPL gives you the ability to run the software and keep your own data.
I don't get why folks who are scared of competitors start with a permissive license in the first place. They could have easily foreseen this. Think about competition who have invested time and PRs back to this.
IIUC the intent was to ensure that modifications to Plausible are released as open source. However it isn't clear if this also affects tools that use a API or even just Plausible being used internally for a company.
The AGPL does have wording saying that in the case software is joined together only the original work has the AGPL requirement, however it is unclear what the difference is between modifications to the original work and other code that uses that original work.
FWIW this is non-specific enough that I am not completely comfortable using Plausible personally anymore. Of course you company's legal team may have a different opinion.
In the case here it's however about AGPL. AGPL has the extra thing, that source has to be given not only to somebody who received the software, but also to ones who access it as service via network. (There is some legal debate on the exact details) EUPL afaik doesn't have such a clause, but it's relevant for somebody who builds a "service" and wants to prevent others from running a private fork of it.
I guess under (1) the "providing access to its essential functionalities" part is relevant: "‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person."
For example, how it affects previous versions? Can the copyright owner switch licenses at anytime?
If there’s a resource in this I’d love to read more, too.
It does not affect older veraions - unless the previous license has a provision for this (and I doubt many people would be willing to use software with such a license).
> Can the copyright owner switch licenses at anytime?
Yes, but many open source projects are made up of many copyright holders due to external contributors.
But the complication is that if the software project is made up of contributions from 100 different people, it's not immediately clear who the copyright owner is. In the worst case you might have to get permission from all 100 people before you can switch.
This is the problem contributor agreements were designed to solve.
Of course, some people call this a feature and not a bug.
It would be a bad situation indeed if I could license my code under an OSS (or even commercial) license and then summarily revoke all those licenses by relicensing the code under new terms.
It's also unclear regarding upstreaming, and the "virality" of the source distribution requirement. As far as I can tell, for non-CLA projects, effectively there is no way for upstream to be exempt from the AGPL article 13 provisions, which means any AGPLed project that takes contributions needs to build in the source code offer functionality into the canonical version or else they'd be violating their own license (read: that of every other contributor, which is why this is a problem).
Additionally, unless the software is written so that it can package its own source as-running and distribute it to every user, using the AGPL puts your users at risk unless you make it a proper click-through license that users must agree to before usage. Due to its nature, the AGPL is an EULA, not a free software copyleft license. Unlike other open source licenses, it is not a mere copyright license. Users need to be aware of its provisions of it, as they are liable for violations not strictly only by distribution, but also if they just run AGPLed software and happen to make a trivial modification, like editing a single template. This is, in concept, going into the "you shall not run this software on more than X cores" proprietary territory, because it makes the critical change of imposing on requirements outside of distribution, so users need to be aware of it just like they need to click-through proprietary EULAs.
The AGPL really is not a good license. I wish people would stop treating it as a magic cure for the "SaaS loophole". Using it has deep consequences for your users and how the software must behave, and it isn't legally tested in a way that guarantees it even will protect you how you think it will. I hope people using it know what they're getting into.
Here's a personal example of an AGPL problem, and how I violated it (as far as I can tell) by doing nothing out of the ordinary. I run dspam on my mail server. dspam is AGPLed (I did not know this). I use Gentoo Linux, so I just installed it, but due to politics/inertia Gentoo considers the AGPL as default-accept (which is supposed to be reserved for licenses that are free enough that users need not be concerned about), so I was not prompted to accept it during package installation (like I would have for proprietary packages). Unfortunately, Gentoo is a meta distro. They also carry patches for dspam. This means that by installing dspam, I was patching dspam and compiling it, thus triggering AGPL Clause 13. This means I was liable to make dspam source offers to all my users. Unfortunately, the definition of "user" is unclear, and it could encompass "anyone who sends me email through SMTP which gets delivered through a dspam filter" (or at least "anyone who has an inbox filtered with dspam", which includes a few other people on my server). Obviously I was unaware of all of this, and did nothing other than "emerge dspam" and configure it. So now I have potentially violated the AGPL (as have all Gentoo dspam users).
The relevant GNU FAQ entry[1] seems to indicate that click-through licensing isn't required (or forbidden, either).
[1] - https://www.gnu.org/licenses/gpl-faq.html#ClickThrough
The FSF's oficial position is that the AGPL is a Free Software license, which means it meets all Free Software requirements. This is understandable, as it is their license. I disagree. Freedom 0 is the ability to run the software however you want, and the AGPL imposes requirements here (if you modify it without distributing it then you are required to offer source when you use it, which is a requirement that goes beyond traditional copyright licensing).
So while they are correct in saying that click-through licensing is silly for typical permissive/copyleft licenses, I strongly disagree that the AGPL is such a license. It's fundamentally different, and I've already given an example of how being unaware of it has potentially put me in noncompliance. The whole point of click-through not being necessary for users is that for all those other licenses, no restrictions are imposed on end-users as long as direct distribution of the code does not occur. The AGPL imposes such restrictions.
I worked with IP/software license lawyers and AGPL works just fine.
* Most people in free software: The FSF wrote it, therefore it's fine, because the FSF are trustworthy when it comes to freedom%. All server open source projects should use it, it'll magically protect us from the SaaS loophole, and there is nothing to worry about if you're not an evil corporation.
* Most every big corp: the AGPL is a ginormous can of worms and we aren't touching it with a 1 mile pole. Nope. Stay away.
Guess what? Reality is in between those two extremes. The problems with the AGPL are widely underreported in the free software world, and almost nobody has taken a close look at its wording and what it really means. "Leave it to the lawyers" but then nobody ever actually goes and asks a lawyer for a clean take on it.
We should do better. The FSF has done a terrible job of educating people on exactly what the AGPL requires and how it interacts with typical free software project development and deployment workflows. If you haven't asked a lawyer about this then maybe you should think twice before slapping it on your project. Relicensing after the fact is a very costly ordeal.
% The FSF, through their "Respects your Freedom" hardware rubber-stamping program and its absolutely broken requirements, which actively encourages reduction in user freedom, makes it much harder to detect hidden proprietary backdoors, and hurts projects that are actually aiming for maximum openness, have amply proved that they are not infallible and are not to be trusted without careful review of their policies and projects. I can go into a whole different tangent about this, but my point is, don't treat the FSF as the good guys by default. Look at what it is they're doing exactly and all of its consequences.
I guess when you say "has absolutely not been evaluated by people who should care," it's because you think anyone short of Yale isn't a real lawyer. Those jokers and clowns from Harvard....
It sounds like you are angry with the FSF, not sure why.
As for your claims: RYF rubber stamping? RYF reduces user freedom? RYF makes it harder to detect hidden proprietary backdoors? None of these statements make a lot of sense. You're going to need to provide a whole lot more information to back them up.
https://twitter.com/marcan42/status/1040626210999431168?s=19
TL;DR the FSF's RYF program is designed to allow inaccessible, un-auditable, immutable blobs - because they know that if they didn't, nothing would ever get certified (everything has at least some microcode or ROM of some sort, e.g. the USB sound cards they've meaninglessly certified as RYF). By doing this, they encourage companies to make their blobs inaccessible, immutable, and un-auditable in order to get that rubber stamp. And so, we go from having firmware in /lib/firmware or something where it makes engineering sense, to dumping it in some write-protected flash read by a controverted set-up with a side CPU, where the user will never be able to audit or replace it, because that is what they will certify. In their view, proprietary blobs are OK as long as the user can't see them or touch them - but if they can, that's a big no-no. This isn't a hypothetical scenario, as Purism has already gone down this road for the Librem 5, to the detriment of their users' freedom, as well as wasted engineering time and final device cost (that extra flash chip).
Put this way: a device that requires proprietary firmware loaded by an open driver from /lib/firmware is, by any reasonable metric, strictly more free than a device with the same firmware burned into ROM, but the FSF will only certify the latter. Even though you could audit the firmware, guarantee firmware authenticity, or even replace it with a free replacement when it becomes available (or reverse engineer it yourself) in the former case, but not at all the latter.
Meanwhile I have a friend who designed a completely open hardware laptop (think about the significance of that) and the FSF refused to certify it because the main CPU (one of the few with open documentation at all at the time) happened to have a GPU accelerator in it (even though it was not required, you can use it just fine with only framebuffer output) and at the time there were no free drivers, so even if the thing shipped with all open code, they thought users might be "tempted" to install the blob drivers. There was some talk then of getting the manufacturer to permanently disable the GPU in those chips to get certified. So the FSF will certify hardware as long as you remove any features which might be usable with proprietary software. How does this increase user freedom again?
It's all completely bonkers.
I'm somewhat frustrated at the FSF, because it seems that so much of what they do these days is extremist to the point of hurting the free software cause (e.g. some of their campaigns are just embarrassing in how childish they sound). I understand that they don't like proprietary software, but treating it like it's a massive evil upon the world is now way past its expiry date as an advocacy approach; this just makes the whole community look bad. Look at the FSFe if you want a more moderate organization which advocates for these causes without falling into sily behavior like that.
I would disagree. AFAIK you do not need to agree to a separate licence in order to use firmware embedded in hardware, your right to use it is implied from legal ownership of the item.
But if the firmware is distributed independently (like as a part of a Linux distribution), then there are legal complications. The firmware licence must allow redistribution - some do not and then OS contains just script to download it from vendor webpage, which is super awkward, has privacy issues and may force you to accept some vendor conditions. Even if it allows redistribution, it may have some conditions that precludes it from being part of Linux distribution for practical reasons (e.g. advertising clause). And it forces the third party to accept such non-free licence in order to have the right to redistribute it (as a part of Linux distribution).
So it creates plenty of logistical and legal issues for users and third parties just to spare some cents on flash.
Note that having embedded flash with firmware does not preclude having ability to load newer firmware from /lib/firmware during boot.
I don't remember the last time I saw one of those firmware download scripts. Vendors aren't dumb, they know they need to allow firmware redistribution and the vast majority allow it without a problematic license.
Having embedded flash with firmware while being able to load newer firmware from /lib/firmware is not a sensible design, as it requires duplicating ROM and RAM. There are three kinds of common devices:
* Those which load firmware from an embedded ROM, which is immutable (except perhaps minor RAM patches)
* Those with embedded flash that can be updated. These wouldn't load firmware from /lib/firmware, they'd instead be updated by a vendor tool that you run just once.
* Those with a firmware RAM that requires firmware upload on startup. These would use /lib/firmware.
Combinations exist, e.g. chips which can boot from RAM or optional external Flash, but that makes the version of the device with external Flash strictly more free expensive and unnecessary if firmware could just be loaded from the host.
You're trying to interpret a legal document like a computer reading a piece of code, and not even reading it correctly at that.
To be in compliance with the license, you need to __substantively__ follow the provisions. If you and I sign a contract that I will build a house under terms carefully laid out in the contract, and I make a change from those terms which is not material and substantive (makes no difference to you), I'm not liable for anything. The kind of nits OP is pointing at would never fly in court.
From there, it isn't a question of "triggering provision" and being "liable." Liability is calculated in terms of damages. Damages aren't set to hurt people, but to make things right. If I sell you a defective car, damages are what it takes to fix or repair that car, not ten million dollars. If I use a different type of flooring building your house because the type you wanted was sold out, a court would rule on the difference in value; you can't just refuse to accept the house. This becomes really important in commercial law.
All of the example OP brings up, if they were in fact problems (and they're not), they would have damages of $0.00. There is no liability, so they're okay. That's how you interpret contracts. Lawyers read, write, and follow contracts with how they'll be interpreted in mind.
And from there, every other sentence is just technically wrong. E.g.: "Due to its nature, the AGPL is an EULA, not a free software copyleft license"
I could write a 30 page paper on the holes there, but at the core, what's missing is a basic understanding of how commercial law works. Without that common understanding, it's like trying to convince your grandma, who has never touched a computer before, about how Facebook's algorithms work. It's hard. It requires a common base of knowledge which OP doesn't have. At that point, you're better off advising people to either take a class in basic business law, or to talk to a lawyer.
Actually, a better analogy than Facebook might be data structures in git. Eben Moglen, who wrote the AGPL, is one of the more brilliant legal scholars alive today. That's much like a person who's never used a computer before trying to poke holes at Linus' hash DAG structure.
At some point, you either have to trust the competence of experts, or you have to educate yourself.
> The value of software lies overwhelmingly in the software. Charging for anything else perverts incentives. Charging for features? Make it hard to add features. Charging for configuration? Make it hard to configure. Charging for training or documentation? Make it hard to understand. Charging for hosting? Make it hard to host, monitor, tune, &c. Not charging at all? Slurp up personal data on users, and charge for that.