I’ve been reusing my own About page and its components, let’s see if I switch to Opal instead 
I also have (somewhere…) a page to display the license text, would that fit in Opal?
3 Likes
And another one that I keep re-inventing, Docking widget.
I have a question about licensing.
The original Opal stuff has a mix of GPL3+ for code, and GFDL and CC for other stuff.
I added Components now, and more out of habit than anything else, that is currently under Apache-2.0.
I prefer permissive to GPL-style licenses, but that is not a very strong preference, and I’m fine to comply with any guidance wrt. Opal.
So:
- should contributions strive to use the same license for code (which would likely be GPL3+) in Opal?
- otherwise, are we Ok with ending up with a bunch of different licenses under the Opal umbrella? Could be a hassle for users of Opal modules.
- or a mix, dual-license things, i.e. whatever the original code had (assuming it’s brought over from an existing app), plus a common lic for distribution under Opal?
3 Likes
Although I prefer using the GPLv3, I think that given the aim of the project being to augment silica stuff, it makes more sense if we go permissive or at least GPLv2 ? 2 bits.
Oh, that would be really nice! Qt’s QML Charts would be worth looking into, I guess. We probably don’t have that on SFOS but maybe it could be ported / backported?
Noo, no, no, I don’t recall exactly how I did it but it’s a horrible hack and I’m afraid of looking at it ever again. Rain graphs are not working correctly for quite some time and I just hope that I don’t have to fix anything in the graphs itself…
Isn’t Nemo.Notifications doing that? Or do you mean in-app notifications? I think Jolla introduced something some time ago, the method that’s used in the clock app when setting an alarm. I didn’t see it in the docs though, last time I checked.
Yesss, please switch, I need actual users . License texts are already supported by Opal.About: if your app has Internet access, you can allow users to download them directly. You can also add your own short versions for specific licenses (the GPL “NO WARRANTIES” text is already included).
I think the only thing that is currently used on some “About” pages in the wild and that is not supported by Opal.About is email addresses for individual contributors. I tried many approaches but there’s no way to support links in a DetailItem.
Do you mean custom DockedPanels? I love your enthusiasm, and I really look forward to new modules! 
I decided against going permissive because I really don’t want my stuff ending up in some closed source walled garden (with the current Silica situation we’re already caught in one anyway…). It’s not only meant to augment Silica, rather it’s meant to support a growing copyleft ecosystem, and maybe someday Jolla feels compelled to open Silica.
That’s my rationale but I don’t set rules for other developers, as long as they use licenses that are free and compatible with the GPL. GPL has a tendency to make other things become GPL (here) but I’m mostly thinking of the green part in this list.
If it’s code that was ported over from another app, then that might be a good way to go. In other cases, I don’t really care as long as licenses are upwards compatible with GPLv3 because the apps I write are GPLv3.
@flypig asked me about that too, but this part didn’t make into the article:
- Why are there multiple licences? What does this mean in practice for developers?
Opal is built in the spirit of Free Software but there’s no policy as to what this means exactly for contributions: if you want to contribute a QML module under any free license (be it permissive or copyleft), you are invited to do so! The only requirement is strict reuse compliance, so that the licensing of all parts is clear.
In practice, this is mostly invisible to developers and users: if you are developing Free Software, then proper attribution is probably the only thing you have to be concerned about. This is where Opal.About comes in: you provide some details and a SPDX license ID, and the “About” page module generates the rest for you.
That being said, all things currently in Opal are mostly licensed under GPL, CC-BY-SA, or CC-0 (public domain).
So, to answer your questions:
I prefer GPLv3+ and I encourage everyone to do that too but I think it’s not too much of a hassle if a module uses a different free license. Modules come with their own Attribution components that can be included in the “About” page, and I think in most cases that’s all you have to think about.
But I’m absolutely no expert on licensing, so… please tell me what you think! (@poetaster I assume you know a thing or two about licensing?)
I’m kosher with GPLv3. It aligns with my goals. However, my goals do not, really, align with Jollas. Nevertherless I use Silica. Because I like the outcome. I haven’t gone into the details, but much of what I’m going DEPENDS on silica so I’m in a bit of a quandary. Should Opal components AVOID silica dependencies?
I’m also considering investing some time in getting all the apps I work on onto other platforms, but that’s another kettle of fish.
1 Like
I should qualify the aligns statement. I do a LOT of work to try to enhance the ecosystem FOR jolla. So, obviously, I have aims that explicitly include the welfare of Jolla. But I really detest the NDAs and the GPL fear. Embrace the dark side, I say. The doors to the dark side are ALWAYS open
1 Like
Yeah, I think we’re in the same boat… 
I think we desparately need something like the KDE Free Qt Foundation but with Sailfish/Silica/etc.
And it’s sooo much work, and it will make them ugly on all platforms while they would be beautiful on Sailfish. SFOS has such an individual “design language” that I don’t think it’s really possible to create apps that look good cross-platform…
Not sure if this was rhetorical, but no: Opal build on top of Silica and should aim to look good and provide high quality code for Sailfish. Unless it’s possible to avoid such a dependency without sacrificing anything, then let’s avoid it of course.
Maybe some work for the sailmates association? @jojo @vlagged Maybe some Opal project sponsoring?
I’m not sure because I haven’t looked at it hard enough, but it is possible to stay closer to Silica like guidelines for design outside Silica. The main problem is that compositing with ambiences get’s us unified appearance, which no one else does. I would miss that. The way it’s done in the cases I deal with (Fahrplan for instance) is completely separate QML for the different platforms. That means more work, but with careful design, not necessarily so much more. And I’m working bit by bit at refactoring to make that more likely. If I was able to get a number of apps running on IOs, for instance, I might actually be able to finance the work
Ok, that’s what I thought. But it means that the licenses could be a hindrance for use on Jolla’s side and that would be a bit sad if the work proves of wider utility. That was what I was getting at.
1 Like
Well I guess the idea of making a Theme for Kirigami, and a QT_QPA_PLATFORMTHEME for Qt5.15 to make apps using those more Sailfish-like could help there.
So you develop against Kirigami, and use the “native” theme for depending on target platform.
I at one point made a promise to look into that, and did a) choose a name for the theme, SiO2, and b) write about seven lines of code and then stopped. I do not yet understand enough of what’s to be done here. (Commits · nephros/qtquickcontrols2 · GitHub, Commits · nephros/qtquickcontrols2-packaging · GitHub)
1 Like
Erggg. Although I did get a couple of kde packages into chum, kaidan killed me. I will never do this kind of packaging again. BUT, that’s just because I’m not using docker as @rinigus is. If I were, I would probably have an easier time of it.
So were you stuck on a packaging issue?
No, just lack of direction (and interest ;), or “time to spend on hacking”). Hacking other apps seemed more rewarding.
qtquickcontrols2 where the theming lives was already packaged from the qt5.15 chum project. Haven’t looked at Kirigami at all yet. Also my main phone is still on 4.4 and getting Qt5.15 on there is a bit of a hassle, and it has graphics problems there.
Ok, got it. Stick to 4.4. The browser still works. sort of From an initial view (ktrip, I think) I didn’t come away thinking I would spend much time on kirigami.
I actually wanted to suggest that back when you guys were still planning the new organisation but then “real life” happened… I also think Sailmates should use gold doubloons if they sponsor things, would be fitting the theme 
(And of course I’d be open for something like that, I think it would make sense if the project gains traction.)
Well, my apps aren’t that carefully designed, I’m afraid . Building two different GUIs would be painful…
That is a really good idea! On the other hand, iOS has a very different approach to GUIs and you would definitely have to write everything twice. I don’t think theming like @nephros tried would be enough…
That hindrance is kinda the point, though. I’m working for a community, not for Jolla - if they want to use my code they can either employ/pay me, or they open up their code so that everyone benefits. That sounds a bit radical but to be honest I think it’s fair.
Of course that only applies to my code. I don’t want to pressure anyone to be that strict with their licensing when they’re working on Opal.
No, not really. Mostly just container classes/views. Obviously, using Theme and icon resources are something one has to avoid, but that can be done and still ‘fit’. But it takes some planning. At the moment I’m working backwards on that front. :_)
My take is that if opal produces enough value (lots of widgets. lots), then the value of the closed parts changes it’s value in proportion. But, if Jolla is keeping the licenses as is because of the mercedes benz entertainment system (a guess), then we are doomed
1 Like
Great job on starting this effort to consolidate useful components around our apps!.
I was not aware of this and I think it is fascinating (including the fact that they have two Trolltech advising members). For those who haven’t the time to read the whole page, sounds to me like it’s a legal agreement between the foundation and every Qt owner since 1998 Trolltech, to make sure that the Qt remains available and properly licensed…
I was going to say that maybe the first step to be in a similar situation would be to… well, have Silica “available and properly licenced”, and of course I found the Dec 2020 community meeting question and the answer… Maybe it needs a recurring community meeting question.
Regarding the ping:
We haven’t yet started acting with actual expenses from the membership fees and donations, but this should be on our radar and I’ll raise the point internally too. Maybe this also fits a potential funding application Sailmates can apply to.
(Personally I also had a couple of month of hiatus (“real life happens” +/- other SFOS related work) but I plan to get back on track shortly.)
(btw, Did you know you can just ping @sailmates for these kinds of ideas?)
2 Likes
Errr, as a member, I suppose I should have known
Exactly, and even though the Qt company regularly tries to get out of the deal (so they can make Qt fully commercial), they can’t - which is a great win for software freedom.
right you are… Maybe sailmates could do something about that?
NLnet just funded Whisperfish, maybe they are interested in other Sailfish things as well…
2 Likes
Now, that’s why I didn’t get any funding !
1 Like