Iirc the issue with SSPL was that releasing the entire stack under SSPL would basically be impossible, since you wouldn't have the rights to release, for example, the Linux kernel, under it.
Yes. I also read it somewhere that, for example, if you hosted your service on Microsoft IIS, SSPL required you to publish IIS source, regardless of the fact that you don't have it.
If the intent is to stop it being used for a business, that's inherently at odds with part of the OSI's definition: "The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research".
Now technically maybe it could meet the OSD if it required a royalty for hosting the software as a SaaS product, instead of banning that - since it allows "free redistribution", and passes on the same right to anyone receiving it (it is defined in terms of prohibitions on what the licence can restrict, and there is no restriction on charging a set amount for use unless that requires executing a separate licence agreement).
Now arguably this is a deficiency in the OSD. But I imagine if you tried to exploit that, they might just update the definition and/or decline to list your licence.
Watching what we charitably call this debate flare up yet again gives me an odd mix of feelings. On the one hand, seeing people I've read and listened to for years heave time, attention, and more typing onto this tire fire evokes deep tragedy. On the other hand, I've been there, casting my own vanities to the bonfire, more than a few times. There's comfort in the familiar heat and glow.
I couldn't escape the waste until I was willing to give up the idea of myself as experienced, as an expert. Until I accepted that time served taught me lessons, but didn't bestow authority. Most people coming into this are new. They relearn what's useful and leave the rest behind. That's part of adaptation. I try to see their point of view.
If you ask a newer coder what "open source" means, they might say "like MIT?" or even just "like GitHub?" If you look "open" up in a good thesaurus, "available" is there. The Initiative---really, whoever's on the board now or later---will never own or effectively police the term "open source", much less "open source AI". And nobody claiming "open source" for good or ill will ever summon on themself the kind of attention or cachet that marketing bauble once commanded, no matter what their license says.
As for fellow oldheads, there's no resolving contradictions between ways we learned to frame these issues, decades ago. Can changes to a license be a solution to the funding problem? Can using freedom terms to buttress a business count as truly open? That bizarre conflict of ontologies won't decide where programming goes in the future, if it ever did. I doubt it will even be won or lost. It will just fade away, like the circumstances that started it.
DHH can kick the anthill. The activists can raise their old hue and cry. It's purely elective, demoded dramatics. The real problems of software politics today aren't expressible in either schema. They can even seem tautologically unsolvable. Meanwhile, we've got new aspirational generalities that aren't expressible in the old ways of speaking. "Sustainability", because many doing good aren't doing so well. "Decentralization", because we're all sharecropping on some platform now.
Sometimes I think the best I can do for the younger generations facing today is just to never impose petty trivia about "the movement" ever again. Never deign imply I know what they should consider important. If "free" and "open" meant something to me, let their inheritors tell me what they mean now, in practice. Tell me about the world they built and left for them.
Maybe I don't have to choose. After all, who reads blogs?
My point of view is clear, but what I see is complex. Things seemed simpler back when I believed what Slashdot told me, before I'd spent twenty years getting involved and looking closer.
If you're looking for a seer with a salvation plan---as technology, legal innovation, organizational form---I don't have hope to offer you.
Look at the figureheads of free and open, the "philosophers". The ones we remember succeeded, but not on the terms of the lofty gospels they preached. Very few practical systems are "free". Most competitive software is closed, and sharing code across orgs still sucks much of the time. Linus succeeded, but Linus just wanted to code, get respect, and make good money. Glad he did.
Thinking we'd seen the end of software history got us here. Now I see more willingness to try new things again. They mostly wither or fail, but so did most early attempts at "free". Mutation, selection, adaptation.
In my experience, most people underestimate what's negotiable across the board. Especially those making enough to do most of their business with mass-market operations, like big-box stores and retail service providers, that profit by doing many, many standardized transactions every day, with minimal discretion or even personal involvement.
Below that, lots of haggling and informal trade often help people get by. The costs of that process can be another burden on the poor. At the high end, it's worth involving people with discretion on the sell side. Additionally, sales are often one-off and customized. They may also bundle a bunch of different items and benefits without clear line-item breakdowns.
When hiring a lawyer, I'd nearly always recommend getting terms down in a written and signed engagement letter before work starts. That is very much a negotiation, but it's fine to ask questions and comparison shop.
If you're starting with a call, it's perfectly normal to start by asking whether initial consultation will be billed or not. If it will be, ask the rate. If it won't be, expect some limits on what can be discussed. The best lawyers I know aren't cheap or easily tricked into giving free advice on consultation calls with speedrunners, but they are up-front about what they charge for and how.
Copyright under US law does not require "artistic expression". One of the requirements is called "creativity", but it's very easy to meet. The key phrase is literally "some minimal degree of creativity".
The fundamental policy choice was to protect computer software under intellectual property law, with exclusive rights and market compensation. There were a number of ways that could have been done. Other jurisdictions toyed with new, software-specific laws. But in the end the call in the US was to bring it under existing copyright law with some tweaks to definitions and a small handful of software-specific rules.
Good question. They have a new Juki machine to sew these on directly, but I can't tell whether it will be practical to sew on by hand. I expect most tailor and seamstress shops won't be taking our loans to buy machines just to sew these new zippers in one size.
You've given the argument from fallacy, dismissing an argument without any reference to its content, but only to its conclusion. The existence of bad arguments for a proposition doesn't condemn all other arguments for the same.
The question is whether any particular argument's strong or weak. That's a matter of evidence and reasoning.
Art versus engineering is a very dangerous generalization of the law. There is a creativity requirement for copyrightability, but it's an explicitly low bar. Search query "minimal degree of creativity".
The Supreme Court decision in Oracle v Google skipped over copyrightability and addressed fair use. Fair use is a legal defense, applying only in response to finding infringement, which can only be found if material's copyrightable. So the way the Supreme Court made its decision was weird, but it wasn't about the creativity requirement.
npm got around to `@{author}/{package}` and `@{org}/{package}` beyond just global `{package}`, albeit midstream, rather than very early on. The jargon is "scoped packages". I've seen more adoption recently, also with scopes for particular projects, like https://www.npmjs.com/package/@babel/core
The issue is what happens when libX@latest is updated and uses libd@2.0 but your other dependency libA@latest uses libd@1.3.1? In maven, crazy things happen. Sometimes it’s fine but if you have any kind of security, the version mismatch has different signatures and blows up. Ask any spring developer what happens when they have more than 1 slf4j in their classpath.
reply