My biggest question is if they use Halium/libhybrys at all, something that is hard to figure out from the marketing but their GitHub repos does have hybris-related stuff. That makes it a non-Linux device to me. Hybris breaks a lot of linux stuff that should just work like flatpak, something I found out incredibly quickly when using SailfishOS.
I don't think depending on Android drivers and having to run a small android just to access said hardware makes it a "linux phone". Especially when the linux experience is compromised because of it.
postmarketOS has no hybris and everything works great, but no device has all the drivers (in fact, no device at all is reported as having a fully functioning camera, let alone everything else) so there isn't a "flagship" device.
If I were to overspend on a linux device I want it to actually run Linux, not a handicapped version of it.
And even then, why stop at the OS? Why is this overpriced "linux" phone not boast having user-friendly and sustainable things like a replaceable battery (probably because it doesn't?). People in this niche don't want just a Linux phone, they want a phone that respects them.
I agree with you, and especially identify with the last sentence. However, I’m fed up with Apple and Google, and any alternative that doesn’t tie me to Google and has all functioning hardware and usable 5G or at least LTE with reasonable specs is a major win in my book. I’ve preordered the FLX1s. The FLX1, which is no longer in production, had a replaceable battery, but lack of a replaceable battery or non-pure Linux in an alternative phone certainly isn’t going to keep me chained to Apple or Google.
> postmarketOS has no hybris and everything works great, but no device has all the drivers
this is why halium exists. OEMs don't produce drivers beyond whatever kernel they ship with, so this is an attempt to build a system that leverages the crap they do ship.
> why stop at the OS?
Because the OS is the only thing you control. The reason the Librem 5 costs so much for a decade-old platform is because they didn't grab a predesigned device from another OEM. Doing everything yourself is going to be the only way to produce a first-class linux phone.
> My biggest question is if they use Halium/libhybrys at all,
That would be a showstopper for now, IMHO. Doing it with maintainable open source Linux drivers is the hard part of having a viable device, from everything I've seen.
Another concern are that I can't find who the developers are, nor even definitively what country they're based in. (I don't see it on their About Us page, ~~and the GitHub repo contributors are hidden.~~ I saw a reference to Sydney, but unclear.) (Edit: my mistake regarding GitHub contributors; they aren't hidden)
Also, it would be nice to have the option of a better hardware provenance than a generic whitebox(?) phone from some unidentified manufacturer in China. Even for individual hobbyist users, and certainly for corporate ones. (This is why I'd like hardware options combinations like Purism for the premium device, and a cheaper device that runs the same software but is still from a brand that at least has a reputation to preserve, like Pine64 or (ha) Google.)
It is not nor should it be a showstopper. A functioning device that can be widely used helps build eg an app ecosystem. That part needs to exist and it doesn’t really matter if it’s Hallium or not.
I guess I might agree, so long as that ecosystem is shared with Purism Librem 5 (a potentially sustainable device, if not affordable), and so long as a more affordable but also sustainable device (which means non-Hallium) will actually appear in response to this ecosystem stimulus.
At all times during the ecosystem stimulus, someone has to be keeping an eye on the real goal. Which is getting those affordable, trustworthy, sustainable hardware devices to become available.
(I've seen Linux handheld/phone projects fail for ~25 years, wasted lots of time and money on them, and would be happy to see something solve the hard problem of open drivers.)
> Why is this overpriced "linux" phone not boast having user-friendly and sustainable things like a replaceable battery (probably because it doesn't?)
Go lurk in their Matrix chat. They've noted in there that they didn't exactly have a ton of choice in stuff like this because you don't really get a ton of options as a small operation.
> in fact, no device at all is reported as having a fully functioning camera, let alone everything else
My Librem 5's camera is fully functioning just fine. Many entries in that table are either outdated or pmOS-specific, or marked as "partial" because they require some tiny manual intervention that's not a big deal in practice.
The pictures I shoot on my Librem 5 look nothing like the (pretty good) ones that you regularly post to the Fediverse. My photos are just a faded, grey, blurred, grainy mess. I can take the time and manually set focus (autofocus never works) but the manual focus slider and button are so difficult to read that by the time I figure out whether or not the slider is enabled, the photo opportunity is long gone.
When I look at your photos, I often wonder what I might be doing differently than you. But after two years of daily driving my Librem 5, I decided to no longer care, and just stopped making photos altogether.
I am taking photos with regular Millipixels from PureOS Byzantium like everyone else, without setting anything manually aside of triggering the autofocus sequence when necessary (in the latest version it can be triggered by simply tapping the preview; previously you had to cycle the "auto" button). The only thing that I do differently is how I turn the raw DNG file into a JPEG: see https://gitlab.com/dos1/glowup and https://source.puri.sm/-/snippets/1223
I think that's because Sebastian develops software for the Librem 5 and thus is likely not running a stock PureOS Byzantium.
I managed to get similar results in my holidays in late August(on postmarketOS 25.06 with Millipixels 0.23.0 and a patched kernel [1]).
Please note that I just used the Librem 5 as my "mainline Linux camera" and have not had a SIM in it in a while, and thus can't comment on how well postmarketOS 25.06 would work for daily driving.
The only major thing these kernel changes introduce is RAW10 support, which helps photos with high dynamic range that would have visible banding in the shadows otherwise. There are more changes, but their effects are either subtle or unrelated to still photos. Most of the pictures I post have been taken without these changes, only some of the most recent ones used them.
>(in fact, no device at all is reported as having a fully functioning camera, let alone everything else)
Nit: The Pine64 PinePhone's cameras at least have been fully functional since 2021. It's a very shitty pair of cameras, but they're definitely fully functional.
I know the wiki.postmarketos.org page for it says the camera support is "Partial" and that a bunch of drivers are out-of-tree. This and much of the rest of the page is extremely outdated, and I (maintainer) just haven't had the time to go through that page and fix it up.
I'm not a PostmarketOS user (I prefer Mobian), but thanks for maintaining the PmOS Pinephone port. It's thanks to people like you that real Linux distros on phones can continue to work and get better.
> My biggest question is if they use Halium/libhybrys at all
From what I have been able to tell, the folks behind Furilabs are also behind Droidian, which is Halium/libhybrys based. Furilabs/FuriOS is the commercial version of it.
> in fact, no device at all is reported as having a fully functioning camera, let alone everything else
I wish usb cameras were sold in the same form-factor as phone thermal cameras. Then the missing drivers for the built-in cameras wouldn't matter as much.
I doubt the market is nig enough, but I know at least a few people who I'm sure would buy a phone that was actually as thin as the new iPhone Mini pretends to be without the camera bump, then have a USB C camera attachment for the rare occasion they need to take a photo.
No: this would allow such cameras to be internally connected to a custom-built phone via USB, but without the connector, oor using a tiny connector. Think Framework laptop peripherals, only built-in
Once you have the camera-controlling binary blob separated in an MCU behind a USB interface, you can run a modern kernel (maybe not even Linux), without running the binary blob in it.
Have you seen the prices for Google Drive et al? The NAS setup you describe (which I wouldn't consider worth the money for that little space) is what, 12GB with 1 parity drive?
Google One for 10TB is 274,99€/mo (at least in my country) so you'd make the entire nas price and subscription cost within a few months, let alone years.
There just aren't compelling public cloud for large sizes (My NAS is 30TB capacity and I'm using 18 right now) and even if you go the more complex loops with like S3 and whatnot you still get billed more than it's worth. Public cloud is meant for public files, there's a lot of costs you're paying for stuff you don't need like being fast to access from everywhere.
As someone learning Japanese I'm really appreciating tools built for JP specifically: Renshuu and Wanikani. Both use SRS (same as duolingo) but spend a considerable amount of time actually teaching the grammar and nuances, they both avoid starting from everyday phrases like "I would like sushi" to instead build a foundation first, and many other little things that make it a much nicer experience than Duolingo who's trying to use a very generic approach that maximises small term satisfaction in exchange for painful long term learning.
I was under the (possibly incorrect) impression that Renshuu was very beginner unfriendly and WaniKani skips the most basic stuff (hiragana et al) and is “just” to learn kanji which ofc is important. Was I wrong?
On WaniKani: that’s correct. In their FAQ (I think?) they link out to an article on Tofugu (aiui run by the same people) which gives you a couple good anki decks to learn hiragana and katakana. I started wanikani without knowing either, and found it manageable at the start by referring back to a hiragana chart. At some point I went through the decks, and after about two weeks I could read hiragana well enough to leave them behind.
Certainly not a complete resource for learning the language, but very effective for learning (to read) the kanji.
It focuses on teaching grammar and vocabulary through listening comprehension. The creator has put an immense amount of effort into it, to a point where I cannot believe its free. I highly recommend it.
I am a year into learning Japanese my self, and kind of wanted to learn vocab and kanji at the same time (and also see example sentences for the vocab which I can put into my anki deck). My method is when I start a new kanji I pick a few words that contain that kanji, bookmark them (and maybe add to my anki deck), and then when it is time for a reading review if I can remember how to pronounce those word I rate it as good.
Thanks for sharing, I'll check it out. I am currently using Wanikani +Tsurukame to learn Kanji, from your description your approach sounds similar with more customization?
I just had a look at it, love that it also teaches the stroke order, this is something I have no tool for at the moment.
If you are happy with WaniKani, you should probably just keep using WaniKani. It is a fine app (though a bit pricey). But I talked about the difference a bit in another thread https://news.ycombinator.com/item?id=43839879
The gist of it is that I like studying vocab and components (radicals) at the same time as the kanji. I kind of swap out the on/kun-yomi reading practice with bookmarked vocab, if I can remember the pronunciation of a couple of words with the kanji, I mark it as good. I also think writing the kanji helps remembering it (although I‘m not strict about it; personally if I screw up the stroke order, or add an extra tail, etc. I still rate it as good). I am also a fan of self rating rather than input evaluation.
Note that they can't "take it away" completely. The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too. So a developer who has contributed to an AGPL codebase cannot be denied access to it. Due to the AGPL license, any code will always be open source and thus the CLA cannot claim exclusivity over the contributed code and prevent its (re)use by the developer in any manner.
The only concern then is ethical - will the developer be monetarily compensated if the product makes money? I believe they should be. Other open source developers may disagree.
Note also that for a commercial open source project, a CLA can offer some legal protection - by signing a CLA a developer declares that they own the copyright on the code, which reduces the liability of the commercial venture behind the open source product if someone contributes "pirated" code.
Is this actually legally binding? What would be the difference w.r.t. informed consent, between DCOs and the "I have read and accept the terms and conditions" checkboxes from most websites?
It also gives me similar vibes to the Do-Not-Track HTTP header since both can be enabled by default.
DCO is something like "Signed-of-by: me myself <me@example.com>" you have to actively add to your contributions, which is usually a conscious and willful act that is far more complex than blindly ticking a box (or even leaving a pre-ticked box ticked). Since that bar is higher, I think the legal weight should be higher.
CLA-Assistant is also similarly simple to fill out, so that can't be the difference there...
We've looked into the DCO before. It turns out CLAs are more common and easier to deal with, thanks to a tool like cla-assistant.io. We ended up opting for it for the sake of simplicity.
> The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too.
That's true in the sense that there will always be an AGPL version, but it's not true that "anybody else" can use it to. In many situations you need to acquire a non AGPL license from the original copyright holder to be legally able to use the software in certain environments. That's why CLAs are important so that there is always a copyright holder that can give you a non AGPL version.
If your business depends on some form of closed-source codebase, than yes, an AGPL codebase will not suit your need. But from an opensource developer perspective it doesn't matter. For example, if you release your source code under the more freer license (like BSD, MIT or Apache), you can indeed close source your code. But so can others. I can use your source code, add more features to it, and close source it. I would be under no obligation to share my code with you, while also having the right to use your code as I please. This is not so with the AGPL. An AGPL + CLA makes this explicit - a developer has to voluntarily give away this right with a CLA. (And this gives developers some additional leverage).
Unless you define Open Source developer as Hobby only licenses matter. I’m an Open Source developer and I want to be able to use software no matter the situation.
And as a result free software was released to the world which everyone can freely use and modify under the AGPLv3 terms. And unlike permissive open source licenses, only the copyright owners have the right to sell proprietary versions. They maximized freedom and secured a business model in one fell swoop. People are only required to transfer copyright if they want to upstream their code, they can always keep their copyrights by maintaining a fork instead.
It's pretty much perfect. Stallman himself suggests selling exceptions to the GPL as a viable business model for companies, Qt being the number one example. I actually emailed Stallman and asked what he thought about this new AGPLv3 SaaS pattern, here's his reply:
> It is my understanding that as the copyright holders
> they have the right to do it without any problems.
> They leverage the AGPLv3 to make it harder for their
> competitors to use the code to compete against them.
I see what you mean. The original developer can engage
in a practice that blocks coopertation.
By contrast, using some other license, such as the ordinary GPL,
would permitt ANY user of the program to engage in that practice.
In a perverse sense that could seem more fair, but I think it is
also more harmful.
On balance, using the AGPL is better.
Their github repo just says AGPL 3.0. Can you point me to the other constraining terms are? This would be quite interesting (like the "Open Core" people). And when I say "interesting" I don't mean a positive feature.
The project is licensed under AGPL, but outside contributors have to sign away their rights with CLA if they wish to contribute to the main project. It's in CONTRIBUTING.md [1]
> In order for us, Retake, Inc. (dba ParadeDB) to accept patches and other contributions from you, you need to adopt our ParadeDB Contributor License Agreement (the "CLA"). The current version of the CLA can be found here.
> You hereby grant to the Company and to recipients of software distributed by the Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
TL;DR: my quick read is that they are trying to do the right thing.
My not super-close reading is that this is actually reasonable (but note: I wrote the original GNU blanket assignment back around 1989 or 1990 so you may consider my perspective bogus).
This agreement says that you confirm that you have the right to license your contribution (that what you wrote isn’t actually your employer’s), and that they can use it without restriction, even if there’s something patented in the submission. It doesn’t stop you from using the code for something else. But you can’t come back later and say “hey, yank out these lines of code which I sent you long ago”. It's not even an assignment -- you retain ownership.
If I were doing this, personally, I might add something to the effect of “btw if the company tries to change the license in a way incompatible with the AGPL 3.0 or later versions this license I have you becomes void” but that could implicitly be in there (if explicit, I missed it in my quick read).
Interesting. I think concerns about legality of contributions are completely understandable.
But doesn't this CLA in particular (and most CLAs out there generally) assign the company behind it a license to distribute all contributions under any license they wish? Specifically the part that I quoted where contributors give them an "irrevocable copyright license" to "sublicense" their contributions?
As far as I understand, this allows them to unilaterally re-license the project as a whole (to proprietary or non-free open source) without asking contributors for permission.
The only way I'd agree to a CLA is if it included explicit language that ensured that they couldn't do this, e.g. "You hereby grant [...] under the terms of the AGPL v3 license", but I'm not a lawyer.
> As far as I understand, this allows them to unilaterally re-license the project as a whole (to proprietary or non-free open source) without asking contributors for permission.
That's generally how CLAs work, to enable re-licensing. For many commercial AGPL projects that's also needed because the copyright holding entity will sell/provide non AGPL versions to customers that legally cannot use AGPL software.
> But doesn't this CLA in particular (and most CLAs out there generally) assign the company behind it a license to distribute all contributions under any license they wish?
Yes. CLA requirements for commercial AGPL open-source projects actually highlights an important feature of the AGPL - you need explicit permission from the developers to use their code in a proprietary codebase.
Codebase under a permissive open-source license like BSD, MIT, ZLIB etc. can be used by anyone and even packaged into a closed source codebase (with a proprietary license) even without a CLA. All that such license demand is that you do not deny public attribution to the developers and highlight the original license (here's an example from the old Opera Presto browser which was a proprietary closed browser with open source components in it - https://imgur.com/a/KDavWLd ). On the other hand, an AGPL codebase cannot be packaged into a proprietary codebase because the license requires not only attribution but also the requirement that the all source code, even the non-AGPL parts, has to be compulsorily shared if you link it with an AGPL codebase (i.e. it forces all code to be always open source).
The underlying philosophy of the xGPL license is the right to repair the software you use. And you can only do that if you have access to the source code of the software. Under AGPL it is illegal to close-source an AGPL codebase. But, AGPL also recognizes the rights of a developer on the code they created. It thus doesn't prevent the original developer from re-licensing their own code or even transferring the rights to another. Thus, in some way, AGPL actually forces the CLA requirement (if you want to distribute a software under proprietary license) and let's the developer decide if they want their code to be reused in a proprietary codebase.
"In order for us, Retake, Inc. (dba ParadeDB) to accept patches and other contributions from you, you need..." makes it sound like their hands are tied, you must assign copyright, there's no other option.
In reality, this is a (contributor-hostile) choice they made. They could have made different ones.
But you aren’t assigning copyright, you’re getting a license to bundle the contribution with the rest of the package.
And they don’t feel safe including a patch without a license to use it. Not an unreasonable position to take.
The wording is explicit (italics mine):
> You hereby grant to the Company and to recipients of software distributed by the Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to…
When you contribute code to an AGPLv3 project without a CLA, you are also giving them a license to use your code. The name of that very license is... 'APGLv3'!
The CLA means you're giving them an additional license: one that lets them do things that the AGPLv3 wouldn't, like use your code in proprietary software.
This is common for FOSS-maintaining organizations that want to use dual-licensing as part of their revenue strategy. Users (including organizationswho are comfortable publishing any downstream changes they might make under the terms of the copyleft license use the free version. Users who are not can instead choose to purchase a proprietary license, like they would with closed-source software.
Often there's some hope that as users of F/OSS, the developers and users are overlapping groups, and there's enough alignment of interests there to provide some level of assurance that the developers (or publisher, in the case of a corporation or collective entity) won't suddenly make drastic changes without user input. (Often, too, that isn't actually the case.) A CLA can give the developer the ability to make such drastic changes as taking a copyleft project and creating a closed-source fork. In cases where the development work is supplied predominantly by a single commercial entity, that means that they can essentially orphan the project out from under you, leaving the open-source version of their software an unmaintained vestige of a proprietary commercial offering, at any time.
So CLAs involve a lot of trust or a lot of risk. Some companies have set up non-profit foundations to be the official stewards of their dually-licensed software so that the chief/commercial maintainers of the software can leverage the dual-licensing revenue strategy while fostering strong community trust. See, for example, the Free Qt Foundation. When Google wanted a CLA as insurance against patent litigation for Kubernetes, they did a similar thing and set up the Cloud-Native Compute Foundation so that Kubernetes could have a 'trustworthy CLA', so-to-speak.
I hope that clears up both why upstream developers might sometimes want a CLA of this kind and why downstream developers can sometimes be leery of them.
Honestly I think this is fine, especially how they've done it. Most CLAs seem to require copyright assignment, but theirs does not. Outside contributors keep their copyright, but grant the company a license to (more or less) do whatever they want with it.
I think we're at a bit of a crossroads here. Enough (smaller) companies have been bitten by the likes of Amazon monetizing their code and crushing the original developers' monetization strategy. So we see some companies turning to non-F/OSS "source available" type licenses instead. This is bad for the open source community as a whole.
IMO, AGPL+commercial is a fine compromise, and companies need to be certain that if they take contributions from the community, that they can still sell commercial licenses for the whole product, including the contributions, without issues in the future. Requiring contributors to assign copyright is one simple way to do that, but I think the path this company has chosen is a lot nicer in letting contributors keep ownership over their contributions.
For a piece of software where the expectation is that the company is going to be doing 90% of the work, and outside contributions will be relatively small, this seems entirely fair to me.
In practice, projects that take this approach do the majority of development in house, and external contributions are small. It makes sense that a company that may have spent several years developing a product can sell commercial licensing. The only alternative way to monetize AGPL works is to provide services and support.
Nobody is forcing anyone to give away their rights. You can always distribute contributions under AGPL in a forked repo.
The alternative is that if you're making meaningful contributions then it's in the company's best interest to hire you full time to do it.
Contributing upstream can benefit the ecosystem around the project, and the money that comes from commercial licensing also benefits it. In some cases the project would die if it didn't have the commercial side. They're not running a charity and if they aren't generating enough revenue they'd likely be working on something else rather than maintaining a FOSS project that doesn't make any money.
I love single-license-per-project F/OSS companies like Red Hat, but they're rare. I'm attracted to companies who are so committed to F/OSS as a practice that their software is copyleft and they don't require a CLA.
But dual-licensing is a tried-and-true strategy and the basic premise is very clear and very fair: share your downstream changes or pay a fee. And a CLA is required to make that work.
Something commenters here seem to miss is that all permissively licensed software is vulnerable to the same kind of maneuver that copyleft+CLA software is. If MIT or Apache don't scare you, neither should GPL+CLA.
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
Even worse, let's say I am a paid customer for their support and run on their proprietary license. Once they rug pull or jack up the prices or whatever, I cannot fall back to AGPL hosted locally. If it were permissive I would have had other options.
AGPL I fully respect as Free Software. AGPL+CLA, however, is not your friend and is pure deception. If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary. In fact, it might be slightly worse as folks are sometimes cavalier in accepting contributions without proper copyright license/assignment and they pass them on to you under their paid license and expose you to some risk.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates.
Strictly speaking you are correct. I concede that from an individual licensee perspective. The scenario I had in my head is under permissive, if the community forks, they would be on par with the original author. Under AGPL+CLA, if the community forks, the original author can sell "usable" licenses but the fork community will be stuck to developing an AGPL-only solution, which is a practical hinderance for the new community gaining any ground at all.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
> If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary.
But right about this. In the scenario you describe, you're a customer under the proprietary license— the kind of dependency your proprietary software product has on the software is the same kind it might have on any other proprietary software. The AGPLv3 version is not a backup option for you.
And it's true that the dual-licensing game the original vendor has set up is one that only they will ever be allowed to play.
If my company were considering purchased dual-licensed AGPLv3 software, I'd give advice like the following:
> It's great for the wider public that there is an open-source version of this exact same software our there. But what we're considering buying here is not that— what we're considering buying is proprietary software. For us, all that the availability of that open-source license means is that this is proprietary software whose source code would be easy for us to inspect, and that upstream might even accept our patches for issues that we encounter. I think both of those things are huge advantages! But if this vendor gets bought out or shuttered, we could potentially be left in the lurch much as we would if the software were exclusively proprietary. That's often an acceptable risk, in my opinion, and it's certainly one that our company has deemed acceptable with many past and present proprietary software purchases. But we should note that on the assessment: if we buy this, we're not buying or depending on open-source software; we're buying and depending on proprietary software.
All that assuming, of course, that the proposition is to use the AGPLv3 software in a user-facing, proprierary web service under the assumption that the copyleft component of the AGPL extends to that web service. If we were evaluating it for use in an internal service, where the end users are our own employees, or an external-facing service that we'd be comfortable releasing under the GPL, or we think that the way we want to use it would not require any license changes for us even if we take thw AGPLv3 version, I'd instead say something like
> Ask the lawyers as always, but I don't foresee any problems. I think this is great and I'd love to use it. If our legal people aren't used to considering copyleft licenses, can we have them consult with the FSF or the SFC or the EFF or something before they make a decision about this? Is that a thing?
Anyway, I agree with you about how being the customer (under the proprietary license) of a company like this is different from being the customer (for support services only) of a company who publishes permissively-licensed free software. I don't agree, though, that the dual-licensing thing is a trick! I think it's totally possible for everyone to go into that kind of arrangement eyes open and be happy with it. I hope and expect that's the goal for companies like that of TFA.
> You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
I am not discussing ethics or morality here, just practicality, and yes, from the perspective of a user that is not primarily releasing open source. Note that it's somewhat different and more general than your characterization. I might be in another business, not software, but unwilling to touch AGPL within my infrastructure due to risk of virality. Strictly speaking, I am not a "proprietary software vendor" as I am not even in the software business, primarily. Nevertheless, your general point stands.
I am not arguing it is bad. Simply that I would not characterize AGPL+CLA as "no vendor lock-in because open source." I put it right in the bucket of e.g. Oracle proprietary database. I am not saying it is bad or totally unreasonable. I just don't buy up the marketing koolaid.
The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing).
AGPL is also not considered a very safe license by large organizations even if you want to run it internally unmodified, alongside the rest of your application. Many big companies have blanket bans on AGPL.
What happens if you (the contributor) fork the project, make a really great feature in your own fork, make it available as the license requires, then the startup integrates changes from the fork back into their own project. Does this then prevent them from ever changing the license away from AGPL?
Yes. If they do it they will be able to license the form back as AGPL but that wouldn't let them license the new thing under their commercial license (effectively useless commercially). At that point they are a peer with you.
Some startups may not know this or knowingly violate this.
> The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing).
There's nothing specific to the AGPL or startups here, it's a common model. The FSF themselves require copyright assignment if you want to contribute to FSF projects.
Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
Secondly, don’t equate the FSF with any other company. The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy; therefore, it’s completely reasonable to also trust the FSF with a copyright assignment.
> Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
The FSF requires copyright assignment for many (possibly no longer all?) of their own projects, e.g. GnuTLS. Of course it's up to an individual project whether it requires it (how could the FSF possibly control what some unrelated project does?), but on those projects that the FSF themselves run (or at least many of them, and traditionally it was all of them), they require it.
> The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy;
They cannot change the GPL. They can publish new version of it, and recommend that you license your project with a term that permits it to be used under those new versions, but this is not obligatory (and notably e.g. the Linux kernel does not).
> The FSF requires copyright assignment for many (possibly no longer all?) of their own projects
The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers. Which is what I wrote. The fact that many projects do choose to require copyright assignment does not make you be less wrong when you said that the FSF requires it.
> They cannot change the GPL.
Technically true. But the FSF can publish a new version of the GPL, which all GPL-licensed software using the “or any later version” language, which is most GPL software, will then use. Linux is an oddity here.
> The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers.
And in the case of their own projects, the projects where the FSF is the project/the maintainers, what is it they do? They require copyright assignment.
Many GNU projects are maintained directly by the FSF/GNU (the same entity; their own statements acknowledge that they share personnel and have no clear boundary between them). And for many more projects they hold the copyright and provide the funding/hosting/etc. and the named maintainer is either a member or affiliated with the FSF/GNU, which suggests they exercise some control over it (e.g. the published hosting requirements for Savannah say that projects they host "should" follow the GNU hosting standards, which include requiring copyright assignment to the FSF if the FSF holds the copyright).
Well, requiring copyright assignment (not just a CLA) is in their published rules for using Savannah, and something almost all major GNU/FSF projects did in the past. Even if it's now something they merely encourage rather than require (and I'd be interested to see a public confirmation of this) my point stands.
Importantly, GPL does not include such line. That line is not part of the GPL. Critical software such as Linux famously do not have that and are not GPLv3 for example.
The Author can choose to license the Copyrighted Work under various licenses. The common boilerplate that many Authors of GPL software choose to use is a boilerplate that says they are licensing their Work under GPL version X or any later versions supplied by FSF. That boilerplate is Author's declaration of license contract and not the license itself.
Basically the Author is directly saying (not through the GPL text) that "I trust FSF to come up with future licenses and call whatever they want GPL version Y [Y>X] and I'll be willing to license my work under that license sight-unseen also."
If I accept their license on 2024-08-14 to use their software, they can do whatever they want to the license after that, but they won't be able to revoke my license to use the code as of 2024-08-14 under the license present to me on 2024-08-14.
No update on the license can retroactively change what I agreed to.
The model is equivalent. Everything else is different.
FSF's structure, purpose, history and guardrails against non-hijacking make it distinct from a startup whose purpose is to claim "open source" but preclude Amazon and keep their revenue stream. Nothing against them or their business model; it's their prerogative, of course. So is the community and customer's read on their future actions. To claim you should assume they are the same is preposterous and/or fooling yourself. Criminals and police officers both have guns too. Doesn't make them identical.
Organisations that start by claiming to be open-source and rug-pulling are something to be wary of. But neither AGPL nor CLAs are a particular red flag for that. Plenty of well-behaved organisations use CLAs or copyright assignments, and plenty of badly-behaved organisations use licenses other than the AGPL (e.g. Redis had a 3-clause BSD-style license but still did the same thing).
Can’t really refute a hypothetical. Is there a polymarket bet for that? I will categorically take the under on your position for any company doing CLA with AGPL. The intent is so glaringly obvious.
As someone who has been on the email client hunt ever since Google Inbox was taken off my feet I can say that I'm a very happy customer of eM client and it's actually one of the few apps that make it painful to leave Windows (since the devs have no intention of porting it to Linux).
It's pay once and it comes with a free version if you just wanna give it shot, the only bad thing for me was how annoying the website was with dark patterns trying to push sales, the software itself is great.
Console support and porting effort in general is the main biz of some companies, the most popular being M2 (mostly emulators) and MP2 Games (handles Clickteam Fusion ports to console like Freedom Planet, Baba is You), but there are many other smaller studios. They mostly seem to have their own proprietary tech.
That kinda work also can't be open source as official console SDKs are expensive and covered by NDAs.
If the next Undertale/Minecraft gets built in Godot, W4 Games would be the easiest way to get that game to consoles and rack in tons of royalties, so I think the investment is justified (though hoping it doesn't poison Godot in some way)
> W4 Games is working on a complementary offering that is simpler in nature. We are developing and plan to offer fully middleware approved console ports for all platforms (Nintendo, Microsoft and Sony). This will place Godot in the same category (and offer the same assurances) as the large commercial game engines.
> Instead of offering porting services (which are still required by many developers and publishers), W4 Games will offer fully working console ports. These ports are intended to be middleware approved, meaning that the console manufacturer approves the port and certifies that it meets the required standards of quality, as well as supporting the full (or as close as possible) feature set of the console, including full integration to the console SDKs (for ease of development and deployment).
Yup, and you can already mix and match both local and cloud AIs with stuff like SillyTavern/RealmPlay if you wanna try what the experience is like, people have been using it to roleplay for a while.
Maybe not yet? Google already made having non-store extensions as annoying as possible (e.g. a nag every time you open Chrome that tells you to disable them) and maybe they think that's working well enough to dissuade people.
They nag every time you open Chrome? Terrible. I guess that's why I use Brave, which sideloads with no problem. Hopefully V2 will continue to be sideload-able there indefinitely.
It probably scared the downstream, see Microsoft pushing out a press release as soon as possible since they have been investing tons of money and PR into their OpenAPI partnership and needed to calm their investors and partners.
Just look around forums and socials like Reddit. I see people bitching how OBS Studio doesn't work for them the exact way they want it while contributing nothing to the project almost daily.
This happens less where the FOSS choice is a drop in a sea of established proprietary packages (FreeCAD, KiCad, Godot) but way way more when they have already established themselves as the popular pick (OBS Studio, Blender) so they get flooded by less tech-savy, more casual users that don't really see the value of open source other than they don't pay for it.
"Normal" people have always had stuff given to them for "free" (either "you are the product" or built-in licenses like Windows) so they don't realize the goodwill and sacrifices that FOSS goes through.
> so they get flooded by less tech-savy, more casual users that don't really see the value of open source other than they don't pay for it
this was solved 30 years ago by an important socio-technical invention called the FAQ, used together with a social convention of not elevating or rewarding vexatious messages.
A solution was proposed, the problem was never solved because people generally don't read or believe that social convention doesn't apply to them in this situation.
I don't think depending on Android drivers and having to run a small android just to access said hardware makes it a "linux phone". Especially when the linux experience is compromised because of it.
postmarketOS has no hybris and everything works great, but no device has all the drivers (in fact, no device at all is reported as having a fully functioning camera, let alone everything else) so there isn't a "flagship" device.
If I were to overspend on a linux device I want it to actually run Linux, not a handicapped version of it.
And even then, why stop at the OS? Why is this overpriced "linux" phone not boast having user-friendly and sustainable things like a replaceable battery (probably because it doesn't?). People in this niche don't want just a Linux phone, they want a phone that respects them.