It looked very promising but GPL for mobile iOS and Android Apps It is impossible, even I release the Apps free it is very difficult to work with GPL on those ecosystems. It is sad because it really looks very cool code.
Boden author here, a bit overwhelmed by the feedback. We are in the process of releasing a new version that will change the license to LGPL / Commercial.
LGPL has the same problem! Users must be able to relink an application with their own version of the LGPL library. This is impossible for almost all iOS scenarios and only very slightly easier on Android.
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.
The GPL is not compatible with Apple's App Store restrictions, so giving away your source code is not sufficient to comply with the GPL.
"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."
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?"
Maybe because some mega corp will figure out how to offer it as a service, and they'll get nothing for it. I support them defending themselves with a way to maybe make money on it. If they can't eat, they can't update the code.
So it's very conceivable that if your app is producing money for you, you don't want to open source the magic as it were - but if you're making money, you shouldn't expect a free ride.
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.
Please take the following with a grain of salt. I am not a legal expert, but we have competent US lawyers assessing this for us right now.
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.
LGPL 2.1 6c - on request, you provide the user with object code they can link against their custom version. Should be enough, if no other terms of the app store get in the way?
(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)
And how does the user then get their relinked app onto their phone?
(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.)
If the app is open source (or at least the source code is accessible), the user would proceed to the source repo, clone it, open the Xcode project and relink to the framework version of their choice.
Others have pointed out how it could work with closed source apps. It's a bit more complicated, but it certainly is possible.
It would be prudent to advertise this expectation of the app developer hoping to use the LGPL version. (Whereas with for instance the MPL and other licenses, no such need exists.)
Consider the Mozilla Public License (MPL) [1]. It is copyleft in the sense that modifications to the library must be MPL-licensed as well, but doesn't impose any restrictions on apps merely using the library. This avoids the LGPL’s complicated re-linking requirements which are very hard to fulfill for iOS apps (as mentioned elsewhere in this thread).
We have put a lot of effort into investigating and assessing different licensing options. There are two different perspectives on this: the user perspective where MIT of course seems to be among the most attractive ones at first glance. Then, there's the company perspective: what is the business model and how is development going to be sustainable in the long run?
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.
Apple's App Store licensing agreement allows you to distribute GPL v2 software. However, the GPL v2 license does not allow distribution under Apple's licensing terms.
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).
I don't quite understand this. The GPL gives the end user the rights to the source, to modify the source and to redistribute the software (modified or otherwise), as long as they make the source available. It doesn't say it has to be available through the exact same mechanism that you received the software in the first place, nor does it say that you have to release your changed software through the same mechanism. IANAL, so I definitely could be wrong, but as long as your GPL software links to the code, eg on Github or somewhere, and provides all of the source including your modifications there, any other restrictions the App Store enforces should be irrelevant to the GPL, right? (Unless the app store says you can't link to external source code, or something, of course)
The main difference between GPLv2 and v3 is the prevention of “TiVoization”. The background is that TiVo I believe was using the Linux kernel in their devices, and despite the fact that they were contributing their changes back to the community, they used code signing, or some other technical measure, to prevent end-users from running a custom version of the Linux kernel. So in reaction to this, GPLv3 was released that explicitly prohibits this behavior — that is, there must not be any technical measure preventing the user from using a modified version of the GPL’d software.
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.
> a user cannot download an app’s source, modify it, and use it on their device
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.
You have to refresh it every week or something though, right? At least last time I tried it (two years ago maybe?), the self signed apps needed to be re-signed after a short period of time. Fine for development and testing, not so great for actual real use.
Ok, so let's assume I was able to build the source and sign it without needing a Mac. Am I then able to run my newly signed program on my iPhone freely? Do I need to get it into the app store? Are there limitations to installing it directly to my phone?
Just trying to figure out where the incompatibility will the GPL is coming from.
So it's less about the common good and more about spiting companies (who are just never going to use this v3 code now so nothing was accomplished except wasting dev time on a global scale)
The GPL itself isn't about spiting companies or not, or even getting a particular piece of software more widely used by companies, it's about protecting the user freedoms whenever that software is used by anyone. v3 was developed because companies found an edge-case around one particular freedom with "Tivoization". The AGPL was developed because everyone found out about the edge-case of SaaS. The LGPL versions are there for when you want to compromise on the "infection" bit but not on the user freedoms of your bit.
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...
It depends on what you think is "the common good".
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.
Prisoner's dilemma imo. The second group only wins out here because other options exists. If everyone was forced to share all software ala GPLv3 with literally no other alternatives then we would see even more and better software everywhere (maybe).
You have good points and I guess you are not missing anything but Check the VLC case with the App store term of services, they pulled the app from the Store. It is really hard to deal with Apple. your app could be rejected and not accepted because it uses the GPL on it. Apple folks are scared of GPL.
Apple saying "you can't have GPL on the app store" is different from "you can't have GPL on app store because there are app store license things that conflict with GPL license things". Apple can restrict their store however they want, but I was wondering if the GPL itself is incompatible with the app store license (which is what the comment I replied to sounded like it was saying).
It's a really new project, so they're probably still figuring out what model works best and might want to limit the kind of deal they do - e.g. make sure it fits the client and they can support them with development where necessary. Freely selling licenses and then have unhappy customers that didn't evaluate the current state properly would be problematic.
Author here. We didn't expect so much attention and are happy about the feedback! Ask us anything.
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.
How will the license enforce that an app using an LGPL version of the library can't be sold? As such LGPL doesn't mean the consuming app has to be free.
Sorry, I should have written "apps conforming to the terms of the LGPL" instead of "free". Of course it's still possible to sell apps based on Boden licensed under LGPL as long as you comply with the license terms.
Is there then a business model in a commercial license for Boden if a company can use it as LGPL? In general are there many companies who pay for a commercial license to avoid LGPL?
The target audience seems very small. There’s lots of C# shops (Xamarin), and lots of JavaScript shops (React Native, Titanium), but few C++ shops that’d benefit from developing apps.
Maybe I’m wrong but the niche seems too small to be sustainable.
Funny you mention that. I primarily work with native mobile development and have grown fond of Flutter. Interestingly, the situation is reversed; shops will adopt Dart because of Flutter.
Except Angular Dart is alive and kicking, no? Powering AdSense at least which is a huge chunk of Google's business if I recall correctly from a Flutter talk by the PM who put some numbers on a slide.
This is different, Its not that c++ that people think from the 90's.
- 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.
From reading the iOS code there is already a number of bugs that will have issue, including but not limited to the iOS handling of text inputs. You won't get events / onchange firing correctly for autocorrections or when Chinese chars compact themselves. Seems like a very cool project anyway, there is a lot you could learn from react-native's approach to native components.
Edit: not to mention no support for text areas, will be interested to see that abstraction :)
I didn't look but I suspected such issues the moment they mentioned best practices and std::string in the same paragraph... It seems like it could be a fun project but I wonder who the target audience will be. Maybe they're working with a partner? I'm thinking for others it must be new startups just starting out, since every existing company I've seen that targets both platforms with native apps inevitably seems to split the codebases into iOS and Android sides because the platforms are sufficiently different. And of those companies a subset will have a shared C++ layer where it makes sense, probably with lots of cross platform issues already ironed out such that trying to drop in this would be too risky unless it matures into a really awesome project rather than its current preview release state... Best of luck to them.
It's cool to have options for x-platform development. I think we're at a solid 3 solutions: Boden (C++), Kotlin, and Xamarin (C#). Not to forget Unity and the JS solutions out there...
I am curious to know if this can also target a desktop toolkit such as gtk/qt/tk/wx and so on. I probably wouldn't want to use such an arrangement as a user, but I could see it being very useful as a developer for testing out app functionality without emulation or a separate device.
I also wonder if this will be able to target the puri.sm Librem 5 when that comes out?
There is already an experimental macOSX port in boden. More desktop support is a future goal. The library is designed to support all types of operating systems.
I did not see much, they just have a rudimentary wrapper for instantiating java classes, calling methods and retrieving objects in `bdn::java::wrapper::Class` which itself is a wrapper around JNI.
> 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.
Author of boden here: We have since moved away from a self written smart pointer and replaced as much as possible with standard C++ classes ( shared_ptr, weak_ptr, std::string etc. )
I don't speak C, but as a long-time web developer, it smells to me to see "Center" capitalized in the flexbox snippet. Why is it different than CSS? How is a developer supposed to understand the capitalization rules?
In C/C++ a common style is to use camelcase with an initial lower case letter for variable like things and with an initial upper case letter for constant or enumeration like things.
While I love C++, I can’t help but see this as the n-th iteration of the noble but impossible pursuit of a cross-platform GUI framework.
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 was exciting about trying an C++ IDE again after a few years of working in other languages. I tried VisualStudio for some simple C++ stuff (learning OpenGL with GLFW) and I found compilers and IDEs are still a pretty sluggish experience, all these years later.
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.
As the intro page demonstrates, modern C++ isn't really all that messy. I think there's a solid argument that it's a more dependable option than Dart, which isn't really used by anyone other than Google.
Better languages have moved beyond C++. I've developed software for over 20 years. I've use C++ for many of those years. Software languages and tools have evolved past C++.
Imagine the "evolution of man" drawing. C++ is the middle guy not exactly standing upright.
An "evolution of man" drawing wouldn't really be accurate because it implies each entry is static in terms of evolution. C++ is very obviously not, and modern C++ is barely recognizable compared to code written years ago.
I agree. All should choose their own languages and tools. The more competition in the marketplace the better. Hopefully the one you choose will have long term support, be accepted by industry and developers, deliver on the promised marketing, and have reasonable open source licenses. Anything else?
Handling callbacks without piles of Rc<RefCell<>> to access widget data, or having vectors simulating graphs, the most used data structure for UI widgets, having to deal with use-after-free indexes.
It sounds like you tried to write rust like it's OOP. You're gonna have a bad time if you do that.
>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.
I have experience with plenty of languages, including doing UI programming in Haskell, just to make your point.
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 don't think Rust has any one answer to a UI problem, since the UI story is basically the wild west right now. Everyone is doing something a little different.
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.
Ah ok had to skim through the slides a bit, I think you meant to use the phrase "generational indexes" which is why googling didn't help me. This project was more helpful for my understanding:
> 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.
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.
I'm definitely no GUI framework expert, but I didn't necessarily mean to imply an immediate mode architecture. Personally I've been writing a lot of code that way in retained mode frameworks. There's some duplication of data but it's not a huge deal when a widget's state is just single variant, which covers just about all I need.
>> 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.
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.
Qt isn't using native elements, and their mobile support is usable but not really great either (and doesn't appear to be a current priority, which makes a mobile-only project potentially more attractive). I'm not sure I'd use it if I didn't have existing Qt experience or even code to reuse.
