Boden – Native mobile cross-platform applications
boden.io
boden.io
> Finally, there will be a commercial licensing option for everyone who cannot or does not want to comply with the GPL.
It's possible to have GPL v2-licensed software on the App Store, but it essentially requires relicensing or dual licensing by the copyright holder (which is what they do here with selling a commercial license to distribute).
This is often overlooked. If you want to keep LGPL you can investigate "linking exception", it's used by some GNU libraries if I recall correctly.
This has been discussed for a decade:
https://stackoverflow.com/questions/459833/which-open-source...
https://roadfiresoftware.com/2013/08/the-problem-with-using-...
Probably depends on the reasonable(?) license fee.
The original comment was that this would limit adoption due to licensing restrictions, and I'm not sure how this change helps.
However, if you aren't making money, and are still using the work of others, then it's good to contribute back - even if that's just by open sourcing your work for others to learn from and study. It's not required, but neither is it required for this framework to have a free tier, much less a truly free one that helps protect the future of your app.
"The primary problem is that Apple imposes numerous legal restrictions on use and distribution...through the iTunes Store Terms of Service, which is forbidden by section 6 of GPLv2."
https://www.fsf.org/news/2010-05-app-store-compliance
See also https://apple.stackexchange.com/a/59495
There is also a significant difference between giving away free applications and giving away the source code. Both from an internal perspective (the company may want to charge for the product or related products or products on other platforms now or in the future) and an external perspective (the app may require other software for which the company does not have rights to release source code).
"Here's a free loaf of bread."
"Why don't you just give me the bread factory and the farms that supplied the ingredients?"
The main issue we see with the GPL is that your app has to be effectively licensed under the GPL too, which makes your app's license incompatible with the iOS App Store's terms of service.
This is apparently not the case with the LGPL. Yes, you will have to provide a way for users to relink your application to another version of Boden. As far as I can see (I am not a lawyer), this can happen outside of the iOS App Store.
Our US lawyers are currently investigating this. As soon as we get a reliable assessment from the legal experts, we'll add an LGPL option to Boden.
(VLC is an example of a well-known program that relicensed to LGPL and now is available in the app store, so clearly it is possible)
(There are plenty of App Store apps with LGPL code in them. The question is, should they be there? And VLC is not a good example, since presumably, I don't know - but I think all of it is LGPL or in any case, open source. The user can rebuild all of VLC in that example. The situation with Boden is going to be that a an app, probably proprietary, has a Boden library in it.)
Others have pointed out how it could work with closed source apps. It's a bit more complicated, but it certainly is possible.
Also you could follow the JUCE library model they got their free version and the pay version with a very attractive payment model.
I like JUCE but the components for mobile still not native l&f, Boden looks very promise with clean code using c++17.
But please keep a reasonable price for developers that make free apps and easy to pay.
Also if you could get a Rust version that it will change everything :)
We have come to the conclusion that LGPL is currently the best option to align both of these perspectives and provide the best value in the long run.
If GPL/LGPL isn't sufficient for you, we'll be offering a commercial license with fair terms as an alternative.
Lets keep Boden FLOSS forever!
It would be better, though, if they published pricing and had a self-service purchase process, rather than requiring users to contact them.
What am I missing?
On iOS, Apple enforced code signing on all apps, so a user cannot download an app’s source, modify it, and use it on their device. Code signing prevents that, therefore would be a violation of GPL.
But I can do this for open source apps? More specifically (disclaimer: I am not a lawyer, and I don't know if this has been tested in court), I personally don't see the GPL requiring that I be able to modify the exact, signed binary that I was shipped if I can create an equivalent one myself.
To use the modified software on your device you have to be a "App Developer" (or whatever Apple calls it), and in the process to becoming one accept the TOS imposed by Apple. So you are only as free to run the modified source as Apple wants you too be.
Just trying to figure out where the incompatibility will the GPL is coming from.
Advocates for GPLv3 say that the common good includes ensuring that everyone has the ability to obtain and modify the source code to everything they run.
However, others say this actually infringes upon the common good, because it artificially prevents technology from developing and being used, by placing too much importance on the role of technology (and the Perfect Software ™) in the quest for human happiness.
I strongly agree with the second group.
2. The other option does already exist, and that can't be ignored or erased.
3. The second group wins out because most people clearly see that technology isn't the limiting factor in human happiness.
No one forces people to use v3, and notably the linux kernel will be v2 forever. Market segments have settled against certain licenses, but others don't care. I'm glad developers have choices.
The choice to use a particular variant of the GPL may be an effort to spite companies. Personally I'm looking forward to the next iteration of MS's stewardship of GitHub in the hopes that they add a "buy a license" button so devs can make sure freedoms are protected in the general case but also make money by giving alternate licenses to companies that were never going to contribute anything back anyway but may benefit the common good in some other way.
For what it's worth I'm not entirely sure the grandparent's account on code signing is the issue with GPL on iOS, but I'm not a mobile developer so I'm relying on memory of reading other accounts. My prior belief was that it was simply that the end-to-end process of putting a release build of your app on the app store involves integrating Apple-copyrighted code which they don't want to become infected by the GPL and so they don't allow distributing apps under the GPL. Even though side-loading isn't as easy as Android you can still do it with a developer build, so it can't just be some issue of cloning a GPL repo that's 99.9% shared by an app store app and building and using your version locally...
With regard to the GPL licensing issues brought up here: We are aware that the GPL is not sufficient and we are in the process of adding an LGPL option. This will allow you to publish apps based on Boden on the iOS app store.
I fixed the parent comment.
Maybe I’m wrong but the niche seems too small to be sustainable.
AdSense team rescued Dart from certain death.
They also used to be heavy GWT users before, a stack now mostly discarded by Google.
- Boden supports native components for iOS and Android and maybe other platforms in the future. - uses c++17 really clean with powerful abstractions, think all your app in just c++17, no xml or other craps, I want to make my app with just c++17. - no garbage collectors, slowness, pause the world etc - single binary - the fastest programming language in the market.
the list goes on and on.
Edit: not to mention no support for text areas, will be interested to see that abstraction :)
I also wonder if this will be able to target the puri.sm Librem 5 when that comes out?
> Yes, I was also wondering why it's necessary to come up with yet another smart pointer, which you need to learn and which is probably not battle tested. - https://news.ycombinator.com/item?id=18586992
Even though on the main website they say:
> No custom containers, smart pointers, or reinvented basics. This allows you to reuse your existing knowledge and focus on what's most important: your app.
By relying on the compiler to check it?
Cross-platform GUIs never work. They almost work to the point where managers latch onto the idea because they think it will let them fire half of the engineers, but the end result is always well in the uncanny valley.
Open Gimp on macOS and see what I’m talking about. Or Slack. Or Eclipse. Etc.
I suspect Qt people developed QML for this reason: it is hard to beat the experience of instantly running something vs compiling C++ code on each run.
Does this thing work in the same way as flutter? (ie. your own UI framework that looks and feels like the official one?)
https://flutter.dev Checkout youtube for presentations.
Build once for iOS, Android, ChromeOS, Web, All desktops.
Imagine the "evolution of man" drawing. C++ is the middle guy not exactly standing upright.
>Handling callbacks without piles of Rc<RefCell<>> to access widget data
That's why you don't let widgets hold program state, they should just propagate deltas and display current state. It's a different way of thinking about how UI can work, but imho it has a lot of benefits aside from just speed and safety.
>having vectors simulating graphs,
You mean adjacency lists? They're a canonical realization of a graph, and a fast one at that.
>having to deal with use-after-free indexes.
What do you mean by this?
That's how delphi does it. Connect widget to a data source and it will update reactively when data source changes. And data source is accessible without touching the widget. When doing a batch update on data, you can also disable widget updates in order to make rendering faster. It also works both ways, so when data is changed from within the widget, the bound data source will be updated accordingly.
If Rust answer to typical UI programming patterns is "you are holding it wrong" then don't expect too much uptake by mainstream UI developers.
See Catherine's talk about their game engine implementation, regarding use-after-free indexes, and techniques to avoid it, by binding timestamps to indexes.
I didn't mean to imply that, just that when I see people complain about the ergonomics of the language and point to using a bunch of Rc<RefCell<T>> stuff usually smells funny, it implies to me that you're either trying to use OO or control flow architectures and patterns, where the type system is able to handle the edge cases that you'd need to think about anyway. There are nicer alternatives, especially in terms of data flow architectures.
And I don't know what you mean by "indexes" in this context or which talk you're referring to, do you have any more details or a link? Google isn't finding me anything.
Here is her keynote talk at Rust Conf 2018.
https://github.com/fitzgen/generational-arena
I'm not sure what your ultimate point was though? You don't have to use anything like that in normal Rust code
If we are talking about graphical applications, that would be a common usage.
My (limited) understanding is that you're describing an immediate mode GUI (as opposed to a retained GUI) and that one isn't strictly better than the other, but rather there are tradeoffs. In either case, I would be a little perturbed if implementing/using a retained mode GUI in Rust was prohibitively difficult even if immediate mode were strictly superior (the language probably shouldn't force such choices). Of course, I'm opining beyond my expertise, so I'm happy to be corrected.