ThenAsNow
Joined 10 years ago
Joined 10 years ago
That said, it's a fair criticism that procurement specs are often poorly written, and the evaluation processes insufficiently rigorous.
Obviously, needless dicklike comments can only help the project and its users.
The EDRAM I'm familiar with, by a company called Ramtron and later Enhanced Memory Systems, seems to be largely lost to history. It's discussed in this relatively recent presentation, see slide 16 onward: https://site.ieee.org/pikespeak/files/2020/08/Silcon-Mountai...
The Wikipedia page you cited opens with "Source-available software is software released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified, but without necessarily meeting the criteria to be called open-source."
So by this definition, "source available" is a superset of FOSS, but not specific enough to imply what the user can and can't do with the source code. It makes sense to name classes of license within the "source available" umbrella that spell out what freedoms are restricted/preserved.
The Big Time license is not specific as to whether the covered software is provided in source or binary form, and is easily applied to source code distributions. Probably the reason I associated this license with "source available" is the primary license author is a prominent U.S. lawyer involved with open source and I'm pretty confident it is written to be applicable to source code even if it is not explicit about it. Similarly, the BSD license doesn't require that the license be attached to source code - one could release binary-only software under the BSD license.
There was understandably uproar about things like the "Commons Clause" and similar attempts to retrofit obligations to pay onto open source licenses. I have no disagreement with rejecting these as misrepresentations of open source. But if no such misrepresentation takes place, this line of objection is bogus. I gave an example of one license that does not misrepresent itself in such a way. I'm sure there are others and if not, attempts should perhaps be made to develop others, just as we have multiple open source licenses available.
>> Regardless, something needs to be done about the sustainability gap in open source other than writing messages like what's linked.
> That feels like the politician's fallacy. We need to do something, and switching to fauxpen source is something, but that doesn't mean we need to switch to fauxpen source.
I regret my phrasing, "something needs to be done," which does indeed sound like a politician. So let me rephrase. There is an axis, with proprietary secret source code and FOSS anchoring the ends. This axis is a good proxy for monetizability, but the axis itself is about freedom. With secret source, no user gets any benefit from the source. Source available, is, to me, a genuinely constructive attempt to address the need for developers to be compensated, while still giving users many of the benefits of access to the source.
I don't think source available is going to be something we "switch to" so much as, if some developers need income from the code they put out there, this is a far more user-centric option than telling everyone to download binaries for platforms they may or may not use and submit themselves to intrusive license checks. If you want to get a job at a RedHat or Collabora or try to have your employer cover your open source time instead, more power to you, source available certainly doesn't stand in the way of that.
> It's not just one project that can't. If a given bit of code isn't open source, then NO open source projects can incorporate it.
Open source projects have no hope of incorporating secret source software either. At least with source available, users can look at the code, make changes, build it themselves, and if they fit whatever "gratis" criteria are a part of the license, they don't have to pay either.
How do they do that if they don't call themselves open source (or "Open Source (TM)" if you prefer) in the first place?
Regardless, something needs to be done about the sustainability gap in open source other than writing messages like what's linked. The inability of your project to incorporate someone else's code shouldn't consign the rest of us to not have the benefits of access to that someone else's code outside of a proprietary binary.
It seems like source available type licenses (e.g., Kyle Mitchell's Big Time license: https://bigtimelicense.com/ ) are a reasonable middle ground for being paid software without giving up many of the benefits of open source.
I'm hoping there's a notable uptick in adoption of licenses like these.
You probably meant "hygroscopic" here. One probably doesn't want to be carrying hypergols in their car!
If one is taught ideal spring-damper theory, they are told friction in the damper is neglected in the mathematical model. If I use this theory to size the spring and hydraulic damper for some application where the forces involved vastly outweigh the damper seal friction, it's likely this non-ideality doesn't impact the answer enough to affect my sizing.
If I'm trying to eke out every last bit of performance from the spring-damper system and minimize damper lag, then the seal friction probably does matter.
Either way, when the theory was taught, it was done by stating what assumptions were used to derive the theory. How much those assumptions affect the validity of the model for a given purpose is an "it depends" matter.
Theory (at least in physical disciplines) is always taught with up-front statements of assumptions, what non-idealities are assumed away in order to tractably develop a theory in the first place. It's not taught by theory that theory transcends whatever simplifications were made to arrive at the the theory. Physical theoreticians do not contend that theory has no differences from reality.
However, in his role leading a project that ostensibly wanted people to use it, he had a very offputting set of personality characteristics that worked against that goal. He was very opinionated and often condescending, frequently stating opinion as fact and being shallowly dismissive. I'm not talking about arguing with people asking that he add shiny baubles, but just generally almost annoyed the person he was talking to didn't realize the obviousness of their own stupidity in not seeing it his way.
Then, he had a gigantic victim complex where any comment that could be perceived as negative whatsoever was seen by him as some grave personal slight deliberately intended to hurt him. It wasn't sufficient for him to explain why he thought others were wrong. It was frequently accompanied by accusations of bad faith, of potential coordination with others trying to take him down, etc. It came across as hysteria. Not to mention the needless aggression with the Calyx developers, etc.
A few years ago, the IRC channel had a lot of this victimization and desperation-type content from him. It got to a point I was uncomfortable using GrapheneOS out of concern for the leadership and prospects of support.
It used to be Theo de Raadt of OpenBSD and to some extent Linus were benchmarks for "prickly" open source leaders, but I think Daniel gave them all quite a run for the money.
It's good that despite all that, Daniel managed to find some developers he could get along with and the contributor base grew beyond him. Here's to hoping the new leadership team steadies the ship and manages not to be so hostile to the community.
Edit to add: looking over the [2] link from parent, it's clear he did provide a lot of thoughtful, helpful answers as well, so I wouldn't want to downplay the great deal of good for which he's responsible. We're significantly better off that something like GrapheneOS exists.
Signed, A fan of Robocop as dystopic corporatocracy preview
It's always going to be cheaper to make things in places where labor costs and environmental responsibility expectations are low.