Re: Licensing for models and datasets
There is also this document by Debian's Deep Learning Team that is worth looking at: https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.rst There they make a distinction between model and its artifacts and if model is non-free or trained on non-free data, then they consider its output artifacts to be proprietary. Andrius 2024 m. kovo 26 d., antradienis 16:33:56 GMT Volker Krause rašė: > On Montag, 25. März 2024 15:17:48 CET Halla Rempt wrote: > > We're looking into adding an experimental AI-based feature to Krita: > > automated inking. That gives us three components, and we're not sure about > > the license we should use for two of them: the model and the datase. Would > > CC be best here? > > Looking at https://community.kde.org/Policies/Licensing_Policy the closest > thing would either be "media" files (generalized to "data files") and thus > CC- BY-SA (and presumably CC-BY/CC0) or "source code" (xGPL, BSD/MIT). > > I think this is a bit more tricky though, depending on whether we assume a > model is derivative work of the input data, and whether the output generated > from a model is derivative work of the model (and thus potentially > derivative work of the input data). The industry assumption so far seems to > be that at least one of those isn't derivative work (AFAIK that has yet to > be legally tested though), but I'm not sure that interpretation is in the > best interest of FOSS developers or artists... > > One scenario that would work regardless I think is using a license with > practically no constraints (CC0, MIT, etc), but that also offers no > protection for the training or model data (which might or might not be what > you want). > > Any other scenario I can think of involving more protective licenses runs > into interesting issues: > - if the output is derivative work, Krita users would be bound by e.g. the > attribution or share-alike requirements of the license (which I guess is not > what you want). > - a Bison/Flex style "code generator exception" to state that the model > output is free of any license requirements regardless of the model license > itself requires that either the model isn't derivative work of the input or > that the input data is licensed in a way compatible with that. > - In the latter case we are back to essentially unprotected CC0-like input, > or a protective license with a special exception, which then gets awfully > close to developing new licenses. > > So I guess this boils down to how much protection you have in mind for the > input and model data? > > Interesting topic, sorry if my ramblings on this are of limited help :) > > Regards, > Volker
Re: Does KDE have a policy for shipping libraries licensed under the Apache license?
Hi, Quick check seems to indicate that KDE Connect license is: *GPL-2.0-only* OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL Apache v2 licensed code is not compatible with GPL-2.0-only but is compatible with GPLv3. So by combining KDE Conenct with that library you lose right to redistribute the whole thing as GPL2 but you still have the right to redistribute combined code under GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL I.e. you are essentially dropping GPLv2 support and only keeping GPLv3. So you must first check that you have no GPLv2 only dependencies. Kind regards, Andrius 2022 m. gruodžio 19 d., pirmadienis 23:34:11 CET Simon Redman rašė: > KDE Connect has had this PR languishing for a couple of years, with a > question I am not able to answer. > https://invent.kde.org/network/kdeconnect-android/-/merge_requests/192 > > The author has added a (very useful) library, which happens to be > licensed under the Apache v2 license. > > KDE Connect code is GPL-licensed. GPL section 2 says that the entire > work must be distributed as GPL. > https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html > > In my eyes, the only meaningful part of the work is the source code, at > which level the concept of distributing a library does not apply. The > .apk that we give to users is just a convenience to them, they could > just as well build it themselves. The .apk contains both the KDE Connect > GPL code and the Apache-licensed libraries, but by itself has no > specific license (and doesn't claim to). > > But my view don't matter, what matters is what happens in court, in the > event anyone ever accuses KDE of violating license terms. As I am not > qualified to expose KDE to any additional risk, is there a policy (or > accepted precedent) for distributing Apache-licensed libraries? > > Thanks, > Simon >
Re: Gitlab update, 2FA now mandatory
2022 m. spalio 24 d., pirmadienis 00:16:30 BST Jack rašė: > On 2022.10.23 02:32, Ben Cooksley wrote: > > Hi all, > > > > This afternoon I updated invent.kde.org to the latest version of > > Gitlab, > > 15.5. > > Release notes for this can be found at > > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/ > > > > There isn't much notable feature wise in this release, however there > > have > > been some bug fixes surrounding the "Rebase without Pipeline" > > functionality that was introduced in an earlier update. > > > > As part of securing Invent against recently detected suspicious > > activity I > > have also enabled Mandatory 2FA, which Gitlab will ask you to > > configure > > next time you access it. This can be done using either a Webauthn > > token > > (such as a Yubikey) or TOTP (using the app of choice on your phone) > > > > Should you lose access to your 2FA device you can obtain a recovery > > token > > to log back in via SSH, see > > https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh > > for more details on this. > > > > Please let us know if there are any queries on the above. > > > > Thanks, > > Ben > Sorry to be dense, but without a webauthn token device, it seems I'm at > a total block if I don't have a phone (or don't have it with me.) Is > that correct, or is there some fine manual I need to read? > > Thanks. > > Jack > Hi, You can actually made webauthn token device yourself if you are willing to do a bit of work. You can buy a couple of ST-Link V2 debuggers for a few euros, use one of them to reflash another with U2F firmware (e.g. https://github.com/gl-sergei/u2f-token) and then register it in Gitlab. Kind regards, Andrius signature.asc Description: This is a digitally signed message part.
Re: Akademy 2022 Covid-19 Mitigation
N95 is roughly equivalent level of protection as FFP2, so should be fine. One is US standard and the other is European. (FFP3 corresponds to N99). 2022 m. liepos 5 d., antradienis 14:34:12 BST Neal Gompa rašė: > On Tue, Jul 5, 2022 at 7:49 AM Kenny Duffus wrote: > > > > Hi > > > > Akademy 2022 is a hybrid event. Everyone can attend online > > > > For the safety of everyone there, those attending in person will need to > > wear an FFP2/3 mask at all times and in all areas of the venue where we are > > having Akademy. We will be providing some free masks as well. > > > > This is our baseline level that we will not be going below so that you can > > plan whether or not you feel it is safe to attend. If circumstances worsen > > we may also need to put in place additional measures that we will notify as > > early as possible. > > > > There may be some venue staff in the common areas that we don't have > > control over who may or may not be wearing masks. > > > > Details of registration to Attend Akademy, either online or in person, can > > be found on https://akademy.kde.org/2022/register > > > > I mostly have N95 masks myself, as that's all I can acquire here. Can > those be acceptable too? > > > > signature.asc Description: This is a digitally signed message part.
Re: Amor Build Instructions
2022 m. vasario 8 d., antradienis 22:07:17 GMT Aaron Franke rašė: > Here are the build instructions that I figured out, verified to work on > Ubuntu 20.04 and Linux Mint 20.3: > > sudo apt install build-essential cmake extra-cmake-modules > libqt5x11extras5-dev libkf5doctools-dev libkf5dbusaddons-dev > libkf5coreaddons-dev libkf5i18n-dev libkf5config-dev libkf5windowsystem-dev > libkf5xmlgui-dev > cmake CMakeLists.txt > make > sudo make install And what about other folks who are not on Ubuntu based distros and don't have apt? We do have a wiki page about building KDE software in general, not just Amor: https://community.kde.org/Get_Involved/development And can't you just do apt install build-dep amor on ubuntu instead of gathering that list manually Andrius signature.asc Description: This is a digitally signed message part.
Re: The status of freenode (the IRC network used by KDE)
2021 m. birželio 16 d., trečiadienis 17:10:42 BST Kenny Duffus rašė: > On Tuesday, 15 June 2021 14:59:09 BST Kenny Duffus wrote: > > On matrix we have a large number of users and the issues of aliases which > > complicates stuff, so that is why we are choosing to migrate them. Just be > > patient a bit longer > > > > That is now all of the simple ones migrated to libera and some of the bigger > rooms are in progress as they need the bridge admin to link them > > I'm now going to look through the various errors and get the remainder sorted > > Just to note again that if @kenny:kde.org is not in your bridged room we > probably don't know of its existence, so please invite me to your rooms > > Thanks to EMS for all their work helping us > > Thank you Kenny for looking at this too! Hopefully, we'll soon be able to return back to normal. signature.asc Description: This is a digitally signed message part.
Re: The status of freenode (the IRC network used by KDE)
2021 m. birželio 15 d., antradienis 14:25:11 BST Kenny Duffus rašė: > Hi > > We had been trying to have a nice orderly migration from freenode but that > wasn't to be despite all our work as freenode imploded earlier today > > The main problem for our migration was that the majority of our matrix > bridged rooms are "portals" which aren't really meant to ever move > > Element Matrix Services support are working with us to convert the portal > rooms to plumbed rooms which we can then migrate > > Existing plumbed rooms can skip this stage and be unlinked from freenode and > using the integration manager add an irc bridge to libera to them instead > > If you are in a kde matrix room that i'm not please invite me there so that i > definitely know of its existance, I'm @kenny:kde.org > > For people using IRC directly life should be simpler, you can just disconect > from freenode if you haven't and then join the corresponding rooms on Libera > https://libera.chat/guides/connect > > The vast majority of IRC rooms have been created and registered, if you find > any that aren't please let me know (seaLne) > > Thanks > > Hi, Given the imposion today, can we not just close old matrix rooms with m.room.tombstone and point them to new rooms linked to Libera? In the short term that might be a bit disruptive because matrix users will have to switch to new rooms. But it we keep waiting too long we might end up in a bigger mess. And at least IRC users showed that they are capable of switching servers, so maybe we shouldn't assume that matrix users are less capable. Personally, KDE rooms are the only ones I still have to use on Freenode. Andrius signature.asc Description: This is a digitally signed message part.
Re: is a BSL licensed service acceptable for sysadminy use cases?
2021 m. gegužės 28 d., penktadienis 11:25:49 BST Harald Sitter rašė: > On Fri, May 28, 2021 at 11:43 AM Sune Vuorela wrote: > > > > On 2021-05-26, Anna “CyberTailor” wrote: > > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion > > >> period) > > > > > > So you can use old sentry versions, which are open source. > > > > > > > +1. I think we should support free and open source software. > > I do too. I'm curious though: How does using the 4 year old software > support the software more than using the eventually 4 year old > software? > > HS > By the way, isn't it 3 year old software. That probably doesn't fundamentally change the discussion. Although, if you use Debian stable or Centos, you probably are using a lot of 3 year old software. signature.asc Description: This is a digitally signed message part.
