"Nothing came of it, but I took the code and shoved it into my back pocket for a rainy day.
My idea was to take this code and spruce it up for Uber’s use case."
"My first reaction was to publish the code on Github."
I’m very surprised by this, isn’t the code property of Box, or Uber? The author does not mention their authorisation before releasing it under MIT license.
Author here. The code was originally written outside of work hours. I offered the code to Box and they didn't want it.
If Uber wants a few thousand lines of JavaScript from over half a decade ago that didn't originate with them and that they used for less than a month, they can send me a letter.
I mean, I asked at the time, and I did it. If either company wants to start a legal fight over a pile of code that neither of them wanted that's old enough to be in elementary school, they know how to reach me.
The problem is that you are claiming ownership of this code and by making it available on GitHub under an MIT license you are claiming that you have the right to do so.
If I take that code and make a billion dollar business out of it, Box or Uber could then claim a share of it. That's the kind of things that companies do with the lawyers on retainer.
I then sue you for falsely claiming that you own it. You are particularly fucked because, thanks to this thread, you can't claim that you didn't know.
Even in California the "I wrote it on my own time" doesn't apply to software that relates to an employer's core business. In other places, like Washington State, you could be employed to write TPS reports and write a video game at home, and your employer would own that too.
IANAL but I have paid for advice on this very topic. I suggest you pay one too.
Long time ago my employer at the time had this in-house deployment system written by a guy that worked there. It worked well and we used it well after he had moved on. He left suddenly and started a company based on the idea. Employer went to sue him and discovered the ‘all your code belongs to us’ form was missing from his permanent file so they didn’t pursue it. That company is called Chef.
A spreadsheet UI didn’t relate to Box’s core business because Box didn’t sell spreadsheet UIs. Box could have had the author’s hobby project been adopted as a feature but explicitly chose not to. The author clearly owned that bit if they did it on their own resources and own time.
In other words, you can write generally useful components and utilities on your own time, network, and equipment; license them to your employer if everyone agrees; and either way you still own them. You just can’t write something directly related to or competitive with the products or processes that make your employer money.
The spreadsheet formulae and enhancements the author wrote during work hours at Uber, though, no. But even just their direct boss as an agent of their employer saying it’s ok to throw it on GitHub would probably cut them loose, especially since it’d be a derivative work with joint ownership.
All IMO of course, but that’s how I would have seen it in their shoes.
Well, you are not a lawyer. OP specifically wrote the code to help Box with its business. That's cut and dry within the scope of an employment contract, under California law. This doesn't get a safe harbor exception.
> OP specifically wrote the code to help Box with its business.
That was the intent, but not what actually happened.
Is intent to donate code enough to put it within your employment contract, when it's done outside work hours and would otherwise be outside the scope of employment?
> That was the intent, but not what actually happened.
The intent is a fact of what actually happened: which appears to be that it was written by an employee within the scope of employment to solve a business problem. Possibly outside of usual working hours, but if it’s by a salaried employee where doing work at home outside of usual working hours is itself a normal if not consistent part of employment, is probably not particularly significant.
That the employer later chose not to make use of it doesn’t change the circumstances of its creation; businesses often choose to not pursue use of exploratory work done by employees in the course of employment, that doesn’t surrender ownership of the work product.
And the version that was further developed within and in response to Uber business needs and actively used at Uber before the function for which it was used was terminated is an even clearer case (insofar as it is a distinct work from the original) of work-product (that it quite likely is also an unlicensed derivative work by Uber of proprietary Box code doesn’t mitigate that, though it puts Uber in the position of potentially being both a beneficiary and victim of IP violations.)
> which appears to be that it was written by an employee within the scope of employment to solve a business problem.
An imagined business problem.
If the code wasn't relevant to their actual business practices, that's quite relevant. They not only didn't want that code, they didn't want anything like it.
As for the modifications for Uber, that's not what I'm here to contest.
No, it’s not relevant. Seriously, go consult a lawyer in this. I have. They’re very consistent on this point because there are tons of case law regarding it.
There are a massive number of examples of patent and copyright litigation stemming from work done for one employer, who rejected it, then the employee goes off and founds their own company and gets successfully sued.
Fairchild was unique in that they had claim to the IP that their employees wanted to use in new startups, yet they decided not to follow through and allowed the employees to start their own companies. They could’ve prosecuted but didn’t, and as a result we got Silicon Valley and the culture that surrounds it.
But it’s no guarantee that that your employer won’t pursue a copyright claim they are perfectly within their rights to do. Don’t assume your employer is Fairchild.
You misunderstand. When he wrote the code, which was related to the company's business, the company owned it. Even in California. He couldn't have "intent to donate the code" because he didn't own it in the first place. The fact that he "intended to donate it" demonstrates that it was related to the company's business.
From a practical perspective, even if you think they don't own it, do you have the money to argue that in court if they decide that they do?
IANAL. If you are having issues like this, get legal advice from a lawyer. Not HN.
Relatedness is relative but I'd argue against it here. They didn't have functionality like that, and they didn't want it.
> The fact that he "intended to donate it" demonstrates that it was related to the company's business.
...yes, that's my point. We're using that intent to make the decision that it's covered. That doesn't seem like a good way to decide whether it's covered.
If he just made a web spreadsheet and did nothing else, people would shrug.
I built a side business that makes five figures of MRR that started while I was at Box and continued through my tenure at Uber. It's still going. If anyone was going to sue anyone about anything, it wouldn't be my shitty spreadsheet library.
The author explains how analyzing and presenting data was worth millions of dollars. The author documents how a senior executive instructed him to write excel. It is clearly their core business. Also, and this comes back to the fantasy/denial/wishful-thinking aspect here, neither I nor the law says core business. That's a word that you added. If you did it as part of your job, then it is, by definition, part of their business.
I am also nearly 100% certain we can look back at this comment in 20 years and find nothing happened, but only because nobody will take this code and make a billion dollar business. If they did, I guarantee there would be a law suit.
Literally today I was in a fireside chat where the speaker told us the IP law department at a previous employer brought in a couple billions in revenue by suing for infringement.
Is there any other industry where workers are so beholden to their employers that they cannot simply create something of their own without fear of legal action?
How did we get to this point as an industry and how do we change this destopia?
Kinda the other way around. California has a law that states such contract clauses are unenforceable. I could show you that. Washington State does not.
I’d recommend you update the article on those two points, because because as it is now, the article makes it sound like you stole code from both Box and Uber.
I don’t think its relevant that the code is old. The code is owned by the entity that’s paid for it. I also found that party of the essay really surprising.
This seems like a reasonable amount of pragmatism. As with most things in contract law, it's not meaningfully illegal unless some claimant is actually going to enforce it. You give enough context in the post to alert at reader that they should be careful of using it.
I was also absolutely gob smacked at this. Will they care? Probably not. Are you putting yourself at the absolute mercy of them deciding not to care? Absolutely.
I would have a hard time sleeping... like this would be like being in IT and knowing the backups were bullshit.
“Work hours” are less clear for salaried workers who may or may not take work home: if it was written to solve a problem for the employer, reviewed with other workers at work, but ultimately not further pursued the status seems murky.
The later derivative that was actively used by and updated for the requirements of another employer during the coarse of work seems to more clearly their property as a derivative (but also murky because it is potentially an illegal derivative of the earlier work, if that was owned by the earlier employer.)
That's not what happened here though. For salaried workers everything you do that is related to your job is owned by your job. That's the default even if your contract doesn't state it. He may not have been directed by his boss to make the code for Box, but he did it with the intent of helping Box's business, as a salaried worker. That makes it Box's property.
But even if you are unconvinced of that, work was clearly done on it on company time at Uber, where it was deployed as part of Uber China's business infrastructure. That work is absolutely owned by Uber (with maybe also some claim by Box). Not owned by OP.
It depends on your employment agreement or contract. Most contracts I have seen say that any IP you develop related to what you're doing at work is the employers.
It only depends on your employment agreement in the other direction. Work done for hire is by default owned by your employer under federal law. For salaried employees it doesn't matter if it is done during working hours.
The employment agreement can give up this right for things not related to the company's core business, and I usually insist on that in my agreements. But that is not the default behavior.
I usually insist that personal and open source work done outside of the product areas I work on are not company owned. Otherwise if I work on financial software at a bank, and then at home I work on defi/blockchain based financial stuff, I could be setting up a liability for me or my users.
Now I understand what you are saying, and no. For a salaried employee it pretty much covers everything you do that is related to your job, with that “related to your job” being interpreted very loosely, or done with company equipment or on company time.
It’s pointless to worry about being sued by a large corporation. If they want to bankrupt you, they always can, regardless of whether you did anything wrong or not.
We are like ants to them, they can squash us at any time, but most of the time we are too small to worry about.
Cool -- if one of the companies wants to issue a takedown request, they're free to make the case for it.
It's funny there's this idea that a company _might_ be potentially injured over code they do not want or know they had being made open source by its actual author, even though many of those companies will gladly use open-source tooling without ever contributing anything back.
Perhaps more soundly, though, in California – where Uber is headquartered – IP/Copyright for code is a huge legal question that the state and federal Supreme Court has no clear answer to. Sure, you obviously can't secretly clone Uber's entire stack, slap a new company logo on it, and start up as a competitor. But if you, as an author, wrote some code for a company under an IP agreement, then no-longer worked at said company, and then later adapted and expanded upon that code (or even started over, with the knowledge of what you learned from others' work): are you, at the originator, not legally allowed to be inspired by your past work? That's not something you, me, or even the company could decide.
There are gray areas but I do not think you are in one.
> and then later adapted and expanded upon that code (or even started over, with the knowledge of what you learned from others' work)
These are extremely different scenarios. Starting with a copyrighted material and modifying it is not at all the same as reading material and starting over. The first is violating copyright, the second is a derivative work.
If I read everything correctly, what you describe doing is taking code owned by the first company and modifying it for the second company. That’s not at all a gray area. It’s a copyright violation. You the engineer sign away your rights to the code when you built it for company 1 while employed by them. Their employment contract for-sure states they own any work produced by you during your employment, and you agreed to this.
If the first project was done off of company time, posted publicly on a private account, you might have a claim to the rights.
I know you’ve dug your trench too deeply to change your mind at this point, but anyone reading your comments should know what you did was technically illegal and can get people in legal hot water.
I wrote the comment above, though I'm not the author of the code that you appear to think I am. But I am in agreement with him.
> Their employment contract for-sure states they own any work produced by you during your employment, and you agreed to this.
There are many open legal questions as to where this line is drawn. Surely the line falls somewhere between "every character I've ever typed on a keyboard" and "the verbatim code". I personally don't think he's crossed it. IP ownership is much more complex than portrayed in HBO's Silicon Valley. That is my opinion.
Furthermore, when I worked at GitHub (now acquired by Microsoft, so I'm sure things have changed drastically) -- there were very lax IP ownership agreements in the employment contracts around code ownership, because the legal department was worried that if found in any way conflicting with California law it would render the entire IP claims null and void (which does have precedent in California).
The point is we don't know, and I think OP would know better than us if it was disallowed or not.
Like many things in this area, the answer is usually "You'll find out if you want to go up against an army of lawyers". The last three companies I worked for all claimed ownership of any IP I create, on or off the job, using company's equipment or using my own equipment. One of them explicitly called it out during the interview: You will have to stop working on open source or publishing side projects when working here. Can they do that? Maybe, probably not. It doesn't matter because I do not plan to bankrupt myself fighting their lawyers.
Regardless of the fact that California is much, much more strict in what they allow, to the point where oftentimes a company’s lawyers won’t even try:
Fine. Don’t fight, I agree, that would be an unfair fight and a waste of time/money.
The US court system requires a “good faith” effort to settle the issue before it enters the legal system. A cease and desist for example— whatever it is, you’d have plenty of time to simply decide it’s not worth it and remove the code once they take notice.
IANAL: In California they cannot, unless it is related to the employer's business (so if the employer is Apple, Google or AWS, they probably can). In most states they can.
I'm not sure how we weigh up the morals here. If you've done something using a companies resources (laptop, desk, chair etc.) and they're paying you and the contract says they own it I don't see how you can have a moral high ground. Maybe there should be some way to allow these ownership concepts to expire so that society benefits overall but right now we don't have that.
At one point in the article there is a photograph of a chair in the uber hallway and a caption indicating that the couch in the picture (or one similar to it) was where most of the work was done for this project.
When property does not serve its purpose it is no longer morally binding, just legally. And that’s if you convince me proprietary code ownership has any moral standing at all. Sometimes, I follow the law not because it’s particularly the right thing to do but because I don’t want to get in any trouble.
Different person, but when I asked if I could publish code as open source (where appropriate), I was told that that’s fine, as long as I don’t associate it with the company in any way (e.g. non-company specific stuff is ok).
So come on man, let’s be honest here. I got serious sacred masterpiece vibes from this story.
This reminds me of some Hindu parable about people who let go of possessions and head out to become ascetics. So there is this wealthy man and wife and the wife is all upset because her brother keeps insinuating that he’s gonna go ascetic and cut loose. The husband tells her to stop her crying and don’t worry about it, he ain’t going to do it. The wife asks him: ‘but how can you be so sure?’ Because, the husband says, this is how you do it, and then and there he rips open his shirt, tells her “you’re my mother” and heads out to the woods.
It's almost as incomprehensible as a Zen koan. I think the husband is showing the difference between talking and doing by, well, doing it. A radical way to demonstrate it.
What an utterly bizarre story. What’s the point of it? Why is the wife upset about her brother? Why is the husband so sure the brother won’t do it? What’s the significance of his little performance at the end? Why is the wife the husband’s mother, what does that have to do with anything, considering the issue is with the wife’s brother? Why don’t we get to see what the wife’s reaction to the husband’s stunt is - is she convinced by his actions, or is she as baffled as i am?
Did I just fall for a chat gpt generated nonsense fable?
It's a simple twist ending. The twist is that the wife was worried her brother would become an ascetic - but the person she should have worried about, the person who was planning to and did become an ascetic, was her husband. The performance is his declaration of asceticism, and the "you're my mother" line is a stock part of it, essentially meaning I renounce sexual attraction when said to your (former) partner.
I put one (possibly wrong) interpretation in an earlier comment.
As for the mother part, in many Hindu traditions monks and voluntary celibates are encouraged to see all women the same as their mothers, to remove temptation. Now he's an ascetic ergo his ex-wife is like a mother to him.
The cryptic yet amusing tone is much like a Zen koan, not a Hindu parable.
I think the wife is upset because "going ascetic" means cutting off contact. The husband is sure he won't do it because the brother is talking about it instead of doing it, which he demonstrates.
It feels like there should be more to the lesson learned than, "people who have decided will act, people who haven't only talk," but I am not quite grasping it. Maybe the other part is, "and worrying about things you cannot change harms yourself," or something?
That’s really not how it works. Ostensibly by showing it to box, it was written for box, and they would be well within a standard of legal standing to make your life a living hell for taking it elsewhere. You should really be more careful with what you say.
Why would you wontonly open yourself to legal liability? You say “they’re free to come after you” but you really _really_ don’t want that. Ive seen that happen to friends and the stress almost killed them.
You know, you're totally correct that they're well within their right to do... something. But why? What damages could they collect? It would take far less cash to rewrite the library I made from scratch than it would to pay lawyers to write some scary letters. There's no trade secrets. It's not even a novel idea. It would be terribly expensive and embarrassing for either Box or Uber to try to juice this even if they were motivated to. Hell, I'm technically still an active contributor to one of the OSS projects Box uses and maintains—absolutely treacherous ignorance that doesn't make me lose a second of sleep.
It’s not really about trying to figure out why they would do it. Think about pointing a loaded gun at your face. No one else is around and your hands are nowhere near the trigger. Would it be a good idea to do it? Most people would say no, because _why risk it_?
You had no good reason to tell us the origin of this other code, and could just as well have told us you threw it together a while back for shits and giggles. Or said nothing about it at all! But by writing out precisely why (in a very legally damning way) on your website, you’ve completely exposed yourself to litigation. You’re pointing the proverbial loaded gun at your face. And as far as consequences go, facing down a vindictive or irrational former employer in court is pretty close to that metaphor.
Depends on the contract but the most I seen stipulate not working hour but context of the work. If it was made by instructions of the company for the company and you got remunerated for that then it is not yours to do whatever you please with it. Better check your contract in details.
Example: "All Intellectual Property Rights with regard to Developed Materials will be exclusively vested in and owned by the Company." (with additional data protection and confidentiality clause protecting company property)
Sergey Aleynikov (born 1970) is a former Goldman Sachs computer programmer. Between 2009 and 2016, he was prosecuted by NY Federal and State jurisdictions for the same conduct of allegedly copying proprietary computer source code from his employer, Goldman Sachs, before joining a competing firm.
Which would be a great solace to someone who just spent $10k or more like 2-3x that responding to a lawsuit. But that's also why I agree the odds of actually getting sued are near-zero.
Some companies, armed with floors of attorneys and retained outside counsel, do that sort of thing just for the message alone. It costs them next to nothing, relatively, ruins the defendant regardless of outcome, and makes it clear for others to not mess around with IP.
Oh, you’re missing a few qualifiers. They’re not concerned with laws applied to them, and other people’s property. But in all other cases they’re big believers in law and using it to protect their property.
Since I enjoyed OP's story, I thought I should clarify a bit.
I'm speaking broadly of how I remember (from the outside) Uber's fast-and-loose IP attitudes in the 2010s.
I don't think OP did anything of a similar sort. From comments here it sounds like they used some code they built in their free time that a previous employer didn't want.
At Uber it sounds like they asked and were permitted to post their no-longer-needed code to GitHub. It's got its own GH org and everything.
This whole chain is legally risky (I wouldn't do it and would strongly advise others not to do it).
I feel OPs actions are not Ethically Wrong, though. I wouldn't enjoy living in a world where OP gets sued for this, since it sounds like nobody at work wanted the work and it's not giving competitors an advantage. I won't claim the world isn't like that, though.
I really wish I could share OP's attitude and sense of ownership. I built something really cool (entirely in my free time) for a previous employer's hackathon. That code lives on some server they own now, possibly deleted. I deleted my copy after submitting it to the hackathon because I didn't want to risk anything. Company lawyers make just building things for fun feel so risky! It takes the soul out of our work.
It's not just big tech that hates AGPL. If Terraform was under AGPL a lot of companies might have to release their source code as AGPL too because of its virality. Where it stops is not exactly clear from the license.
AGPL is almost exactly the same as GPL except that SAAS counts as distribution. That's the entire purpose of the license — to preserve the copyleft protections of the GPL in a world where most software people use is hosted.
Except it’s not just hosting the covered work itself as SAAS that triggers a distribution, but any derived work. If you use (say) AGPL MongoDB in your SAAS bug tracker, your bug tracker now needs to be AGPL too. The virality doesn’t stop at hosting a SAAS MongoDB.
That's probably not correct. While the AGPL is a little ambiguous, it probably does not infect other apps. That's why I created the Candid Public License (CPL): https://github.com/candiddev/cpl
Every lawyer I’ve talked to takes my interpretation. It may be overly cautious of them, but in practice, if something becomes the prevailing legal view, it de facto is the correct interpretation, at least until it is tested in court.
Recall that the GPL (non-affero) categorizes runtime linking to GPL’d binaries as a derived work. (This is why the LGPL exists, to allow for what the regular GPL restricts.)
The logic of the lawyers I’ve talked to (2 different companies on multiple occasions with different lawyers) is that the same wording that causes network access to count as “distribution” in the AGPL, also causes networked API access to count as a derived work.
It’s not all that crazy of an interpretation, IMO. My lawyers may suck and be overly cautious, but I’d wager this uncertainty is exactly why any sane company stays as far away as possible.
> Recall that the GPL (non-affero) categorizes runtime linking to GPL’d binaries as a derived work
If its not a derived work under copyright law requiring a license, a license offer can’t transform it into a derived work requiring a copyright license.
So, thought experiment: say I do want to take AGPL MongoDB, alter its source code, and host my modifications as a SAAS without releasing my modifications, and get away with it.
One way I could do this is by completely implementing its wire-format API of MongoDB as a proxy server to my derived MongoDB, and offer that up as my SAAS.
I could use a defense that I’m not distributing MongoDB, I’m distributing my proxy service I wrote myself. It just happens to be that my proxy service talks to MongoDB to do its job, but according to you that’s not a derived work, because network access doesn’t count.
For AGPL to still protect MongoDB in this scenario, the proxy-plus-mongoDB combo would have to count as the derived work, and I think the only way to do this is to count any API access as deriving a work. I think this is at least how the lawyers I’ve talked to described it.
GPL has already established that runtime linking counts as a derived work. If what you’re saying is true about “not a derived work under copyright law requiring a license”, then I don’t understand why the LGPL exists.
GPL's source disclosure requirements trigger on distribution.
AGPL's trigger on distribution or on allowing remote user interaction over a computer network.
> I could use a defense that I’m not distributing MongoDB, I’m distributing my proxy service I wrote myself
You aren't distributing either of them. When you run code on your server and people interact with it over the network that's not a distribution. If it was a distribution there would be no need for AGPL. GPL would be sufficient.
> It just happens to be that my proxy service talks to MongoDB to do its job, but according to you that’s not a derived work, because network access doesn’t count.
It's not a derivative work because it doesn't incorporate copyrighted elements of MongoDB (assuming you didn't actually copy code from MongoDB).
> For AGPL to still protect MongoDB in this scenario, the proxy-plus-mongoDB combo would have to count as the derived work, and I think the only way to do this is to count any API access as deriving a work.
AGPL would protect MongoDB in that scenario because you are allowing remote users to interact with MongoDB over a computer network. That this interaction happens to be taking place through a proxy shouldn't be relevant.
> You aren't distributing either of them. When you run code on your server and people interact with it over the network that's not a distribution. If it was a distribution there would be no need for AGPL. GPL would be sufficient.
I think you’re misreading this part of my comment: MongoDB is (or at least, was) AGPL, and AGPL defines network access as distribution. So I would have to justify whether offering my proxy service to network access counts as distributing MongoDB, or if laundering it through a proxy works around this. Remember that in my example, I did modify mongoDB. But I’m not technically offering this modified mongoDB as a service, I’m offering my proxy as a service, and hoping that it doesn’t count as “distribution” of my modified mongoDB. (i.e. I’m not distributing mongo, I’m distributing my proxy, and my proxy is not AGPL.)
> AGPL would protect MongoDB in that scenario because you are allowing remote users to interact with MongoDB over a computer network. That this interaction happens to be taking place through a proxy shouldn't be relevant.
Well, that’s the thought experiment that my example is intended to provoke… it seems obvious that my dumb proxy is a way to work around the AGPL, but what if we tweak the example? What if I make a web UI where you type mongo commands and it gives you the result? (Still pretty obvious, no?) What if I make a simple dumb CRUD app that happens to use MongoDB? (Less obvious…) what if the CRUD app is itself an extremely thin wrapper, and although it doesn’t implement any MongoDB protocols, it leverages built-in mongoDB functionality for 99% of the logic?
The point is, it’s not hard to imagine a legal theory that says “if network access equals distribution, then network access equals a derived/combined work”. It’s the theory that the legal departments of several companies I’ve worked for have taken. And I’d argue that if you have a proprietary product that uses an AGPL service as part of the backend, you have a rather large reason to be worried.
By my reading, the AGPL doesn't define "distribution" at all. It defines "conveying":
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
This definition specifically excludes networked API access.
Here's what the AGPL says about network access:
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.
It only applies if you "modify" the program. Does creating a proxy service count as modifying the original program? I think it could count as a derived work, but I would be very surprised if that counts as a modification.
Doesn't it prove GP's point? If you use MongoDB in your commercial software it gets infected with AGPL, because people interact with it over the internet - just like linking does with GPL.
> GPL has already established that runtime linking counts as a derived work
No, whether runtime/dynamic linking (or even static linking) creates a derivative work under copyright (as is when, to the extent it does, such a use would nonetheless be fair use and still not require a license) is still a contentious topic, and AFAIK there are no cases strongly suggesting a general answer.
A license offering permission cannot itself resolve when the law requires such permission. Arguing that it can is like saying my offering terms of permission to use my home and claiming that they apply to use of the public street out front establishes that I own the street.
If your argument is that AGPL can’t restrict me from using mongo in a proprietary product because copyright law itself does not restrict this, then you may or may not be right, I don’t think any of us know for sure until this is tested in court. I will say that the AGPL is written with the assumption that this is restricted by copyright law, so I don’t think your interpretation is the common one.
> One way I could do this is by completely implementing its wire-format API of MongoDB as a proxy server to my derived MongoDB, and offer that up as my SAAS
This is what Cosmos DB for Mongo DB is (wire format endpoint that talks to Msft’s own DB backend.)
The AGPL says "including scripts to control those activities" but if I understand what you are saying properly it means that the text of the AGPL is overreaching and some parts of it wouldn't be applicable?
Would the details depend on the country? Like it might be one thing under US law, and another in another country?
If the AGPL defines network access as distribution, it stands to reason that network access also counts as linking. See my other comments about a hypothetical proxy that thinly wraps mongoDB as an AGPL workaround, for why this gets hairy very quickly.
AGPL does not add any distribution clause... all distribution clauses are taken from the GPL...
The AGPL adds a modification clause so that if you ever modify the code even if you do not distribute the application, you still have to share the code or at least link to the version of the source code that you use. The loophole that AGPL fixes is that there are ways to avoid distribution.
This AGPL/GPL virality urban legend should have ended years ago.
There is no such thing as "virality". It doesn't exist. The worst thing you can do is violate the license terms and not be allowed to use the software that is AGPL licensed.
And yet everyone understands what this term means when applied to software licensing. Pretty good argument that this word, in fact, exists and has a well defined meaning.
Not really. The lawyer Kyle Mitchell said of the agpl,“Inebriated aliens might as well have beamed it down from space as a kind of practical joke.” Even lawyers have trouble understanding when its provisions are triggered.
The AGPL defines "Corresponding Source" as "all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities".
Then in section 13 it says that "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".
Isn't "scripts to control those activities quite vague? Under those terms wouldn't AWS Proton, IBM Schematics, Env0, Digger, Spacelift, etc. be required to open-source a very large part of their product as well?
I think, if Terraform was licensed under AGPL, then not only would all of those folks would have to also open-source their products, but also that would be the intent of the license in the first place
You could modify it easily, for example the user could register an additional function to the mapping. That would not be as easy to do with a module and getattr().
You can also list the registered function with math_exprs.keys() and that might not be as easy with a module either.
That is an entirely different use-case than a function signature allowing arbitrary keyword arguments. Arbitrary keyword args are different than arbitrary positional args like you have in your example.
GP is suggesting that one should only ever use explicit keyword-only args (anything listed after `*,` in the signature) versus arbitrary keyword args implicit via `**kwargs`.
e.g. (omitting type hints for clarity):
def sum(*args, **arbitrary_kwargs):
...
vs
def sum(*args, some_keyword_only_arg):
...
In my opinion if one finds themselves writing code that uses arbitrary kwargs, they've got a design problem.**
> It seems altogether surprising that with an empty list or tuple a, a[1] results in index error, yet a[1:] quietly returns an empty list or tuple.
`a[1:]` returns the sequence of elements that start at index 1. If there is no such element, the list is empty. I don’t see any good reason why this should throw an error.
Both cases are an index error. It's just for some other reasons in case of the section, the error is represented by an empty object and it's left to user to handle the result.
This could easily conceal the indexing error unless the caller code explicitly checks the length of the returned section.
> This could easily conceal the indexing error unless the caller code explicitly checks the length of the returned section.
An empty returned section doesn’t mean the index was out of bounds (`a[0:0]`); if you want to make sure you have to check the length before slicing, like in Go.
When you slice a list, you get a list.
When you see there is nothing inside the returning list, you know that means end of list, contains zero element.
Slicing and indexing return object at different level.
This should signal an explicit error, which invalid index is indeed. If user believes for some reason the invalid indexing is ok, then it could be caught and handled. No ambiguity.
I think it is consistent, it works a bit like filtering an element from a mathematical set.
Given a set of sheeps, let x be the five-legged sheep is inconsistent because we know neither the existence or uniqueness of shuch sheep, so it raises an exception.
Given a set of sheeps, let x be the subset of five legged sheeps is the empty set because there is no such sheep.
but this may also just be because I internalised Python's behavior.
Some language have a specific value to denote the first thing, for example:
["a", "b", "c"][4]
gives `undefined` in JavaScript but it differs from `null` which would be the equivalent to `None` in Python (and I don't think Python has such concept).
a[1] has to raise an IndexError because there's no return value it could use to otherwise communicate the item doesn't exist. Any such value could itself be a member of the sequence. To behave otherwise, Python would have to define a sentinel value that isn't allowed to be a member of a sequence.
When using slice notation, the return value is a sequence, so returning a zero-length sequence is sufficient to communicate you asked for more items than exist.
It may be surprising, but it almost always leads to more ergonomic code.
FWIW Rust does not have variadic functions. The closest thing would be either macros, which are variadic, or trait methods, which are not variadic but can look like they are.
How is it more "readable"? The two are just as readable.
What do you do with your first example if you have a list (generated at runtime, not a static one) to pass to the function? This wouldn't work (imagine the first line is more complicated):
Your example has a fixed number of names. What if you wanted to accept any number of names, like Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso? Really, though, Iterables make more sense for monadic types.
I knew a Chinese girl whose parents, surnamed 吕 and 郎, wanted to give her the combined surname 吕郎. This was not allowed, so formally she was surnamed 吕 and given a three-syllable personal name starting with 郎.
There are a couple funny things about this:
1. A personal name of three syllables is stranger than a surname of two.
2. Double-syllable surnames are unusual, but definitely not unheard of. This girl told me that she hadn't been allowed to receive the double surname 吕郎, because it was too long. I asked what would have happened if her double surname had been 司马 instead. "That's different!"
(If the government of China tried to pick a legitimacy fight with the name 司马, it would lose, and everyone knows this.)
So this almost looks like an example of the kind of thing you're referring to, except that the database scheme has nothing to do with it. A surname that was nontraditional but within the technical norms was rejected in favor of a personal name that was both nontraditional and well outside the technical norms.
Whenever we're extending an external library, we're submitting the change upstream. Whenever there's an opportunity to sponsor a project on which we heavily rely, we do that. But yes, we don't maintain any major open source projects as a company. And neither will we with OpenTF, because our active involvement with it is only temporary - we are just helping it get off the ground. Long term we will be primarily a sponsor of a dedicated team (see our pledge), not a core maintainer.
spacectl, vcs-agent and terraform-provider-spacelift are only useful with your proprietary product. prometheus-exporter is a very small exporter to monitor your proprietary product and has no utility beyond that.
I'm not sure what spcontext does because it has no documentation but I'm sure I could read the 10 commits to find out. The only none trivial project in the list is celplate which actually looks nice, but even there most of its complexity is in cel-spec.
> Whenever there's an opportunity to sponsor a project on which we heavily rely, we do that.
Come on, on Spacelift GitHub profile there is one project sponsored, and only since August 24!
> we don't maintain any major open source projects as a company
So you never had to handle project management of large open-source supports, community support, doing code reviews every day and handling feature requests from the community?
Yes, HashiCorp has been slow to respond to PRs and did not always commmunicate clearly, but so does many large open-source project like PostgreSQL, Python, Linux, etc. Managing a large open-source project takes more time than clicking on the merge button on GitHub. Users don't magically come fix all the bugs in the software, and develop complex new features.
HashiCorp did contribute a lot, and there is still a lot to learn from their projects, there is Raft, the autopilot, various library that are used a lot in the Go ecosystem, including go-plugin, a programming language with its specific type system and plenty more. After all, the change of license is making noises because we their tools defines part fo the DevOps world and we all use them a lot.
I wish HashiCorp would have kept using the MIT license, but using the BUSL is still miles ahead better than companies that are completely closed source.
From the outside perspective it looks like you support Free Software as in Free Beer more than in Free Speech. You are supportive when others are actually maintaining the projects for you, and you just want them to merge your contributions quickly. It is a very efficient way to externalize some of your costs, but you only step forward to actually to help manage them when your bottom line is threatened.
That's ok, it looks like you love money more than open-source ideas. That's perfectly fine but don't pretend otherwise.
Some others companies that signed the pledge have actually been maintaining open-source projects and have a leg to stand on. Spacelift loves having the high moral ground and the extra publicity.
Release the core of your product as open-source, like HashiCorp did for 9 years, and it will change my mind.
Nobody is pretending anything, and I don't care about changing your mind. We are donating engineers and funds to an independent project, whose value is entirely independent of what you think about Spacelift as a product or as a company, or any other argumentum ad personam you can come up with.
"Nobody is pretending anything" Wrong, wrong, wrong. The whole thing has been PR to cast hashicorp as some evil company who withdraws from Open Source. It's quite hypocritical to pretend to support Open Source from companies which don't even have source available!
Cut the bs please, this is just a self-serving fork. You all don't give a shit about open source, you just want to keep using TF in competing services for free.
I don't agree with your sentiment one bit but I will not try to change your mind. At the end of the day what matters is the outcome of the project for the community. So let's all take a deep breath and revisit this in a few months time.
> Yes, some applications will remain hard / impossible, but I'd argue Python is not a good fit for apps requiring high performance / high scalability anyway
People are already trying to use Python for parallel tasks. Forcing people to use another language does not help them much.
For now there is nothing impressive with it. The perfs they show off don't include data sharing, which is very primitive.
Which means there is nothing subinterpreters do that can't be done with multiprocessing.
They show progress, and it's good. But I would wait until we can see gunicorn spawning WSGI interpreters workers and get similar performances to the setup with regular workers to get enthusiastic.
to further your point: I've used the technique launching a separate python process for performance critical operations for years on different projects. I can run it in a completely different priority set as well.
I have a use case for sandboxing (without a secure-sandboxing requirement) that it would help solve. But at last read, they discourage/disallow sharing modules across the subinterpreters and reloading all modules in each subinterpreter is not acceptable for my use case.
They were always usable using the C-API but not exposed to the Python library (and until 3.12 you were blocked by the shared GIL so there was little point anyway).
I'd be interested in introducing appropriate abstractions (ABI) and in a module for parallelism. Whereby one can swap out different implementations for sub-interpreters, green threads, GIL or even hardware or cloud vendor-optimised implementations. Not that dissimilar to Project Loom in Java.
Yes this is a thing was trivially protected by the GIL. There is the same thing with mutating the same map concurrently in Go that will panic for example.
PEP 703 goes over this in the "Container Thread-Safety" (I think container here refers to the fact that the object has references to other objects, this is the things that already are special-cased in CPython to be managed specifically by the garbage collector):
> This PEP proposes using per-object locks to provide many of the same protections that the GIL provides. For example, every list, dictionary, and set will have an associated lightweight lock. All operations that modify the object must hold the object’s lock. Most operations that read from the object should acquire the object’s lock as well; the few read operations that can proceed without holding a lock are described below.
Note that concurrency of containers not specific to Python any way.
For example, Java implements different versions of containers for single thread and multithread usage, because multithreaded containers have obvious performance penalty
> For example, Java implements different versions of containers for single thread and multithread usage, because multithreaded containers have obvious performance penalty.
Very few codebases in Java are single-threaded; specialty frameworks like Netty are the exception not the rule.
Likewise, there are not different containers for single threaded and multithreaded usage; there are containers that have different strategies for dealing with multi-threaded usage.
Hashtable is the oldest and is notable for it still being present and still being fundamentally flawed. It will lock reads and writes, but does not describe a way to lock for a transaction - e.g. changes based on read data. As such, it fundamentally has race conditions you can't protect against.
Hashmap and the rest of the Java 1.2 collections API set a slightly better pattern - they don't internally try to maintain safety, but provide mechanisms like synchronizedMap() to let you hold the monitor for the length of your transaction.
However, this could only be so good, because the monitors in Java are pretty fundamentally broken as well. A monitor is both part of its public API ( e.g. "synchronized(foo) {...}" ) and part of its implementation (e.g. public synchronized void bar() { ... })". This means that external code can affect your internal operation if you leverage the monitor that you get by default through your "this" instance.
As such, synchronized set involves three monitors:
1. The monitor on the interface-implementing collection type itself, e.g. on the HashMap. This likely is never used.
2. The monitor on the object returned by the 'synchronizedXXX' wrapping method. This is used to protect transactional access, such as iterating through while removing items.
3. The monitor used as a mutex inside the object returned by the 'syncronizedXXX' wrapping method, protect the integrity of the collection data type if used by multithreaded code which does not hold monitor #2. The code may have a race condition, but it won't put the collection itself into an inconsistent structural state.
The 'synchronizedXXX'-returned wrapper objects are pretty expensive, and if you can you should just internalize those collections into business object that does any needed syncronization itself.
ConcurrentHashMap and the like are lockless, and are built with the idea that you can perform the changes needed through atomic operations rather than transactions. This isn't always true, but often is.
For a collection which is always held by a single thread, the atomic operation overhead may still cause a performance impact - after all, the atomic operations are still processor state synchronization points. It is also possible to beat ConcurrentHashMap with regular HashMap on certain usage in multithreaded environments, when you are properly protecting access to the HashMap yourself.
It might be challenging to find scenarios where ConcurrentHashMap doesn't beat the 'synchronizedMap()' wrapper, just because the implementation itself is really expensive.
Thank you! That makes sense, and it also explains why removing the GIL has a negative performance impact as discussed in other comments. Taking a lock every time a container is accessed is significant overhead, which is why languages like C++ don't make basic containers thread-safe.
> Effectively the GIL is incurring that overhead on every data structure whether you need it or not.
Not really. The GIL is taken and released quite infrequently (only when the Python interpreter decides it's time to do a context switch), whilst the new locks for each data structure are taken/released every time you do a basic operation on those data structures.
Holding a lock that is rarely taken/released incurs very little overhead.
My idea was to take this code and spruce it up for Uber’s use case."
"My first reaction was to publish the code on Github."
I’m very surprised by this, isn’t the code property of Box, or Uber? The author does not mention their authorisation before releasing it under MIT license.