… & of course we again ask Microsoft's GitHub to start respecting FOSS licenses, cooperate with the community, & retract their incorrect claim that their behavior is “fair use”.
The only thing I haven't seen said succinctly, although it's been hinted at by many, is this:
There is no one on the planet yet who has agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License.
That really says it all. Whatever your view about copyleft licenses generally: legitimate and well-intentioned copyleft licenses (e.g., CC-BY-SA, GPL, and Affero GPL) have many projects that use the license in an inbound=outbound contributor licensing fashion. All (two of the) SS Public License uses have a strict CLA that give the publishing entity non-SS-Public-Licensed rights to the contributions. We shouldn't take anyone seriously who promulgates a license but won't use it themselves in an inbound=outbound way. Period. I suggest we all try to not give further interest to this clearly risible licensing proposals from MongoDB and Elastic.
If there's energy to focus here, I'd say it's toward figuring out how to handle good governance of forks of these two projects. I hope folks can maintain the discipline to discern and bifricate these two very different issues.
> We shouldn't take anyone seriously who promulgates a license but won't use it themselves in an inbound=outbound way.
I would just treat them as proprietary. With access to code and opened gate to provide also code, if you are paying someone and they still do not care about your bug.
What may be better than fully proprietary and unavailable source.
I would not dismiss for example Windows just because they are not open source.
It's worth noting that Crate isn't contesting that SSPL is a perfectly legitimate open source license, it's the GPL part that's the issue for them.
GPL and AGPL are just as much used to "poison the well" for potential competitors to a product also released as open source, and dual licensing strategies are a well-known part of open source businesses. This hasn't changed with SSPL at all, there's just a lot of pearl-clutching about the fact that the high and mighty OSI has not signed off on it.
> GPL and AGPL are just as much used to "poison the well"
But it is also legitimately outside of the purpose as well... unlike the SSPL. The Linux kernel for example. No one has ever looked at the SSPL and said “I want to work on that project” unlike the the GPL, which I believe is the GP’s point.
> There is no one on the planet yet who has agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License.
Many of the people who are enthusiasts for the GPL should be similarly enthusiastic about the copyleft protections afforded by the SSPL. It, like the GPL, discourages commercial use by encouraging users of the software to open source any software they want to build on top of this software.
RMS would not be upset that the GPL poisons the well because companies don't want to open source their code, RMS would say they are denying user freedoms by failing to open source their code. The SSPL merely builds on this.
The only real sticking point here seems to be the OSI, and probably some manner of lobbying by tech firms to keep the SSPL from being accepted more widely as an open source license.
Comments of this sort was comme il faut in the 90s. But now, more than two decades later, GPL has proven its commercial value so many times over it's hard to take such arguments seriously.
Tit-for-tat business models grow faster than those staking out islands. Linux won. We need to move on from this.
By "discourages commercial use", I refer to the very-real-today fact that plenty of organizations won't touch GPL or especially AGPL code because of the copyleft restrictions. This is largely the same for SSPL.
Amazon could use SSPL-licensed Elasticsearch on AWS, if they wanted to open source AWS, and they'd probably still make bank on it. But they don't want to, so hence going to SSPL, like GPL, discourages their use.
Isnt sspl just agpl with "addtional" requirement only if you are a cloud service provider just for the benefit of their users? If am an end user of say Amazon, am I not getting more freedoms with respect to the source code of Amazon stack? Isnt that GPL is supposed to provide ?
"If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License."
Doesn't particularly specify what type of business you have to be running, though it's obviously partially related to whatever type of software you licensed under the SSPL.
The GPL affects projects which embed GPL code into them, and the SSPL effectively does the same, it just draws the borders wider, to anything used to provide it as a service to others. In a copyleft sense, that promotes providers of it to also contribute to the ecosystem of tools around it.
I dont think GPL forces anyone to contribute upstream. I am asking about the idea of freedom the end user enjoys with GPL code.
Does sspl build on it, give more freedom to end user or restrict that freedom.
If it gives more freedom, isnt that a good thing ? Why should people be up with pitchforks ?
I will happily contribute to a permissively-licensed code base for a project, although I'm aware that my contributions might be used in some closed-source platform later on. Exchanging my contributions for the ability to do whatever I want with the software is a reasonable trade.
I'm also willing to contribute to projects using copyleft licenses, on the basis that a project that requires all contributors to leave all of their contributions and derivatives of the product in the open offers a fair playing field.
I am way less interested in contributing to this new breed of semi-open projects, which require me to sign over my contributions in exchange for access under a license which stops me from using the project in certain ways, but grants one entity special privileges to use it in that way.
I think the evidence suggests that both GPL and permissively-licensed projects can be wildly successful. There are good reasons for both approaches, with different benefits and trade-offs. It's also legitimate to be irritated at "bad neighbours" who take without contributing back. I'm not convinced that this semi-open licensing approach is a benefit to anyone.
As the author, I can confirm I'm fully aware of the etymology of “A Modest Proposal” — my undergraduate degree included the Honors program in the Humanities and there are many professors who would be aghast if I'd forgotten.
I chose the title because the proposal should be not a big deal — especially given that these companies already demand that copyleft projects grant these 30 days — however, it's ultimately an untenable proposal. Just like the original Modest Proposal, it's made to a ruling class who don't realize their policies are completely unreasonable.
Your life or death scenario is an edge case with its own special complexities which should not be lumped in with discussions of the vastly voluntary choices we can make.
Karen's and my 2019 FOSDEM keynote (and accompanying podcasts) discuss her struggles with the medical device industry and how those struggles relate to the larger set of choices related to technology that we make. This isn't an issue that lends itself well to short-form discussion. The issues are quite complex:
I realize sarcasm is the "way of expressing things on HN", and I did some of it myself in a post upthread, but to get serious on norgie's point for a moment: I picked this specific issue to speak out on for two reasons: (a) as a regular traveler [0] and speaker at FOSS events, this was a great opportunity to draw attention to the problems with airlines, as all of us use them to attend these events and my blog is well read among FOSS folks and (b) as someone who is a frequent traveler, and recognized by Delta as a "good customer", I have a louder voice then most in this debate.
There are indeed a lot of issues that we should be speaking up on, and it can be exhausting to speak up on all of them. I try to target moments when my voice can get a bit more attention than usual for some reason and pounce on the opportunity to make a difference. I think it's a good approach.
(Again, I'm the poster of the ebb.org blog post that was the original article linked to in this thread; as others have mentioned, this article was changed to be about the Washington Post news story that inspired my blog post).
[0] and yes, the fossil fuel impact of that does bother me and I've spoken about that too at FOSS conferences)
I go to great lengths to buy clothes not made in sweatshops, actually. I admit I have some clothes probably made in sweatshops that I go second-hand. BTW, I've often been the only one at FOSS conferences raising the issue that t-shirts given out and/or sold were made by sweatshop labor.
Yes, the X200 I'm typing this on was probably made in a sweatshop, as was the Nexus One I still use as a mobile device. But, I use every piece of hardware I have until it breaks in an unfixable way, and I also only buy used hardware. I've purchased a newly made electronic device since the late 1990s.
As I mentioned in the original post, I've only worked for charities dedicated to causes I support. I'm curious to know which causes you spend your time getting "bent out of shape" to work on. Perhaps making up facts about authors of posts that get HN coverage is your cause? Is that your day job, or just a hobby cause? :)
Oh, and as for commuting, I work from home, which means I don't drive home from work any day. The last day I "drove home from work" was circa early 1997. Did you happen to research and were speaking about the commuting I did in the 1990s?
I wonder how the rest of HN readers cash in on this "guarantee" you gave them about the facts of my life which I can easily disprove you were wrong about.
TL;DR: while vmbrasseur of OSI does say "what's done is done" in comments here, I think the OSI shouldn't accept the proposal as submitted, and should demand that licenses submitted them to have gone through a prior public drafting process. This is particularly important for licenses whose stated goal is to make fundamental changes to how copyleft works. GPLv3 and (even better) copyleft-next made this the standard of how new license drafts are done, and we should follow that standard.
My friend, the "what's done is done" was purely in reference to the fact that the license was submitted for approval belatedly (IMO). My statement in no way implied whether the license itself would be approved as it stands.
Now that the license has been submitted, folks can now analyse and discuss it, openly. Any decision on the license will spring from those discussions and the related actions (should any be needed) that MongoDB takes based on the feedback they receive.
The proper place for that feedback is on the discussion thread on the review mailing list. Statements on blogs and comments on Hacker News are good for helping to frame that feedback, but aren't well placed to be included in a cohesive conversation.
Hey, Tim, I've talked a number of times with GitHub about the issue of lack of nuance in their license monikers on GitHub. I haven't gotten very far, but this change will cause me of course to raise it again.
As others have commented, kragen is jumping to excitement a bit too quick. GitHub's license data is not curated, and I'm quite sure determining a license of software is an undecidable problem; it just requires human judgment, and many self-report their own license incorrectly to GitHub.
GitHub has a lot of problems to solve before the license data they are presenting can be trusted. Even many very common programs have licenses that can't even be described with an SPDX moniker, so the "badge method" just isn't going to work.
Those who wish to learn more about copyleft after reading Ben's article may also want to look at the copyleft guide https://copyleft.org/guide for more information.
Ben is a contributor to the copyleft guide, so we'll likely merge in his article into the Guide.
… & of course we again ask Microsoft's GitHub to start respecting FOSS licenses, cooperate with the community, & retract their incorrect claim that their behavior is “fair use”.
A few more links to our work on this issue:
https://sfconservancy.org/blog/2022/feb/03/github-copilot-co... https://sfconservancy.org/news/2022/feb/23/committee-ai-assi...