Threads for kemitchell
-
It isn’t possible to implement ActivityPub without a server and a database. You can’t do it with just a static site.
This feels like an enormous miss.
What’s the under-over on whatever Mastodon does becoming de facto standard?
-
When you say “whatever Mastodon does”, what do you mean exactly? It’s still generally operating within the ActivityPub spec, though I guess it has some extensions that make things a bit easier at scale. The standard itself is open-ended and can be used in different ways, it mostly just describes a format and how a set of existing technologies should be used together to create a social networking experience.
Hopefully, Mastodon’s influence in the fediverse will drive evolution of the ActivityPub spec to help with managing large-scale instances. Personally I think the killer feature of federated social networking is the ability to expose your work to an audience beyond whatever community/app you happen to be posting from. If I post music on FunkWhale, I don’t need to repost it to Mastodon, you can just follow my FunkWhale account on your Mastodon account.
-
-
quad
6 months ago
|
link
| on:
mold 1.7.0 - author seriously considering license change away from open source
Sounds like a job for https://patronlicense.com/versions/1.0.0.html
-
To accept these terms, you must be enrolled to make regular payments through any of the payment platforms pages listed above, in amounts qualifying you for a tier that includes a “patron license” or otherwise identifies a license under these terms as a reward.
How long does one have to be a patron? Indefinitely?
-
-
-
It was written by a lawyer who specialises in software licensing, @kemitchell.
-
It does not seem to have been written or edited by a lawyer.
Made my day.
The language is rather weak and I would be extremely hesitant to use this for anything of value.
What strikes you as weak about the language?
-
most free software legalese is excessive in it’s verbosity.
-
-
-
A few things to note about selling support, from my experience:
- If your software is easy to use and works well, companies are often reluctant to pay for support (since they don’t have to).
- Corollary: if people who have no problems don’t want to pay for support, your customer base is likely to consist of people with really unusual and complex problems.
- If you are open about being an individual or a small company, the pointy-haired bosses who make purchase decisions will often hold it against you (even if you are literally the only support provider for your software in the world).
-
This is largely my experience, too.
There are exceptions. But these seem to be the rules.
-
-
I’m not sure all the famines and skull piles are really worth it for OSS support contracts.
-
-
-
-
That, sir, is a right snappy blog post title.
-
Contracts that don’t allow for a meeting of the minds are inherently lacking. Regardless of whether it’s evil, it’s certainly not fair. As somebody pointed out on the orange site, proprietary software usually is not sold with such rich support contracts, and rich support is the only supposed advantage of a non-FLOSS EULA.
As we covered last time, claims like “won’t be infected with malware, won’t be riddled with security holes” are not upheld by proprietary vendors. Similarly, plagiarism or inappropriate reuse of licensed code (e.g. use of code from Stack Overflow without citation) is rampant. So, the only thing left that a proprietary vendor can offer is an SLA (and discounts for committed use, etc.)
-
“Meeting of the minds” is really important latent wisdom. I agree it’s been neglected. And I’m glad to see it mentioned in a software forum!
I can’t agree that support is the only advantage of a commercial deal. I think that’s just one aspect of taking responsibility for the software sold. Same for quality, security, and IP guarantees.
I have definitely seen commercial software vendors fall down on quality, security, and IP. Same with open source, of course. Software isn’t perfect, and no license agreement can make it so. Nor would a typical customer pay perfection’s price. There are exceptions: medical devices, weapons, critical infrastructure. Fields, as a rule, where open never caught on as elsewhere.
So software’s imperfect, but license terms say it should be. The value isn’t just in telling pleasant lies. The value is that when things go wrong, with consequences, the vendor’s committed to stand responsible, financially. With dollars at risk, they’re incentivized to invest in prevention.
If the customer fears the vendor may be under-investing, they can insist the vendor carry insurance. The carrier in turn will question vendor’s practices and price their premium accordingly.
-
Returning to my Sony BMG example, at what point did Sony BMG fully disclose what they had done, instead of lying? They shrugged off several class-action lawsuits, and only an FTC action was able to reimburse customers; were they accepting responsibility? Was their insurance affected?
In the linked thread on the orange site, it’s shown that licenses like AGPL are comparable to your list of terms in a “proprietary” deal. The main distinction are these two clauses:
the seller guarantees the software will work as documented, won’t be infected with malware, won’t be riddled with security holes, won’t contain plagiarized code; the seller provides support and maintenance via e-mail, with a response-time service-level agreement
This first clause is completely countered by the Sony BMG example. They published malware, the malware opened up security holes by installing a rootkit that sheltered other malware, and the malware contained plagiarized Free Software without appropriate licensing. This really does happen, the consequences are dire, and the publishers walk away without effort.
The second clause is just selling software as a service with an SLA!
(I apologize for pulling teeth, but it’s clear that you’ll ignore anything cited unless it’s directly quoted or explained.)
-
(I apologize for pulling teeth, but it’s clear that you’ll ignore anything cited unless it’s directly quoted or explained.)
That’s not an apology. I’m not throwing time or attention after it.
-
-
-
-
-
What does evil mean in this case? To me, it means a EULA that:
- gives more advantage to the software creator/seller than the customer, when it should be equal, and/or
- absolves the creator/seller of responsibility.
With that in mind, I think Mr. Mitchell is right in general.
In practice, how many EULA’s are not evil? I think Mr. Mitchell has probably seen a few, probably written a few. I think that may be because his work is probably mostly between two business customers.
But as an individual software consumer, I have never seen such a EULA. I’ve only seen EULA’s that are “evil” (which I define as a EULA that gives more advantage to the software creator than the customer, when it should be equal), at least in the software that I use.
That is why I use Open Source software as much as possible: that extreme is better than the other, of being locked down by EULA’s that advantage the creator over me or absolve the creator of responsibility.
This is in addition to a few of the other problems mentioned by comments on the orange site.
So in theory, practice and theory are no different; in practice, they are.
But it would be a good world if Mr. Mitchell was right in practice, as long as customers always had access to source code and the ability to modify it, and the creator/seller accepted responsibility for it.
-
It’s also a rare case of arguing for a strawman. ;)
The customer can fix bugs and make improvements. Better yet, while they pay, they can foist this off on the seller. What the customer could usually only hope for in the best case with open source—a timely response from a responsible person—they now get by right, under contract.
The problem is that for all practical purposes such an EULA doesn’t exist. No software developer can be expected to do any work without an incentive to do that. If there’s a problem the vendor isn’t personally having and leaving it unfixed does not lead to significant user base shrinking, they will not do it, and who can blame them?
EULAs with negative financial incentives for the vendor to fix bugs/add features or solve your problems kinda do exist, but they are out of reach even for average business users. There are also many ways to game those incentives by sticking to their letter without keeping their spirit, e.g. giving a reply within the SLA timeframe but not supplying any actually useful information there. And then even the most well-intentioned support providers should be wary of any guarantees to solve the problem, because anyone can take you to court and claim you didn’t solve their problem. That’s not counting cases when a problem really can be solved.
If people can share modified versions, there may be hope that someone is having the same problem as you but better programming skills and will make a patch. In a “use, but don’t distribute” model there’s no way for anyone to share it, so even if someone fixes it, you will not benefit from it.
P.S. For the record, I do make money from open-source software with a “pay for precompiled binaries and support” model, and we do have a EULA covering the binaries with proprietary and trademarked artwork embedded in them (exactly like RedHat and Mozilla do). But we don’t give any guarantees of solving user’s problem because it would be false advertising. We don’t game SLA response time guarantees that we give, because we all had multiple proprietary vendors play that trick on us, and we hate it.
-
The problem is that for all practical purposes such an EULA doesn’t exist. No software developer can be expected to do any work without an incentive to do that.
Licenses like that get signed all the time.
The vendor’s support commitment requires them to respond timely to requests. Where those requests identify bugs, the result is a fix, which the vendor’s maintenance commitment requires it to provide. If the vendor falls down on its support commitment, the customer gets credits against its fees, and possibly an out from the contract. The vendor’s incentivized to avoid that.
Blank-check commitments for new features aren’t so common, for obvious reasons. I have seen many deals where particular roadmap points got included in the terms. But even without a hard commitment to develop new features, support request → roadmap item → minor release stories are very common. Features existing customers ask for can be features potential customers want.
-
Maybe if you pay hundreds thousands dollars… Haven’t seen anything like that from proprietary vendors in the thousands or tens of thousands dollar range.
I have seen bugs in very expensive software go unfixed for months and years just because they weren’t affecting the majority of users, and it wasn’t a real threat to the vendor. I did see many prompt fixes, mind you, but my point is that in the vast majority of cases there’s no guarantee that your bug will be fixed, no matter how critical is it to you.
-
I have definitely seen good support SLAs in that range of ARR. And happy customers who never had to send a ticket!
I hear you on languishing bugs in pricey software. It happens. Frustratingly, sometimes it’s just efficient.
I have also seen side deals where customers ponied up extra to get a bug squashed or a feature added, even one arguably covered by their existing support-maintenance deal. The remedies under that deal weren’t enough to move the vendor, and the loss from the customer walking came in under the cost of the fix. Another day at the office.
I think we’d probably be better off in a wold with more source available deals like the one I outlined in the blog post: fix it yourself if you want to, just send the patch back to the vendor. But often enough, the vendor’s still the one who can get the work done with lowest cost, especially when the customer isn’t a “software company”. The vendor has the people who know the code.
-
-
-
-
In practice, how many EULA’s are not evil? I think Mr. Mitchell has probably seen a few, probably written a few. I think that may be because his work is probably mostly between two business customers.
But as an individual software consumer, I have never seen such a EULA. …
I really appreciate this comment.
I was 50-50 on the second part of the blog post, after the
<hr>. The bit where I speculate on why this black-white view persists. I knew my speculation’s informed, but speculation’s always a jump. I worried it would distract or detract more than it added. I’m glad I went with it now.The HN discussion already has two or three threads where I see someone with software deals experience butting heads with someone who only sees take-it-or-leave-it terms. Here you’ve hit the same insight with introspection, without all the noise and squabble. It’s nice to be here on lobste.rs ;-D
The relevant bit of my post was here:
[The black-and-white view of licensing] reinforced a stark, limited view of the industry—characteristic of young and commercially sheltered coders dealing entirely with dominant apps from megacorps, on one hand, and open source from hackers, on the other—as all relevant reality. There wasn’t any burgeoning gray area of independent software sales in this picture…. No experience of negotiation—engineering terms to circumstances—to speak of. No rallying call to develop those chops.
When a vendor has you over a barrel—market power, exclusive deal—the terms they deign give are more than likely bad news. Same with the software, for that matter. Microsoft doesn’t need to give us source code to keep Word in pole position. If a hardware vendor controls their tech, the dev kit can be lousy.
As solo devs cruising the web for code, we have no leverage. The cost of just discussing terms with us would eat all our value as potential customers. So terms are take-it-or-leave-it.
The reason I’m on about this to solo devs and indie firms is that I think we could get a lot more out of ourselves and each other if we accepted that deals engineering is an art we can get good at that could unlock a ton of latent potential. Some of this is business basics: many firms now offer multiple take-it-or-leave-it deals, at different “tiers”, with a features grid. As programmers, we have the skills to do that and so much more. And we have the skills to automate it—software configuration, legal terms, payment, the whole shebang.
-
I’ve had great success moving from one file to … multiple files. You can even use subdirectories!
-
I’m the author of the article that Mr. Mitchell is responding to.
tl;dr: I think Mr. Mitchell has good points, but I also feel like he did not address the parts of my post that actually discouraged me.
I didn’t expect to have anyone respond with a blog post like this. That said, Mr. Mitchell has some good points.
First, he is right that my original article is too absolutist. I will own that mistake. Please remember, however, that the post was written in the middle of a depressive episode, when I was feeling more discouraged than I had been in a long time. I wasn’t thinking completely straight.
Second, he makes a good point about trying hard to serve people, but what he missed is that I had done that. In the types of software I want to write, I could see very well that closed source was not going to fly with my intended audience. @alexandria said (in this thread):
People will only pay for closed source software if they can’t already acquire a ‘good enough’ alternative for free.
As far as build systems and version control systems go (the top two projects I am working on), there are plenty of ‘good enough’ alternatives that are Open Source, so developers only want Open Source, for the most part. Of course, there are companies that will use closed source, if it is better, but individual developers, by and large, don’t, especially because they often don’t need the features that make the closed source ones better.
The reason I am targeting individual developers is because they are the most likely to be “early adopters” of new technology. I was hoping that, after getting enough of them as users, they would convince their employers to start using my software.
Third, and this follows from the previous point, Mr. Mitchell has himself said that, over time, software moves from closed source to Open Source, then to public domain. I had read that post of his before posting mine, and I understood what he was saying. I guess what I did not say well is that, for the software I was planning to write, the transition from closed source to Open Source has already happened, which means that going closed source would not work.
Fourth, I don’t feel like Mr. Mitchell addressed the points from my original post that actually made me discouraged: the appropriation of Open Source by companies who fail to give back or outright steal (by violating FOSS licenses). Those things are the reason I was discouraged because, even if I do get individual programmers to use my software, then they get their employers to use it, what will prevent their employers from just ripping me off and violating the license I put on my code?
The fact that developers will use closed source in some cases, as Mr. Mitchell says, does nothing to address these problems.
With that said, I don’t regret putting that post out and submitting it here and to the orange site, and that’s because my “call to action” at the bottom, asking people to contact me if they knew things that could encourage me, worked. A lot of people emailed me with encouragement, and that eventually brought me out of my funk.
One person in particular, who I won’t name in case he does not want to be named, wrote to me about an article he wrote a long time ago about how it’s possible to make a living selling closed source software that is only closed source temporarily before being open sourced after a certain amount of time. He helped me see why that works, and he also helped me figure out a method for not violating my ethics in doing so.
(My ethics include always providing source code to my users, like an architect should provide blueprints to the owner of the building they designed. What this person helped me realize is that even if it’s closed source, I can provide source code to my customers with a license that prevents them from redistributing it. Yes, this is an argument for copyright still applying to software.)
That, along with Mr. Mitchell’s assertion that all software eventually moves toward the public domain, helped me form a plan.
First, I’m going to get the software ready, of course. But when it’s ready, I’m going to release it under the terms of the two most radioactive licenses possible: the SSPL and the AGPL, and users will have to comply with the terms of both. This shouldn’t matter for individual developers.
However, it will matter to companies, so next, I will do my best to make sure my users know that they can ask me to relicense more permissively once they are asking their employers to use my software. When they ask, I will.
I will also develop closed source add-ons that companies can use, and these add-ons will be open sourced after a certain period.
In essence, my software will follow the transition from closed source to copyleft to permissive licensing that Mr. Mitchell described; it’s just that instead of more permissively-licensed competitors rising up and out-competing me, I’ll relicense my stuff to prevent the need for competitors to do so.
That does beg the question of why I wouldn’t start permissively licensed in the first place, and the answer is to make my software radioactive enough that at least some companies won’t touch it at the beginning. It’s a game of numbers because I don’t have to prevent all companies from ripping me off, just enough of them. And after my software grows more important (if that ever happens), then I suspect that companies would be less likely to rip me off, even if the software is permissively licensed.
It’s funny, but Mr. Mitchell did help me, in a way, with his post about the lifecycle of software licenses.
-
Forgive me for catching up with you here! I’d made a note to send you an e-mail, properly, which I try to do whenever I blog a response to someone else’s post. But Saturday caught up with me. I got the post out, and didn’t look at my to-dos again until this morning.
Note to self: Publish the post, then send the e-mail. Don’t put it off!
I hear you on discouragement and depression. Man is that real, and I’m inspired by how honest and open you are about it. I wish I’d thought more about where you may have been mentally as I wrote, and done more to emphasize a helpful rather than corrective tone. If I’d caught you still in it, and come across too harsh—easy to read that way when you’re down, don’t I know it!—I could have done you wrong. I’m happy to read that my post found you standing firmer on your feet. I just got lucky there. Also that others stepped up with so much encouragement. A little faith in community restored.
As for company and user misbehavior: oh yeah, that’s real. And I’m really fucking tired of it. And I’m probably doing disservice by taking it as a given, whenever I write. By focusing just on the jump from frustration to resignation, without honoring the frustration to begin with, my post falls short of a complete picture. Your notes there are very well taken.
On licensing, I’d encourage you to consider a license choice that more clearly expresses your intentions. A mad-science hybrid of AGPL and SSPL will definitely freak people out. But if what you really want to say is “businesses needs to talk to me about a deal”, you might find that better expressed through a noncommercial license like PolyForm Noncommercial or Prosperity, which also allows free trials. More experimentally, you might find Big Time interesting.
Whichever way you go, good luck!
PS: No need for “Mr. Mitchell”, unless you prefer that way. Kyle, or kemitchell, do me fine. And kyle@kemitchell.com anytime.
-
First, I’m going to get the software ready, of course. But when it’s ready, I’m going to release it under the terms of the two most radioactive licenses possible: the SSPL and the AGPL, and users will have to comply with the terms of both. This shouldn’t matter for individual developers.
However, it will matter to companies, so next, I will do my best to make sure my users know that they can ask me to relicense more permissively once they are asking their employers to use my software. When they ask, I will.
That depends a lot on the company. I’d have to check our policy but I believe it means that we could use it, we could maintain our internal fork, but we’d need to jump through approval hoops to contribute anything back. Licenses like the AGPL are problematic if we want to incorporate them into a product or ship them to customers (or, in general, do anything that involves the code leaving the company) but they are fine for use.
The critical thing for a company (which I’d assume @kemitchell knows, since he is a corporate lawyer and this is literally his day job) is minimising risk. The license is one aspect of this. Dual licensing doesn’t really help here because it lets you choose between risks (the risk the supplier will go away for the proprietary license versus the risks associated with a less permissive license). If your dual license allows people to pay for a more permissive license (e.g. MIT) then you now have a risk that someone will distribute the version that they receive.
For a single developer, the largest risk that a company is likely to worry about is the bus factor. If you get hit by a bus, what happens to the software? That’s a massive risk for anything that’s going to be a core part of the work flow. There’s a big difference between buying a proprietary product from a big company and a proprietary product from some guy, especially if it’s a product with a lot of users and that is bringing in a lot of revenue.
Open vs closed is one of the less important concerns within an overall risk discussion for most companies.
-
That depends a lot on the company. I’d have to check our policy but I believe it means that we could use it, we could maintain our internal fork, but we’d need to jump through approval hoops to contribute anything back. Licenses like the AGPL are problematic if we want to incorporate them into a product or ship them to customers (or, in general, do anything that involves the code leaving the company) but they are fine for use.
That actually sounds perfect, to be honest, including not giving back code. I’m interested in companies contributing back in general, but for my own purposes, I’d rather not incorporate code copyrighted by Microsoft into my repo.
That said, I don’t really like the SSPL and will probably remove the requirement for it soonish after the code is published.
The critical thing for a company (which I’d assume @kemitchell knows, since he is a corporate lawyer and this is literally his day job) is minimising risk. The license is one aspect of this.
I think I understand the position companies have on risk, and I want to do my best to make risk minimization the real product I am selling.
Dual licensing doesn’t really help here because it lets you choose between risks (the risk the supplier will go away for the proprietary license versus the risks associated with a less permissive license). If your dual license allows people to pay for a more permissive license (e.g. MIT) then you now have a risk that someone will distribute the version that they receive.
Those risks are partially why I’m not going to dual license the core.
For a single developer, the largest risk that a company is likely to worry about is the bus factor. If you get hit by a bus, what happens to the software? That’s a massive risk for anything that’s going to be a core part of the work flow.
Yes, I agree, and it is a weakness of what I would like to do. But I do have some techniques for reducing the impact of the risk from the bus factor.
First, I document my code heavily. You can see this with my
bcespecially. The development manual inbcis the largest file, by far, in that repo. But I didn’t stop there. I commented every piece of code heavily so that someone else could go in, follow what I was doing, and be able to understand it. This reduces the impact of the bus factor by making it so users can have the backup plan of fixing bugs themselves if I get hit by a bus, and that backup plan has a chance of working.Second, I create extensive test suites. Once again,
bcis the example. The test suite is so extensive that I feel comfortable making massive experimental changes and just running the test suite (usually under Valgrind or ASan) to see if there was any regression. Should I get hit by a bus, the test suite then becomes a tool for anyone else wanting to make changes to do so without fear, just like me, which I believe reduces the impact of the bus factor.Third, companies can pay for the privilege of making the time factor a non-issue, and by “time factor,” I mean the possibility that I don’t have enough time or motivation to respond to their bug reports in a timely manner. But that’s the risk that they themselves have to mitigate; I can’t help with that.
There’s a big difference between buying a proprietary product from a big company and a proprietary product from some guy, especially if it’s a product with a lot of users and that is bringing in a lot of revenue.
I agree. In fact, it’s why I am doing all of the stuff I mentioned above. Doing those sorts of things brings a one-man project closer to a product from a big company. I think it’s why a project like Curl, which basically has a bus factor near 1, is so successful and widely used.
Sorry, said to much, but tl;dr, you are right about risk, I know you are right, and I’m doing my best to mitigate that.
-
I’d also add that risk and perceived risk are both important. It sounds as if the risk is low but I’m not sure what to suggest for reducing the perceived risk. A company has to do a lot of analysis of your code to understand how difficult it would be for someone to take over but that’s probably more work than most companies would do. You might be able to do some equivalent of underwriting: have some other company like Red Hat or Canonical provide maintenance contracts that they subcontract to you.
With curl, the reason that the risk is low is that, to a first approximation, everybody depends on curl. This means that, if Daniel were hit by a bus then everyone is equally screwed. If you are not the biggest company depending on curl then you can depend on someone else leading the effort to pick up maintenance costs.
-
-
-
-
I use proprietary software for work. It has great features, like forcibly mangling SHIFT-JIS comments into Window-1252 with no way to change my encoding. Or features like bizarre, fucked up proprietary file formats that are impossible to diff with git unless you pay $250, per head, per year, for their “git integration” license. Or really, really cool features like making breaking changes every sub-release of the ide/language, and then recommending that you use a VM to keep your old version around because they also couldn’t figure out how to let you use choose which version you wanted.
I would rather not use proprietary software for development.
-
-
No, there isn’t any open source tooling in industrial automation. Most factories have a set of PLCs they bought in the 90s, and you need to buy that brand’s IDE to do work on that machine. So mitsu PLCs require you to hunt down a copy of GX Developer (and you better hope said copy is a Japanese one if you’re working in a Japanese plant or else you’re fucked), wago PLCs require their ide, and so on.
-
opcfoundation.org ?
-
OPC mostly encompasses data sharing from PLC to PLC or PLC to scada system, right? And typically, most factories use the proprietary system: MELSECNET for Mitsu machines, can’t remember what the other ones are called. There is a standard for languages that a PLC should support: IEC 61131-3, but not every manufacturer follows the standard.
-
-
-
-
-
TextMate and Transmit being “better than anything apt-get could give me” sounds rather amusing, considering that both vim and emacs have exploded in popularity in the last decade by taking in lots of those TextMate users :) And TextMate 2 is GPL, haha.
Some programmers use proprietary software, sure. Outside of game dev though they more often than not absolutely despise it.
The number one practical problem with using closed proprietary software is that you’re literally going back to basically where Stallman started – with that printer driver that he couldn’t just fix because it was closed.
doing open source because that’s what we want to do, what we’re reinforced in doing, all the while invoking generalized, thoroughly hypothetical “users” to lend importance and nobility to our hobbies, compulsions, and fancies.
I generally don’t think that much about users when working on hobby projects and don’t care about nobility. My projects are open source just because why the hell would I keep them to myself? They would just go to waste there and probably be lost forever. The public is the best backup/preservation system there is. If I helped someone by doing that, well, that’s just a nice bonus to me, not the goal.
-
My reference to better-than-apt referred to that earlier time, when TextMate was hot new stuff. The day I bought my license, there wasn’t any comparable substitute in open source. And certainly nothing like the filesystem-based integration with Transit.
Folks cloned the snippet system for Vim and Emacs pretty quickly, at least partway. But that wasn’t really even half the TextMate proposition. It was just the most visible bit, from the screencasts. It took a long time before anyone really went after the bundle system, the configuration flow, the UI, and the command namespace. When they did, they actually maintained TextMate bundle compatibility—direct clone. Eventually, Atom. More or less a GitHub founder’s pet project, so I’m told.
I’m back on Debian now. UltiSnips for Vim, in the terminal. But the kind of work I do has changed. And it’s been 17 years. If Allan Odgaard had kept up pace with new ideas, rather than diverting into a big, HURD-style rewrite, I wonder where editors would be today.
I think it’s fair to set games somewhat apart as its own world. It’s not really the same industry. Ditto film. But my experience doesn’t track yours beyond that. People despise bad software. Despite the hype, open ain’t always better. Mako Hill had a good bit on that.
As for what people despise, I wouldn’t take that as any indication. Twitter’s full of folks venting about open source, too. Especially when they’re made to use it. That’s not to draw any equivalence. It’s just to say samples of grousing don’t tell us much.
The Stallman printer story is canon. But I don’t think that makes it real. Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add. They want to call somebody who knows the system, who’s committed to deliver. Or, failing that, drive-by some GitHub repo with a #feature issue, and miraculously see it closed by a PR on the double.
For good, closed software done right, the end user experience is actually better. You ask, someone capable responds. No one calls you a noob, tells you RTFM, or throws the work to open a pull request back on you. The work gets done by the person best positioned to do it. The experience of the software honors the value of your time.
I have more than a thousand GitHub repos, and have publicly referred to the platform as a shellmound. I’m not sure my random doodle repos counts as open source, for any meaningful sense of the term. GitHub don’t even insist on a license for free storage, as long as you’re comfortable hanging your laundry in public.
-
The Stallman printer story is canon. But I don’t think that makes it real. Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add.
Counterpoint: For a developer or company with little money, which has been the case for the better part of my career (notably excluding my few years at Microsoft), if they want a feature, fix, or integration for an open-source dependency, they can make it happen given enough time, effort, and skill, but with a closed-source dependency, they’re stuck, unless perhaps they’re good at reverse engineering. That’s a big reason why I prefer open source for libraries, unless there just isn’t a good open-source solution for the problem at hand (e.g. speech synthesis or optical character recognition). Maybe I’m better than most at diving into an unfamiliar codebase and bending it to my will. I find it entirely plausible that Stallman was, or would have been, good at that too.
-
Arguably, the possible spaces of software and the way it was interacted with and written were smaller, so Stallman probably would have been good at it. He was a systems programmer, in a systems programming environment, who wanted to hack on a systems progam/driver/firmware.
That doesn’t necessarily mean that most or even all developers can or should be able to say, step out of systems programming and instantly know how to fix a React bug that is plaguing them. Software is more diverse and more specific, and programming systems are more layered and orientated towards the problem, and out of that comes subfields that are non-transferrable even if some of the basic concepts are.
-
I think the problem Stallman faced was that it was illegal to fix the driver. You technically don’t have to have knowledge to fix a React problem, it’s enough you can find someone who can and is allowed to (for payment, if need be).
FLOSS development doesn’t have to be a net drain on money. The FSF’s standard answer is “support and training”, and that’s fine as far as it goes, but it’s really hard to realize in an age where a project without good docs seldom gets traction and many developers choose burnout handling issues rather than asking for money.
-
-
-
As for what people despise, I wouldn’t take that as any indication. … The Stallman printer story is canon. But I don’t think that makes it real. Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add.
I think that, for folks who agree with these points, this makes sense and contextualizes the rest of the post. But not everybody will agree with this. Personally, I have written a Free Software driver in anger, regretting my hardware purchase and petitioning the vendor for documentation. It was a choice made not just from ability, but from desperation.
For good, closed software done right, the end user experience is actually better.
And for bad closed software done wrong? It can destroy hardware and hide malware, just to pick on one particularly rude vendor. Note that I would not be able to publish this sort of code in the Free Software ecosystem and convince people to use it, because folks would complain that the software doesn’t provide any functionality to the users. And this is a foundational weakness of proprietary software vendors: they are incentivized to make harmful software experiences due to privileged legal status. (Or, to be blunt: if I published this sort of malware, I would be arrested and jailed for crimes.)
-
Haven’t done any real systems hacking in a long while. I did when I was young, and had more time. I definitely had to do some driver and firmware work, to get Linux working with various things. I’m not sure if I was angry going into those projects, but I remember being pretty frustrated coming out of them!
A lot of that came about from buying cheap hardware. I remember one Acer laptop in particular, the one I chose for college: great specs, great price, terrible build quality, total bodge-job, component- and firmware-wise. I eventually bought the MacBook, and came back to Linux on ThinkPads. I pay a premium for ThinkPads, but I get what I pay for, Linux hardware support very much included. It makes way more sense than spending hours brushing up and hacking patches.
As for bad proprietary software: oh yeah, it’s out there. But the idea that software vendors have some inherently privileged legal position doesn’t fly. They have copyright, and can require customers to buy licenses. But the terms of those licenses can and do vary. I have advised on several software license deals, for substantial money, on terms that basically boiled down to Apache 2.0 plus a payment clause, limited to just the paying customer.
If all you’re doing is buying licenses on take-it-or-leave-it terms, or negotiating with highly aggressive companies much bigger than yours, yeah, you’re likely to see terms that strongly favor the vendor. That’s how leverage works. But proprietary software sales get done on sane, fair terms all the time. Perpetual licenses. Modification rights. Meaningful warranties. Accountable maintenance commitments. Sometimes the less impressive product wins out, because the terms offered for it are better.
-
-
Most people, especially these days, don’t want to dive into an unfamiliar system for a feature add
I think that is observably untrue, given the massive number of extensions available for all of the popular editors, for platforms such as GitHub, or even MS Office. The key point to remember is that being able to modify the behaviour of a program does not necessarily depend on its source being available. Somewhat counter-intuitively, it’s often easier in proprietary programs because they’re forced to maintain (and document) stable interfaces for third-party extensions, whereas open source projects can often just tell people to go and hack on the source directly. Specifically on editors, Vim, Emacs, and VS Code all have extension ecosystems that are significantly larger than the core product, which exist because people who were missing a feature decided to dive into an unfamiliar ecosystem and add it. VS Code and Emacs both did well by making that system less unfamiliar to their early userbase by building it on top of a language (Lisp, TypeScript) that this audience used.
-
-
considering that both vim and emacs have exploded in popularity in the last decade by taking in lots of those TextMate users :) And TextMate 2 is GPL, haha.
Some programmers use proprietary software, sure. Outside of game dev though they more often than not absolutely despise it.
Get out of your bubble. Outside that bubble a lot of developers use JetBrains IDEs or Visual Studio. Visual Studio Code has gained a lot of traction in recent years, but initially mostly because Code was much better for web development than the competition and it is free. Not because it is open source [1].
In the most recent Stack Overflow developer survey, Visual Studio Code is used by 71.07% of developers, Visual Studio by 32.92%, IntelliJ by 29.69%. The most popular fully (?) open source editor is actually Notepad++ with 29,09%. And vim takes the next place at 24,82%, but I wouldn’t be surprised that is because people use vim when doing quick edits remote Linux machines. Emacs dangles somewhere at the bottom of the list with only 5,25%, surpassed by many proprietary applications like Xcode, PyCharm, or Sublime Text.
The number one practical problem with using closed proprietary software is that you’re literally going back to basically where Stallman started – with that printer driver that he couldn’t just fix because it was closed.
I agree that this is a major downside of closed source software. But most people want to fix the things they are working on, not their tools.
[1] https://underjord.io/the-best-parts-of-visual-studio-code-are-proprietary.html
-
proprietary applications like […] PyCharm
PyCharm/IntelliJ IDEA are Apache2 and most devs use the free software version available at https://github.com/JetBrains/intellij-community
-
PyCharm/IntelliJ IDEA are Apache2 and most devs use the free software version
I have no reason to doubt this, but are you aware of any usage statistics? I’m curious whether “most devs” is more like “just over half” or “over 99%.”
Anecdotally, every company I’ve worked at where the devs used JetBrains IDEs has paid for the commercial version, but totally willing to believe those companies aren’t typical.
-
From my anecdotal experience, no company has paid for the commercial JetBrains version, even when most of the devs use it. It might very well be a cultural thing.
-
At the two companies where I used it, we paid for the whole toolbox subscription for every developer who wanted it. Most of us used IDEA Ultimate and one or more of CLion, AppCode or PyCharm Professional. Many of us also used DataGrip.
I still maintain a subscription for my consulting work now, too.
-
-
-
-
-
I don’t really disagree with you, but your arguments seem kind of weak.
Get out of your bubble.
In the most recent Stack Overflow developer survey […]
What now? It’s just another bubble.
[1] https://underjord.io/the-best-parts-of-visual-studio-code-are-proprietary.html
I haven’t ever used any of those “best parts” and never seen anyone using them.
-
I haven’t ever used any of those “best parts” and never seen anyone using them.
I’ve used the remote stuff. That and PlatformIO are the only things that ever cause me to use VS Code over emacs or one of the JetBrains tools.
The extension marketplace is proprietary too, and I’d call it one of the best parts of VS Code.
-
-
-
Some programmers use proprietary software, sure. Outside of game dev though they more often than not absolutely despise it.
I mean, there’s Vivado, and then there’s Visual Studio, just like there’s, I dunno, a steaming, rotten pile of horse shit and then there’s pancakes.
There are many bubbles in the tech world and game dev is only one of them. I worked in an embedded shop where the state of Linux was that we had one colleague who tried Fedora and he thought it was like a beta or something because he couldn’t put things on the desktop and, in his own words, he expected some things not to work as well as Windows but that was years away from being useful. The thought of writing code in a text editor after finishing college, where they put you through the ritual of compiling stuff you wrote in vim by writing gcc incantations, seemed about as foreign to these guys as the idea of sailing to America on a steam ship.
There are plenty of bubbles where programmers use both kinds of tools, too. Way back when I was doing number crunching, everyone at the lab was using emacs, vim, nedit or notepad, but also Matlab, which everyone hated for various reasons but nowhere near as much as they hated, say, gdb. We worked a lot with another research group at another university where it was the other way around: someone had figured Octave was good enough and they had just one Matlab installation for things Octave really couldn’t do or to port their code, and used the money they saved on Matlab licenses to buy a bunch of Windows and Visual Studio licenses.
I don’t have much in the way of numbers here but you shouldn’t take a tweet about Vivado as the standard about what people think about closed source tools. Vivado is successful because it barely works and there are no alternatives that work (for any non-hobbyist definition of “works”) – it’s successful largely by vendor lockdown.
-
-
Well, what can I say, not every case of acute horse diarrhea deserves to be famous :-D.
But seriously, this is one of the things I love about our work. Vivado is huge. I suspect it’s already old enough that virtually everyone who finishes an EE or CompEng degree has seen it at least once (it’s about ten years old, I think, and it replaces another suite called ISE which was also all sorts of horrible in its own way). It’s very likely that it’s been involved in one way or another in dozens of stories that popped up here on lobste.rs, like stories about RISC-V or cryptography or FPGA implementations of classical systems. And it’s perfectly possible for someone to be an excellent programmer and earn a living writing code and never hear about it. No matter how good you are at anything computer related, there’s always something out there big enough that it’s got tens of thousands of people behind it that you had no idea about.
If you keep an open mind, computer engineering will surprise you in all sorts of fresh ways, all the time – not all of them good but oh well. Dogmatism is fun and it feels like you’re right all the time but it’s really fscking boring. I’ve done it and it sucks.
-
-
By reputation, another reason Vivado is successful is because all the other FPGA toolchains are reportedly even worse. Don’t get me wrong, Vivado is a tyre fire that segfaults, but the others are apparently even less reliable.
e.g. I’ve heard that at some shops, people writing FPGA code targeting competing FPGAs will actually write and debug their entire project on Xilinx FPGAs with Vivado and then port the code to the other toolchain for the originally intended target FPGA.
-
I’ve done too little real work on Altera’s stuff to have had first-hand experience but from the little I’ve done I can certainly say Quartus sucked at least as much as Vivado back when I last touched it (2015-ish?). Maybe it’s changed in the meantime but somehow I doubt it :-D. I heard Lattice’s stuff is tolerable but I never tried it. I did try Microsemi’s Libero thing though and it makes Vivado feel like Visual frickin’ Studio. Porting designs between toolchains is not quite like porting program code and it sounds like a really bad idea on paper but, indeed, given how bad some of these tools are, I can imagine it’s just the only way to do things productively sometimes.
But it’s really a lot more complicated than how good the toolchain is. A big – probably the biggest – reason why Vivado and Quartus are so successful is simply that Xilinx and Altera… well, Intel, are really successful. The next version of Vivado could suck ten times as bad as the current one and it would barely put a dent in their market share, just because it’s what you use to do things with Xilinx’ devices. Developer souls are a lot more fungible than silicon.
Also, being so big, they both have roots in the academic world and they run deep, and it’s simply what lots and lots of people learn in school. They’re not very good but as long as the bitstream flows out, who you gonna call?
A competitor with better development tools could, in theory, steal a chunk of this market, but that chunk would be exactly as big as how many programmable logic devices they can sell, and there are constraints – both technical (as in, performance) and non-technical – that dictate that long before anyone even considers the quality of development tools. The usual retort is that developer tools are important for productivity. And they are, but the best designs, from the most productive teams, won’t be worth crap if there are no physical devices for them, or if these devices cannot be obtained on time and in the required quantity and at the right price and so on.
I also secretely suspect that it’s just a case of the audience of these tools being a little more tolerant to weirdness and poor quality. I mean, they taught me how a transistor works in my second year of uni. I then spent the other half of my undergrad years (and I could’ve spent a whole two years of masters’ on that, too) learning about all the ways in which it doesn’t quite work exactly like that. Software segfaulting under your nose is just a tiny drop of weird shit in a very big bucket of weird shit which people way smarter than you reverse-engineered out of nature. Your entire job revolves around manipulating all sorts of weird but inevitable things. So you just learn to chalk up the fact that Vivado crashes if you have more than 64 mux instances whose names start with the letter X under “inevitable” [1], somewhere between “all P-N junctions have leakage current” and “gate capacitance varies with gate oxide thickness”. What’s one more?
[1] Note that this is something I just made up on the spot but it does sound like something Vivado would do…
-
A competitor with better development tools could, in theory, steal a chunk of this market, but that chunk would be exactly as big as how many programmable logic devices they can sell
You don’t exactly need to sell programmable logic devices to steal a chunk of FPGA development tool market. Symbiflow has already done that with Lattice’s FPGAs, and are slowly starting to bite into Xilinx FPGAs as well. Quicklogic just released their new FPGA product without their own software, just by giving Symbiflow their bitstream generator and FPGA definitions. There are signs that the new Renesas FPGAs are using Yosys (part of Symbiflow) too.
The reason why these closed software tools are so entrenched is that they are tied in with hardware. And as of now, open source hardware is a lot more niche thing, than open source software. With time, that will probably change, but even then, the software landscape in places dealing with hardware will progress faster. Just remember, how a while ago working on microcontrollers almost always meant dealing with vendor-specific IDEs. That is basically gone now. With time, that will happen with most FPGAs as well.
-
I haven’t tried Symbiflow since 2020 and it’s a project I’m really cheering for, so I’m not going to say anything bad or unenthusiastic about it. But it’s worth keeping in mind that the iCE40 line (the only one that it supports well enough to be usable for real life-ish projects) has a very straightforward, wrinkle-free architecture that lends itself easily to reverse-engineering. Even though the underlying technology is physically the same, as in, it’s based on the same technology (FPGA), the market Symbiflow can realistically target is practically different from the one where people are using Vivado and complaining about it. Its relative success in this field is important and useful, not to mention liberating to a lot of people (including yours truly) but I wouldn’t be too quick to generalize it.
This approach will probably find some success at the low-power, low-cost end of the spectrum, where not only are customers rather unwilling to pay the licensing costs, but some companies, especially fabless vendors like Quicklogic, would be reasonably happy to be rid of software development cost. But this part of the FPGA market works in entirely different ways than the part of the FPGA market that’s bringing the big bucks for Xilinx (and Altera) and where the people who associate the word Vivado with an overwhelming feeling of dread work. For one, it’s not a field where architecture and fabrication technology are important competitive advantages, so there’s not that much value in keeping it closed and keeping the software tied to it.
-
-
-
-
-
-
You’re right that systems programmers and hardware devs prefer small and lean tools, which are often released as open source, but walk into any corporate dev house and you’ll see a lot of Visual Studio and IntelliJ with Xcode and other IDEs sparkled in. The sole exception to this are web devs, whose first usable tool was VScode.
If you have the skills and time to hack on your tools, open source is better, but for most people it’s just a better proposition to pay someone else for their tools and use the saved time to do their job and make that money.
-
Actually most devs use proprietary software, and kemitchell even mentions this in the post. He switched to Mac, but Windows is still the most popular platform even amongst devs[1]. I suspect the Stack Overflow survey results are even skewed and that Linux likely has less market share than they found.
https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-operating-system
-
I hope I made the point that devs do use proprietary software. It’s not true that devs just won’t use closed code. But I don’t have data to support the claim that most devs do. I suppose you could get there by arguing Windows and OS X are closed, and the number of folks on Linux is small. I’ve enjoyed looking at the Stack Overflow survey, but I have no idea how representative that is.
For what it’s worth, when it comes to laptops and desktops, I’m back on Linux again. I did switch to Mac when I was younger. And I did my programming career that way, before going to law school.
-
-
But how much of that is because companies require Windows? When I was hired at my current company, half the employees used Macs (mostly developers) and the other half Windows. We then got bought out by an “enterprise” company, and they use Windows exclusively. They even sent me a Windows laptop to use, even though I use a Mac. The Windows laptop sits unpowered and unused, only to be turned on when I’m reminded that I have to update the damn thing.
-
-
-
Kyle Mitchell has put together this “license as a service” thing where you answer a number of multiple-choice questions and it spits out a software license you can use when selling, rather than having to engage a lawyer to draft up a set of terms. (Fixed fee to Fast Path per sale.) Also, Kyle is a big proponent of plain-English contracts, so it’s pretty pleasant to read.
Pretty interesting concept here, even though I’m not on the sales side of the software business.
-
so it’s pretty pleasant to read.
I’m sure there’s room for improvement, but reading this made my morning.
Thank you!
-
-
I am not a lawyer but there’s no way I’d touch this license. First, it’s an EULA, it doesn’t give me any rights to modify the software, so I’m stuck with the provider as a single supplier, making it a try-before-you-buy proprietary license, not anything like a F/OSS license. Even if the terms are FRAND, this just means that they have to screw all of their customers equally. The rest of the license has a bunch of things that make me super nervous:
You may use the software for any noncommercial purpose.
Okay, what does that mean? If it’s a CMS, for example, can I host my blog on it? What if my blog receives ad revenue? Does that change if the ad revenue is less than the cost of hosting versus if it’s sufficient that I can quit my job? If it’s an image editing program and I create a picture with it for fun, but then a year later sell the copyright of the image for $1m, am I retroactively violating the license? Note that all of the revenue-related things are answered if I’m a small company, but not if I’m an individual. This is really fun if I produce something for free, give it to someone else, and they then sell it for a load of money - was my use now retroactively commercial?
Previous advice I’ve received from lawyers is to avoid anything that permits noncommercial use without explicitly defining it because there are so many corner cases like this that you may discover that you’re a commercial use or, worse, a particular use may retroactively become commercial.
Use by any charitable organization, educational institution, public research organization, public safety or health organization, environmental protection organization, or government institution counts as use for noncommercial purposes, regardless of the source of funding or obligations resulting from the funding.
A charitable organisation is defined by law in most jurisdictions but this doesn’t mention anything about jurisdiction. There are reciprocal treaties between a lot of countries for the purpose of donation (for example, a German company gets a tax deduction when donating to a UK registered charity can claim a deduction if the charity meets the requirements of a German charity). In some jurisdictions this explicitly includes or excludes religious organisations. If my jurisdiction regards my organisation as a charity and the licenser’s jurisdiction does not, who wins?
Educational institution is similarly poorly defined. I think we’d all agree that schools and universities probably qualify. Does PluraSight? Or LinkedIn (which includes LinkedIn Learning) and, by extension, Microsoft? Does Pearson Education (it’s right in the name!)? If my company does in-house training, is it an educational institution? If I run an online store that sell clue-bats embossed with the phrase ‘the world contains many legal jurisdictions’ for hitting lawyers with, am I an educational institution?
Similarly, does ‘public research organization’ include anything that self-identifies as such? Including think tanks that exist solely to lobby for specific policies?
had fewer than 20 total individuals working as employees and independent contractors at all times during the last tax year
A company with 13 full-time employees can be pushed over this limit if they hire half a dozen contractors for an afternoon to staff a booth at a marketing event. I believe this clause excludes agency employees, so you’d be fine if you hire these folks via an agency (this adds to your compliance costs) but if that’s the case then you can defer triggering this rule by hiring as many full-time staff via an agency as possible.
earned less than 1,000,000 USD (2019) total revenue in the last tax year
This is probably fine for anyone in the USA (though note that it implicitly biases the license towards high-margin businesses). Not so much in the rest of the world. In the time that I’ve been paying attention, the USD:GBP exchange rate has gone over 0.8:1 and below 0.45:1. It can fluctuate by over 20% in a year. Any non-US company making over half a million USD needs to worry about this because fluctuations in exchange rate could invalidate the license. Oh, and the exchange rate to use isn’t defined. HMRC, for example, publishes exchange rates to use for tax purposes (monthly and annual averages) against GBP. I presume the IRS publishes something similar, which could have been explicitly referenced here.
indefinitely, if the licensor or their legal successor does not offer fair, reasonable, and nondiscriminatory terms for a commercial license for the software within 32 days of written request and negotiate in good faith to conclude a deal
Note that the clock doesn’t stop ticking during the negotiation. So first you have to notice that you’ve crossed the threshold. Easy if it’s hiring the 21st employee, a bit harder if it it’s the end of the tax year accounting for final revenue (it’s fairly common for that to take a month or more after the end of the tax year to get accountants to sign off on the end-of-year accounts and know if you’ve just crossed the threshold). By the time you know that you need to sign the letter, you’ve probably used a quarter of that time. The licenser can then make a FRAND offer in 32 days. You now have 64 days to complete contract negotiation and signing. Good luck with that if this is anything other than an off-the-shelf license agreement with a previously published price that your legal team agreed to before you started the process. If you’re not happy with the FRAND terms then the supplier just has to run out the 64-day clock before you’re in violation.
-
-
Okay, now prove that in a court of law.
-
That’s not how law works. Having a disagreement doesn’t automatically teleport you before a judge—they would really hate that. It doesn’t even land you on a call with a lawyer the overwhelming majority of the time.
Negotiation in good faith is a magic phrase, or “term of art”, in law. The search term is “implied covenant of good faith and fair dealing”—the idea that by default, the law requires a baseline of responsibility and straight shooting from all sides to a deal. Honor the thrust of the deal.
Big Time’s language merely makes that implied rule explicit. It also makes clear it extends to negotiation of the new terms, not just doing what’s agreed under Big Time itself. That gives folks who don’t know the legal defaults comfort that Big Time licensors can’t simply send a qualifying offers and sit on them, effectively ghosting would-be customers. If that happens, the company’s choice is to drop the software or keep using it, in reliance on the Big Time terms. If the licensor comes back and threatens to sue, the user can cite the language back at them. Negotiate. Which is the point.
-
This is the flow that I imagine:
- A negotiation requires multiple rounds of review by both sides lawyers (from personal experience, this happens when a company buys anything)
- Time zone differences mean that any query takes at least 1-2 days for a full round trip.
- The lawyers on the provider side keep raising entirely reasonable (or reasonable seeming) issues with any proposed changes that the buyer requests.
- You run out the clock and the providing company says ‘we’ve been negotiating in good faith, you are now out of time and must either agree to the terms or be violating the license’.
Now what happens? If I keep using the software, my compliance team will be very unhappy: I don’t have a license. If FACT does an audit, I am not in compliance. If the supplier decides to take me to court for using the software without a license, then I have to prove that I do have a valid license under the terms of of the Big Time Public License, which requires demonstrating that they were not acting in good faith.
From a corporate perspective, this looks like a big tangle of compliance risks and something that I wouldn’t even bother trying to get my compliance team to look at because they’d run screaming away from it.
In some ways it’s easier if I’m a big company to start with because I’m definitely not covered by the Bit Time license and so need to apply for the FRAND license anyway, so there’s no risk from a license that I don’t use. If I’m a startup with acquisition by a big company as a possible exit strategy then this is the kind of thing that would show up when a potential buyer did due diligence as a big risk and make my sale price lower. If I’m an individual, I can’t afford to hire a lawyer to tell me if I’m a commercial entity or not and so I just avoid it.
-
-
-
-
Big Time’s noncommercial language, which descends directly from PolyForm Noncommercial, is the clearest I’ve seen in a public license. The idea that legal terms like this ought to be perfectly clear in every case is a myth. That’s not how natural language—or legal terms—work in practice.
The “safe harbors” for personal uses and noncommercial organizations address the vast majority of truly difficult edge cases we actually hear about with Creative Commons NC. CC’s own studies on understanding of its language indicate very little utility from their extra language. So Big Time doesn’t include any.
If a use case is arguably commercial, and the user doesn’t qualify as a small business, they should reach out for a paid license. That’s the other half of the point with Big Time. Using this license won’t make sense unless the licensor does (or did) offer paid licenses.
As for modification, if you’re covered for “use”, you’re covered under copyright. see the Copyright License section.
The headcount limit for small business was lowered from 100 to 20 in version 2.0.0. It’s only approximate, and it only needs to be, functioning as one of three rough proxies for bigness. If you have thirteen full-time employees and are hiring on contractors by the handful, you probably have what with to get a license. Nothing stops you from reaching out for terms before you’re clearly no longer “small”. There is a special transition time frame for companies that start out small and grow out of those limits.
We have active discussion ongoing, including on GitHub, on adjustment of the small-business thresholds for economy size, internationally. Perhaps we might add an adjustment for purchasing power parity, atop of inflation. But it’s not altogether clear yet whether that’s what developers would want.
The most important thing we’re hearing is that devs definitely want to sell to big, well known firms and kinds of firms that ought to be paying, like banks and startups who’ve raised millions. Not that they want to draw a particularly fine line between different degrees of small. All of our “small business” thresholds clearly put the big firms of concern out-of-bounds for free small-business use.
-
-
Could that language to make sense without referring to the tax year where the company pays tax?
Привет из Калифорнии! Счастья и успеха в новом, 2022-м году!
-
This is part of a recurring problem with the license: it does not mention jurisdiction and makes a load of US-centric assumptions. This phrase would be better if it included an explicit note that it happened within the tax year of the organisation receiving the license. Without that, there are problems if I am under $1m over my tax year but it isn’t evenly distributed and so in the seller’s tax year I am over. Am I violating the license?
All of that said, to your question:
Could that language to make sense without referring to the tax year where the company pays tax?
Absolutely yes. Because for most companies the thing that matters is the accounting year (which may be different for each company) and not the tax year (which is defined by statute in each jurisdiction). That defines a point in time each year at which all accounts must be reconciled and, for publicly traded companies, the point at which they must report earnings.
-
Even companies that define their own accounting year have to prepare accounts for the tax year, in order to pay their tax. This isn’t a US-specific phenomenon. Companies pay tax everywhere. Do you know of a country that requires tax reporting for other than a defined, year-long period?
The point of using tax year in the terms was to use the measure companies will already have. Plenty of companies only do accounting on the tax year. Those that also do other accounts still have to do tax accounting. I believe that’s true even if the self-defined tax year dominates conversations about external reporting or internal compensation and budgeting.
I certainly don’t think I agree that this language could refer to the seller’s tax year:
You may use the software for the benefit of your company if it meets all these criteria: … 2. earned less than $1,000,000 total revenue in the last tax year
-
-
-
-
-
That’s kind of a cool idea for a license.
There are two things that immediately spring to mind for improvements:
-
They should mention that this is not a FOSS license. That’s obviously an intentional feature by the authors, for reasons they consider good. It should be called out in big, bold letters that this is not Free Software. (@kemitchell I think this warrants an update to the post)
-
When they’re saying who can use it as if it were a FOSS license, they don’t define/explain the “USD (2019)” notation. I think (with high confidence that I’m correct) they mean a figure that’s equivalent to US dollars adjusted to their 2019 value in terms of inflation, but since this is load bearing in terms of who they feel can use their software without paying, it bears explanation.
For my own stuff that I release in a spirit similar to this, I think I still plan to just use the AGPL. But this is really a cool idea and I’m glad people are exploring it.
-
Thanks very much for these comments!
“USD (2019)” is standard notation…for folks who deal with foreign exchange and inflation all the time. We should have anticipated that other kinds of careful, earnest readers might stumble on it. You guessed the meaning. But we shouldn’t make you guess.
PR with revisions: https://github.com/berneout/big-time-public-license/pull/21
I also hear you on FOSS. But I want to stay focused on expressing as clearly and succinctly as possible what this license is, rather than listing out all the things it isn’t. I definitely don’t want to burn any more cycles on the sacrificial altar of free/open definitional politics, or whose reading of whose definition rules or ought to rule. It’s a trap. We’ll never get that time back.
I also want to gently push back on the idea that FOSS is the norm and anything arguably not-FOSS should bear some kind of label, like a poisonous household chemical or a sharp power tool. A big contributor to the scale of the open software funding crisis is the extent to which we’ve infantilized devs and insulated them from business. Commercial licensing isn’t unclean. It isn’t even exceptional, unless you’re at least one manager removed from the source of your opportunity. Keeping especially young devs’ information diets scrubbed of alternatives between MIT-free and “work for FANG” produces a lot of devs who don’t thing they have options in between.
Devs are starting to take hints from other corners of the “creator economy”, because they’re exposed to it online, as consumers. They shouldn’t feel like they have to look outside software for that kind of model or guidance, because they don’t see those discussions happening within it, or strong implicit or explicit signs it isn’t welcome.
-
So I won’t argue with you stridently, because I very much appreciate your point. But… in general if I’m not negotiating a license with someone and I have been told I can use their work, I expect it to be either FOSS or “type my credit card # into a form and go.”
I feel like a license that occupies a space between these positions needs to highlight that fact. If it doesn’t call that out and it doesn’t require me to enter payment info, it feels like FOSS in a deceptive way.
This is very friendly criticism, and I think you are reading it that way, but I want to call that out for others. I think what you’re doing is good.
-
I’m glad you read my comment as I meant it. Have no fear about how I’m reading yours! And again: Thank you for time and thought. It’s nice to have a good conversation with a pseudonymous Internet presence. That was more common in “the good old days”.
I see there’s a kind of friction here. And I must admit that’s intentional on my part. Or rather, it’s a foreseeable consequence of what I intend. The warning label you mentioned could address the consequence, but at the expense of my true end.
I can see how your expectations could come about, based on what’s been normal for the last ten years or so, in our field. But I think that normal’s hurting us, pretty plainly, personally and collectively. So I’m trying to change the norm, to normalize what isn’t yet expected. And there’s the chafe.
-
But I think that normal’s hurting us, pretty plainly, personally and collectively. So I’m trying to change the norm, to normalize what isn’t yet expected.
If you have the time and energy to write it out with a clear path from current licensing practices/expectations to what you think would be a beneficial new normal, I believe that would be a very interesting blog post. I’d read it, anyway.
-
-
-
-
-
Hopefully not hijacking the thread, but is there a dual licensing like: MIT / MIT but pay me 1k per year?
-
I recently published a blog post very close to your question: https://writing.kemitchell.com/2022/01/21/MIT-for-Noncommercial.html
-
-
-
Do people actually try to do this, with these exact intentions, really?
I would expect this to mean something like “license is MIT, but companies please apply for custom license to get support and stuff”.
-
Are you asking if people actually try to publish software that is allowed to be used for non-commercial purposes only, or if people try to do that using a dual-license with one of the licenses being the MIT license?
I am positive the answer to both questions is yes, but I do not have any clear examples handy.
-
-
If you’d managed to read even the first paragraph of my post, you’d see it responds to one from the Stack Overflow blog. I even quote the passage where they mention MIT for noncommercial, verbatim.
I don’t mention Big Time in this post. I do mention two actual noncommercial software licenses I’ve contributed to. Because they’re better, and will help devs tempted to jerry-rig MIT to avoid needless hassles.
-
I’ve read it. Both your post and the one you refer to put up a strawman (people use MIT license for non-commercial). This is not a reality with any projects with even slightly traction.
What I am trying to say is: this post is intellectually dishonest by putting a very niche if not non-existent misread of license (MIT license obviously is permissive and cannot be arbitrarily restricted) into focal point, then attacking it, trying to establish an alternative reality where “non-commercial” open-source is an widely acceptable open-source practice.
-
He’s very clearly addressing one specific way of using the MIT license and saying that it doesn’t legally work. He’s also directly responding to someone mentioning the usage he’s addressing.
He’s not using that niche usage as a strawman to attack the general MIT license anywhere in the post. What line are you reading that turns this into a strawman attack on the general license?
It’s a little concerning that you also clearly didn’t read the article and initially accused him of just wanting to promote his own license (which isn’t even mentioned in the article) before pivoting to calling this a strawman attack on the MIT License.
If you have a bone to pick with someone please don’t bring that into the comments section of Lobsters. The guy wrote an article: come discuss the merits of that article if you want.
-
Just realized that I replied too quick on my mobile device and left too much for interpretations. Sorry about that.
I am not saying the post attacks MIT license in general.
I interpret this post for a particular MIT license usage as this:
Someone licensed their code under a modified MIT license (modified as: MIT license for non-commercial use cases), and a commercial license (supposedly with some guarantees).
My comment, and my parent comment (by @unrelentingtech) call out that this situation doesn’t exist, or at least very niche so nobody really see it anywhere.
Note that this is in contrast with a different interpretation of MIT / commercial dual-license: someone licensed their code under MIT license and also provides a commercial license if you want to pay for it, in hope to get some guarantees (as MIT license provides the software as is). There are some examples for this case, most notably MySQL (but with GPL). There are also community edition / enterprise edition software licensed similarly.
The comment you replied to can come off as offensive when re-read it. The point that I am trying to drive home is: by attacking a non-exist use case (modified MIT license + commercial license), author’s self-interest served, which (again, this is an extrapolation) is to lend legitimacy to non-open-source licenses as a reasonable alternative to open-source ones.
-
-
Indeed, it is all a big conspiracy to give devs free legal help with their licensing terms.
-
-
Thanks for your note! Glad to be of help.
-
-
-
-
-
-
-
kemitchell
1 year ago
|
link
| on:
How Effective Is Copyleft with Commercial Licensing at Making Money?
Companies pay for software all the time. You may be reading too many headlines from one corner of the industry.
Dual licensing (AKA selling exceptions) has worked and does work for many firms, large and small, both on its own and in combination with other models, like selling proprietary extensions or complementary software. I keep a very incomplete list of examples at duallicensing.com. There have been many more successful dual-licensing sales than lawsuits by dual-licensing companies against deadbeat users.
Merely sprinkling a business model on top of a project with a few website changes and social media posts almost never yields meaningful money. Not with dual licensing, not with open core, not with services or any other model. You need a model and you need to push. Going into business is adding a whole ’nother project to your life.
Driving paid-license sales will take time and energy. That is time and energy you will not also be able to spend on your software. On the upside, paid-license sales can take substantially less time and energy than developing complementary products, hosting, developing closed, one-off software on contract, or providing high-touch professional services like training. Your project is your project and there won’t be any business need to segment it into free and paid chunks, since what you’re selling is fundamentally permissions, not bits.
-
Dual licensing (AKA selling exceptions) has worked and does work for many firms, large and small, both on its own and in combination with other models, like selling proprietary extensions or complementary software. I keep a very incomplete list of examples at duallicensing.com.
I don’t know how many of your examples are actually small people, but I do know of one: VideoLAN. And the link I had in my original post was the VideoLAN guy talking about how it really hasn’t worked out very well. So while you have examples (and thank you for them; I’m going through them now), I’m a little nervous about how effectively those examples actually make money.
There have been many more successful dual-licensing sales than lawsuits by dual-licensing companies against deadbeat users.
I’ll have to take your lawyer’s word for that, but I do wonder if that’s just because the threat is enough from bigger entities. If I, as an individual, am not enough of a threat, would they care enough to pay as required? I don’t really know.
Merely sprinkling a business model on top of a project with a few website changes and social media posts almost never yields meaningful money. Not with dual licensing, not with open core, not with services or any other model. You need a model and you need to push. Going into business is adding a whole ’nother project to your life.
Agreed. My current business model plan is two-fold: licensing and on-call support. I just don’t think people will pay for that if they can get away with not paying.
Driving paid-license sales will take time and energy. That is time and energy you will not also be able to spend on your software. On the upside, paid-license sales can take substantially less time and energy than developing complementary products, hosting, developing closed, one-off software on contract, or providing high-touch professional services like training.
I do understand that driving sales takes time and energy. Unfortunately, that’s just what I’m going to have to do to make money. I’d rather spend half my time on that than all of my time on someone else’s software.
Your project is your project and there won’t be any business need to segment it into free and paid chunks, since what you’re selling is fundamentally permissions, not bits.
Are you saying I should keep it closed source? I’m not entirely sure what you are saying here.
-
If you think your potential customers are a bunch of big companies and you’re afraid of big companies, I’d suggest you reach out to some founders at companies that successfully license big companies. Or find another line of business.
If you’re looking for validation of the idea that dual licensing doesn’t work because large companies are all big meanies who don’t play fair, I can’t corroborate. I’m sure it happens. And probably more often where the developer obviously lacks spine and cowers. But the dual licensing failure cases I see have a lot more to do with more basic business faults.
-
If you think your potential customers are a bunch of big companies and you’re afraid of big companies, I’d suggest you reach out to some founders at companies that successfully license big companies. Or find another line of business.
That is a fair criticism. I’ll take the L, and I’ll see about doing as you said.
If you’re looking for validation of the idea that dual licensing doesn’t work because large companies are all big meanies who don’t play fair, I can’t corroborate. I’m sure it happens.
My wife, the one with business sense, thinks it won’t work because of this, so it’s not just me. In fact, I was pretty idealistic about it until a month ago. She tried to get me to see sense for years, and I’ve only recently come around.
And probably more often where the developer obviously lacks spine and cowers.
If I had the resources to go after companies in the case that they violated my license, I would happily “grow a spine” and continue with my work. But I don’t have the resources because a lawyer like you doesn’t come cheap.
But the dual licensing failure cases I see have a lot more to do with more basic business faults.
I believe it. I’ve been taking potential business ideas to my wife for years, and having the business sense that she does, she has shot them all down. So I could see it being hard to find the right one.
In other words, I guess I have not found the right one. Good to know.
-
Wasn’t trying to talk you down. But you came in with a question based on a presupposition that contradicts my experience. For what it’s worth, I’m a deals lawyer, not a lawsuits lawyer.
I have seen founders and salespeople have to push on large company users who weren’t initially willing to deal. When the vendor is small, that is definitely an asymmetric conflict. If you find yourself on the smaller side of an asymmetric conflict, you can’t think just in terms of all the big-side resources you don’t have, like how many dollars or bodies or lawyers they have that you don’t. You have to work other leverage. Go talk to founders that have won some of those battles.
For what it’s worth, the VideoLAN comment you cited seemed to have a lot more to say about lack of interest in technical support contracts than dual licensing. That fits with my perception of their software’s primary use case and license choice, which don’t put a lot of users in positions where they need other license terms.
It’s hard to sell tech support for reliable, well documented software. It’s relatively easy to sell technical support to large companies with urgent problems.
-
-
-
-
-
kemitchell
1 year ago
|
link
| on:
Why you probably shouldn’t add a CLA to your open source project (2018)
I blogged a response to this piece: https://writing.kemitchell.com/2018/01/06/CLAs-Are-Not-a-Sham.html
-
-
I still remember the iconv commands for transcoding Russian texts by heart. I used to be really good at guessing encoding from garbled output, by sight.
There could be a whole nother blog post on Russian keyboard layouts,
-
I see kemitchell, I upvote. Is there anyone else hacking on OSS licensing? Your efforts are appreciated, Kyle.
Like others, I’m defaulting to xGPL these days.
-
I use appreciate their work, and the Blue Oak Model is a gem especially, as are much of their blogging, but very little is the licenses here are OSS, rather most are explicit attempts at business proprietary licensing, but in a generic way borrowed from OSS.
-
Most of the lawyers here are also up to good hijinks: https://writing.kemitchell.com/lists/Blogroll.html
None of the stuff mentioned in the blog post is my work alone!
-
I wouldn’t count this as “hacking on” but I’ve become a fan of the UPL since I found out about it: https://lobste.rs/s/u0illx/universal_permissive_license
-
-
That… sounds very stupid? Why would you purposefully prohibit yourself from using any GPL code? You choose to be unable to dynamically link against GPL libraries, and to be unable to statically link against LGPL libraries, and for what? To make some imagined other people a bit less happy?
-
-
-
Nice domain name.