Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 01, 2020 at 09:25:18AM -0400, Allen Winter wrote: > On Thursday, April 30, 2020 5:15:43 PM EDT Albert Astals Cid wrote: > > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va > > escriure: > > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić wrote: > > > > > > > > > We have made a big fuss in the past about having different projects > > > > > that do the same thing and now we'll have that but also we'll have > > > > > several projects with the same name? > > > > > It really feels off to me and I wonder if this is related to the move > > > > > to > > > > > gitlab. > > > > > > > > +1 to both sentiments - that projects should have different names and > > > > that > > > > this is a bit off topic for the gitlab migration. > > > > > > The projects *DO* have very different names. That *HAS NOT* changed. > > > To use the example Bhushan gave above, one is called Plasma Mobile > > > Dialer and the other one is called Maui Dialer. > > > > > > With the current git.kde.org setup, we have a flat namespace, so all > > > repositories if the name appears to be generic (as dialer is) have to > > > be namespaced by prefixing of the repository name. > > > > > > With Gitlab however we will now namespaces that group repositories, > > > making the prefixing unnecessary and as some projects have complained > > > about, duplicative. > > > > > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your > > > path, which just looks silly. > > > > Am I the only person that just has all the repos on the same folder? I > > thought it was the common thing to do :? > > > I use kdesrc-build and I see the repos in a hierarchy. > In particular, I like frameworks in frameworks in kdepim in kde/pim > > I don't see that I'm setting any special "layout in a hierarchy" option in my > kdesrc-buildrc So it's been a few months since we had switched the default, but since it's clearly an invasive change, the way we addressed it was to make the flat hierarchy a default for new users (who use either of the 'quick config' schemes like kdesrc-build-setup or kdesrc-build --initial-setup), but to leave the built-in default unchanged. So in essence, existing kdesrc-build users (who had a folder-based layout by default unless they went out of their way to find the right option) saw no change, but new users would have that option pre-set for them in the config. Regards, - Michael Pyne
Re: Notice of upcoming changes to the behaviour of the anongit network
On Sat, Apr 11, 2020 at 10:14:38PM +1200, Ben Cooksley wrote: > Hi all, > > As part of the preparations for the move to Gitlab, and the rewrite of > our anongit tooling, one of the things we have looked into is how the > anongit network in general operates. > > As part of this, it has been observed that the git:// protocol is > unencrypted, and thus vulnerable to intercept and manipulation by > hostile actors. > > We have therefore decided that support for the git:// protocol to > access KDE Git repositories will cease following our migration to > Gitlab. > > Going forward, all anonymous access should take place instead over > https, which is encrypted, and has the added benefit of offering > support for redirects (should those be needed) For kdesrc-build users, as Johan Ouwerkerk noted on the other Gitlab thread, kdesrc-build since January 2020 has already switched over to using https for KDE-based source repositories in anticipation of this change. Thanks to Ben and the sysadmin team for coordinating ahead of time on this, it's allowed us to have it deployed for 3 months now and we haven't heard of any breakage as a result of this change. One important note is that if you have any git repositories that you have manually checked out using KDE's anongit, you may need to either manually adjust it to use a https:// git remote (if it uses git:// now), or adjust it to use a kde: remote (as explained at https://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes). kdesrc-build configures git to understand this "kde:" prefix by default. Regards, - Michael Pyne
Re: Update on Status of Gitlab Migration
On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote: > On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley wrote: > > > > Yes, the hostname git.kde.org will be fully retired as part of this > > transition. > > > > From my understanding kdesrc-build will automatically pick this up > > once we update sysadmin/repo-metadata to show the new repository > > paths. > > This is something we'll confirm with mpyne though to ensure we can > > make the cutover as smooth as possible. > > > > Just to be clear, my understanding based on reading the > `Updated/Git.pm` module is that KDE repo paths are abstracted via > ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`. > Currently the code manipulates the user's ~/.gitconfig to bind the > correct mappings to the `kde:` prefix (this happens even before > cloning sysadmin repos for metadata). > > So if my understanding of the code is correct, the entire switch over > is transparent provided that kdesrc-build is updated beforehand to set > the updated value for `pushInsteadOf`. We already have the same > mechanism in place in kdesrc-build for ensuring that people use > https://anongit.kde.org instead of git://anongit.kde.org when > cloning/fetching. Yeah, when Ben asked me a couple of months back about it, this was the same conclusion I reached after reviewing the existing code. But I need to note that the way this works right now is that a module is cloned via a URL such as 'kde:juk' (not kde:kde/kdemultimedia/juk!). This is transparent to how git operates when setup with ~/.gitconfig, so you won't notice it in `git remote -v`, you need to actually look at the repository's .git/config, or run `git config --local --get remote.origin.url` in the source directory, to see whether it uses a kde: URL or a full URL. Either way, once the switchover happens, then *in theory* it can be as easy as running kdesrc-build once (to update ~/.gitconfig) and from there Git will rewrite to the updated URL automatically. We could add the switchover logic before that and guard it with a date check, that way we can do some testing early. > > Depending on how things look we may also make available a script that > > will update the configuration of a repository to reflect both the > > change in hostname as well as the change in path. > > > > A cleanup script could be handy. I think kdesrc-build will > automatically pick up new repo paths from metadata and that should > work transparently, but the old clones may get left behind as well. > People who use the kdesrc-build option to ignore KDE repo structure > shouldn't be affected at all. I don't know that we'll even necessarily need a cleanup script (though it couldn't hurt). In my case, my entire source repository contains only one repository directly referencing anongit (or git.kde.org), all others are non-KDE or kde: 1 git://anongit.kde.org/scratch/ 1 git://cmake.org/ 16 git://code.qt.io/ 1 git://git.freedesktop.org/ 1 git://git.gnupg.org/ 3 git://github.com/ 23 https://code.qt.io/ 7 https://github.com/ 1 https://gitlab.com/ 344 kde: All of the kde: repositories use the kde:foo syntax, where the 'foo' comes from the 'repopath' parameter of the sysadmin/repo-metadata YAML files. We may need to do on-the-fly conversion of the kde: repo paths if they won't be expressible as 'kde:foo' in the future, but we should have the information needed to do this in kdesrc-build to make this happen on-the-fly. Regards, - Michael Pyne
Re: Invent/gitlab, issues and bugzilla
On Thu, Jul 04, 2019 at 06:22:11AM +0300, Ilmari Lauhakangas wrote: > Nate Graham kirjoitti 3.7.2019 klo 21.23: > > On 7/3/19 11:53 AM, Albert Astals Cid wrote: > >> If the new is much better than the old, let's just remove the old. > >> > >> As said, having two things that do the same is just confusing for > >> everyone. > > > > I would tend to agree, and having two is super confusing. In general, > > people who have reported bugs on both Bugzilla and GitHub or GitLab seem > > to agree that Bugzilla's UX is inferior. However I don't believe we've > > officially trialed GitLab Issues and investigated what missing features > > need to be added before we can migrate to it. Maybe the time to do that > > is now, as a part of the general GitLab evaluation and migration period. > > > > Personally I find GitLab Issues to offer a vastly superior UX for bug > > reporting compared to Bugzilla. However the UX for bug management and > > triaging is not as granular. For example I still haven't figured out a > > way to create a saved search for "all Issues opened in the last 24 hours > > across all projects". And it would be nice to have some kind of overview > > similar to https://bugs.kde.org/weekly-bug-summary.cgi. > > The upcoming Bugzilla version 6 will have a vastly superior UX to BZ 5: > https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap > > With support from the BZ team, Kohei Yoshino has essentially solved BZ > UX (this includes drafting plans for the future) and I am immensely > grateful to him. > > The underlying functionality will remain superior to GitLabs and hubs as > it has been for years. I couldn't help but to notice that the feature plan you refer to, for how Bugzilla now has a superior UX drafting future feature plans than Gitlab/Github, is actually hosted in Github rather than Bugzilla. The irony is that BZ 6 really will have key features that will be handy for developers, especially around search. E.g. from the @BugzillaUX Twitter I see examples of a search for bugs fixed in $CURRENT_RELEASE [1] and a search for bugs fixed "this month" (i.e. relative date) [2]. All the same, Gitlab issue tracker is certainly good enough for most developers, more convenient for some developers, and better integrated into the rest of the workflows Gitlab would support (merge requests, quick actions from commit messages). As a personal example, I'd point to https://invent.kde.org/kde/kdesrc-build/issues/27 where Gitlab itself was able to recognize and link to the relevant merge request. Had I merged that exact MR to implement the issue, Gitlab would even have been able to automatically have closed the issue. With a bit more discipline I could have even done things like link to a specific milestone, but kdesrc-build isn't a large enough effort to warrant that level of detail. I'm not sure how to bridge that gap between small projects like mine vs. our larger efforts, but it seems to me that Gitlab is good enough for many of our projects, while Bugzilla remains preferable for projects that have high numbers of bugs to triage and sort through and developers willing to learn its more advanced capabilities. But the same thing that makes Bugzilla so powerful seems likely to continue to make it harder for new contributors (especially contributors used to a Github model) and so I'd be leery about making it a mandatory user touchpoint for projects that have adopted Gitlab, at least as it stands today. BZ 6 may improve this enough to make it feasible for new contributors and then it would "just" be a discussion about how much the potential integration benefits with the rest of Gitlab would be worth balanced against the large migration effort that would seem needed if we were to point users away from Bugzilla. Whatever we do, we should remain mindful of our goal to be able to onboard new contributors and I think those new contributors will come in more and more over time with a familiarity with the Github/Gitlab model and that we may have to find ways ourselves to adapt to that, even if it's nothing more than having a way to "incubate" new contributors in graduated steps to what we're using. Regards, - Michael Pyne [1] https://twitter.com/triagegirl/status/1134554219766112256 [2] https://twitter.com/triagegirl/status/1139278780881444864
Re: Fuzzy searching against KDE repositories
On Sun, May 06, 2018 at 06:04:24PM +0300, Dimitris Kardarakos wrote: > Hello everyone! > > Let me introduce you to a project that I am currently working on. > > The scope of the project is to provide an easy way to search KDE code > and translations repository since I consider that such a kind of an > infrastructure would help possible newcomers to easily obtain valuable > information about the work of the community. For example: > > To make the long story short, I was thinking that a google-like search > engine would facilitate onboarding of newcomers to KDE > > > Do you think that such a tool could help KDE community? I look forward > to hearing your thoughts, since I am not still convinced if working on > this would really help the KDE ecosystem. Dimitris, I personally think this would be very useful. Potentially to extend existing solutions like lxr.kde.org, or the custom hacks that I think a lot of KDE developers or contributors might have behind the scenes. I've had to search through commits before and in my case I'd added some support in kdesrc-build to output basic information about each repository so that I could automate some of those search... this tool would have completely eliminated the need for custom scripting on my end. As far as other work, if you limit that to just kde-commits mailing list then services like kde.markmail.org are out there, but I don't think their search is as powerful or as easy to use as the tooling you're using on this. Regards, - Michael Pyne
Re: Babe project - Legal feedback
On Sat, Feb 03, 2018 at 03:19:04PM -0500, Camilo Higuita Rodriguez wrote: > My case is the following, let's say that there's a feature for streaming > audio, and the users stream the song they are listening to, what would go > down in that case? Who's in legal troubles? > > Also if I were to send an mp3 over email to a few friends, where's the > illegal stand point there? The platform has some fault for allowing to > "distribute" the file? Or the user who emailed the content? This mail is more general advice, not directed exactly towards this question, but still I think it may be helpful. First, remember that to some extent, organizations based around delivering and building a software ecosystem based on Free software are inherently users and stakeholders in strong copyright, given the way our laws "protecting" intellectual work are structured. Concepts like "copyright" (in the form of copyleft), are what prevent private parties or companies from simply taking our Free software and making a private fork without sharing the source. Sometimes a private fork would be too much effort to go after (just like media companies don't try to enforce every license infringement they encounter), but for when it's not, we actually *need* copyright to be able to enforce license disputes. So it would be hypocritical for us to use copyright as the shield to defend our Free software ecosystem on one hand, but then ignore copyright when others are legitimately using it. Yes, there are other concerns, such as the nearly infinite extension of copyright that the big media companies seem able to achieve at will, but still -- it would be self-defeating to act as if we only weakly care about copyright, or even worse, only care when it serves our interests. Secondly, the debate between legal agency of a "platform" and the legal agency of a "platform user" is pretty much never that clear cut to be only on the user's side. Even here in the United States, where we have strong gun rights and mottos like "guns don't kill people, *people* kill people", there are still laws against the unrestricted sale or distribution of some types of guns or gun-related gear. So even our culture doesn't *completely* ignore the fact that the platform matters, even on issues like guns (and stronger weaponry, like bombs and explosives). And in cultures and societies that have stronger prohibitions against guns (i.e. pretty much all the other ones ;), the legal question is already slanted in favor of the idea that platforms matter, not just user action or intent. The NSA also makes similar justifications for their actions, saying that their surveillance actions (however icky) are conducted under a fully legal framework and that abuses are infrequent and due to "bad apple" users of their intelligence platform, not the existance of the platform itself. NSA's many detractors (many of whom come from communities like this one) tend to disagree, and say that the platform -- however technically legal -- is a problem just by being. So I guess all I'm trying to say is that even for us the right thing to do can legitimately be complicated, even without worrying about media lawyers. It /would/ be nice to be able to have 'virtual' parties with close friends without all having to be in the same room :), but getting there may be thorny. Regards, - Michael Pyne
Re: Bugzilla Update Staged: Testing Requested
On Sunday, October 23, 2016 4:34:39 PM EDT Ben Cooksley wrote: > If you find any issues it would be appreciated if you could let us know. I haven't found any issues in my testing to this point either. However the show_bug.cgi page seems to list a table to be used for estimating programmer workload in solving the bug (that is, when I'm logged in)... I'm not sure this is a good fit for our workflow, is it just a theme feature we can disable? Regards, - Michael Pyne
Re: [kde-community] "Fork Me" button within the kde git infrastructure?
On Mon, September 21, 2015 00:05:33 Jaroslaw Staniek wrote: > PS: Freedom of forking - derivative works is not so terrible, it's a > pilliar of FOSS. Last time I tried it, running git-clone against our KDE git infrastructure still worked just fine, and thus forking is quite easy to do. Did this change at some point? I haven't tried running Github's git import tool since it requires an account, but even their instructions for manually mirroring a git repo (for use with private repos) seem easy enough: https://help.github.com/articles/importing-a-git-repository-using-the-command-line/ Likewise for Bitbucket: https://confluence.atlassian.com/bitbucket/import-code-from-an-existing-project-259358821.html#Importcodefromanexistingproject-PushingaGitproject No one is arguing to *try* to make it more difficult to fork KDE or create derivative works... the "Trinity Desktop Environment" is still up and kicking, and others could be too with barely any work at all to setup the initial fork... Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Sat, September 19, 2015 16:24:13 Eike Hein wrote: > On 09/19/2015 02:12 PM, Myriam Schweingruber wrote: > > Some of you wanted the mirror on Github because apparently there are > > developers out there who are too lazy (or too dumb) to learn to use > > new tools. Are those developers we want? > > Developer recruitment should be our #1 problem for the > next two years, and along those lines "GitHub might get > us contributors" is by far the strongest argument that > side's come up with. Agreed, but yet, I'm not sure that it's really that strong. KDE is far too large (effectively its own ecosystem now) to rely on increased 'foot traffic' from new developers alone for recruiting. We would need a recruiting and *incubation* program of some sort, in my opinion... but we'll never get that without a good deal of investment of time and energy from our existing devs, and that is something we are perennially short of. Even the relatively-successful GSoC program, which is subsidized in great part by Google Inc., requires substantial (and unseen) effort behind the scenes by kde.org administrators and student mentors. With an improvement to recruiting/incubation then *maybe* increased attention by more active participation on Github would start to help... but on the other hand it could just as likely simply result in specific applications getting a recruiting boost from developers who'll never intend to help with KDE as a whole. Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Bikeshedding - our strength apparently *sigh*
On Sat, September 19, 2015 16:42:54 Riccardo Iaconelli wrote: > If somebody happened to send me some material for WikiToLearn through the > Facebook page (it has happened), I don't reject it asking him/her to resend > it to the mailing list, because that would never work. I accept the > material, thank the person, and point out they can also subscribe to the > mailing list, if they are interested to keep an eye on it. > > And this is exactly how we got one of our now most important contributors. > Did I loose my soul or my values? The project just grew stronger. Is anyone actually arguing this point in the way you ask? No one's asking to prevent "one offs" entirely, the core of the issue is that KDE development should happen *within* KDE-the-whole-community, not *apart from* KDE. The way we know best to do this is to prefer the use of the infrastructure we as a community have setup for that purpose, and to avoid diluting that infrastructure (which has its own positive network effects). If you've ever licensed software under a GPL instead of BSD license then you agree with the logic, even if you don't realize it's the same here. ;) Maybe there's a way to integrate pull requests into a KDE community workflow that meets the intent of what we're trying to do without subsuming the existing workflow completely (Github can't be allowed to subsume the whole deal because it's proprietary). But IMHO we're not at a stage where that's been clearly described how that could work. My personal feeling is that opting to go the actual-development-on-Github route would simply introduce a schism in development workflow, despite the best intentions of any party. And if you think *these* threads are filled with bikeshedding, just wait until that break occurs... ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] What is a GitHub pull request exactly?
On Sat, September 19, 2015 17:32:33 Kevin Krammer wrote: > So (a) and (b) workflows differ in that in (a) github mirror and git.kde.org > have the same state, while in (b) the mirror is for a period of time not > actually a mirror, but "ahead". > > Where "ahead" could also mean wrong if "klmn" needs to be modified or gets > rejected. > > Is (b) the problem people keep discussing about? Kevin, first off thanks for taking all the time to diagram this in an email! I think some of us are seeing this as simply an administrative or technical discussion of how we merge changes into git.kde.org in the presence of Github. I don't think it's really that at all, but instead a question of "where is the development happening" and "how is KDE [the community] staying involved/up-to- date with that development"? So I understand that from the perspective of "I already take patches by email, this is just another way of accepting new patches" this whole discussion might seem incredibly overdone. But there's another perspective of "how do we [KDE] ensure that our community values around common development are still maintained?", and that is the perspective from which many of us have questions. If the whole question were just a matter of s/emailed patch/pull request/ and *nothing else* I think I'd agree that there's no problem. The questions that are popping up are coming instead from trying to envision the next few steps out from "We started accepted pull requests on Github", i.e. the developer pressure on the rest of us to conform, "where will we do the code reviews", or the fear that development would naturally shift over to Github. Because after all if you can now contribute to KDE *just* by submitting pull requests on your Github fork, then why bother getting a KDE development account? This is something we didn't really have to worry about with Bugzilla or emailed-patches because no one's masochistic enough to sustain extended development that way. But on Github that workflow is already the default, it would be more work to go further and request a KDE identity. That wouldn't be a big problem for developers who were only going to toss us a patch or two anyways--no big loss in that department. But what about the developers might have joined but now see no need to? That would lead us, eventually, into one of two situations: a) Having to post developers to watch all of our Github mirrors and bring back pull requests, and eat the loss in possible KDE community contributors, and run the risk of increased reliance on Github infra for meaningful development. b) Having to move official development closer to Github itself to be closer to where the new developers are (with the same risk of reliance). There are ways around this, we could run concerted recruiting efforts to remind those submitting pull requests that there's a wider community behind the mirror and try to recruit that way, but that would have to be done *in concert* (and therefore, be discussed beforehand). And none of that addresses things like ensuring that review happens in spots available to the KDE community (are you **really** going to re-review a pull request that had been reviewed on Github over on reviewboard.kde.org? Every time? Same for every developer?). So when I say I'm opposed to this kind of thing it's not because I think the idea is completely stupid or that it's so off base, but rather that there *are* implications to this which we'd need to think through, especially in relation to the expected positive gain. It's not simply a flip the switch, allow pull requests, and it acts just like emailed patches... Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Official KDE mirror on github
On Fri, September 18, 2015 23:28:37 Vishesh Handa wrote: > On Fri, Sep 18, 2015 at 10:14 PM, Martin Graesslin <mgraess...@kde.org> wrote: > > So I join Sune, Eike and Marco: "Free software needs free tools, no > > proprietary pull requests for KDE development!" > > -1 > > I would prefer us to be more pragmatic. If an adequate free-software > tool exists, lets try to use it. If a proprietary tool provides a > better experience lets use that. The end result of that type of thought is something like what happened with BitKeeper. I'm not going to say it's impossible to use proprietary tools without having that type of drama occur, but I think it would be better if we just skipped to the part where we end up preferring a Free/open alternative to handle our critical tasks (as also happened with BitKeeper -> git). Besides which, it actually is *already* a general principle of KDE projects. There was no point going through all the work and community debate about what it should mean to be a "KDE project" if we were just going to walk away from those points when something more attractive came along. It should not be surprising that KDE developers advocate for something more than sheer pragmatism; if we were *only* pragmatic we could just recommend that people use Windows or Mac, no? There is at least value in consistency. It would confuse our users if they could report bugs one way with KFoo (utilizing support from Github) but couldn't report bugs the same way with KBar. It would impact our developers: remember that part of the ethos of being a "KDE project" is that the code is notionally open to *all* KDE developers. Are we supposed to canvass for bugs on both b.k.o and Github for some (but not all) "official" KDE repositories in the future? I agree it could be more convenient for an individual KDE app developer to allow this feature, but they are not the only stakeholder when discussing applications that form part of a "kde.org" release. Just my two cents... Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Updating TechBase Getting_Started pages
On Mon, August 17, 2015 09:53:58 John Layt wrote: Hi, I've started to update the old TechBase Getting_Started pages for the new KF5 world [1]. My aim is to teach the one simplest quickest way to build KF5 for new KDE contributors. There's a few key concepts I want this rewrite to follow: 1) There is only one way to do things, no giving alternatives 2) There is only KF5, no KDE4 3) There is only kdesrc-build, no manual messing around The three build scenarios (= new dev personas) that will be presented will be: 1) Build an app only using packaged Qt and KF5 2) Build Plasma only using packaged Qt and KF5 3) Build Frameworks using packaged Qt All the more detailed or historic information will be removed to other parts of TechBase [2]. New build instructions for external devs just wanting to use a Framework or two should also go here and not Getting_Started. This may result in some default build configs needing to be added to the kdesrc-build repo to make life easier. There may also need to be a couple of simple scripts to set-up kdesrc-build to start with, and to actually run things seeing as kdesrc-build doesn't. The less the new dev has to worry about the better. Thoughts? Is anyone else working on something similar? This has been sorely needed, and I've never quite had the time to bring kdesrc-buildrc-setup up to speed. But do let me know if there's things I should take *out* of kdesrc-build.git to make it easier, or some kind of feature that's sorely needed. Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Announcing the new KDE e.V. board
On Sun, September 7, 2014 10:59:49 Albert Astals Cid wrote: Dear community, Friday at the KDE e.V. general assembly we voted on new board members. In the evening we had our first board meeting over dinner and decided on the new roles. The new board is: Pradeepto Bhattacharya - board member Albert Astals Cid - board member Aleix Pol - vice president Marta Rybczynska - treasurer and vice president Lydia Pintscher - president A huge thank you goes to Cornelius for his 9 years of excellent work on the board and guiding us through the last years. Congrats to all, and I'd like to mirror the big THANK YOU to Cornelius for stepping up for nearly a decade of service for the KDE e.V. Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] licence policy updates
On Fri, February 14, 2014 10:31:24 Jonathan Riddell wrote: I've made some proposed changes to the KDE Licensing Policy http://techbase.kde.org/Policies/Licensing_Policy/Draft Most significant is the inclusion of GPL 3+ as an option in response to a request by GCompris and a desire voiced by a few people not to treat it as an exception. I was writing up a short draft guide on how to pick a license which got me to looking at our current FLA Relicensing Policy (v1.3.1, http://ev.kde.org/resources/FRP.pdf). Although it speaks to relicensing under the FLA process (the FLA form itself mentions GPL and LGPL without giving versions), it also gives a flat list of acceptable KDE licenses, split in license groups. AFAICS this is *the* list of permissible licenses as determined by the e.V. General Assembly, whether contributors adopt into the FLA or not. I noticed that GPLv3 *is* an acceptable license for non-library code, either GPLv3, GPLv3+, or GPLv3 w/ Qt exceptions. GPLv2 is certainly a valid option but it does not appear to be mandatory. The FRP also lists the Techbase Licensing Policy page as being informative, not normative (end of §2 on page 2). It seems to me that GCompris is already in license compliance and that we need merely update the Licensing Policy page to conform to the allowed licenses in the FRP. Please let me know if I'm missing something. Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] licence policy updates
On Sun, February 16, 2014 19:06:07 Lydia Pintscher wrote: On Sat, Feb 15, 2014 at 2:03 AM, Michael Pyne mp...@kde.org wrote: Perhaps something similar exists online as well. http://choosealicense.com/ (developed by github after people were annoyed that so much unlicensed code is hosted there) https://creativecommons.org/choose/ Thanks for the advice. I've prepared a rough draft of something that could probably be beaten into shape by a few of us. This is literally a *rough* draft, I've done just a little bit of research by looking at the FLA, FRP, and Licensing Policy pages, so it's certainly possible I'm not accurately stating a KDE position right. Should we get it smoothed out though it could probably be posted to community.kde.org (or similar) and referenced in our new contributor literature (assuming we have some! ;) Regards, - Michael Pyne --8-- # How to pick a copyright license for KDE source ## Purpose This guide is intended for the use of KDE contributors in selecting a license for new software in a way that helps the contributor meet their individual goals for the software, while keeping with the spirit of the KDE Project's purpose ... to promote the free exchange of knowledge and equality of opportunity in accessing software as well as education, science and research. (quoted from [the articles of association](http://ev.kde.org/whatiskdeev.php) of the KDE e.V.). The selection of an appropriate license is one of the more important decisions that a contributor can make with regard to the success of the software project, the KDE Project itself, and even the wider ecosystem of Free and open-source Software. Additionally, license selection is one of the first tasks that the contributor must complete, and becomes increasingly difficult to change (if needed) as more people contribute to the software in question. What that in mind, the KDE Project has prepared this guide to aid contributors in this process. ## KDE License Requirements KDE maintains a [list of acceptable software licenses](http://techbase.kde.org/Policies/Licensing_Policy), which you should briefly review before reading this guide. Of particular note: * The difference in emphasis on license requirements for software which is intended to form a library with a public API [Application Programming Interface] and for all other software (such as applications, simple widgets, etc.). * The availability of license options that may change with approval of the membership of the KDE e.V. (in other words, an agreement on your part, if you wish to permit it, to allow the KDE e.V. to relicense your software under certain terms). * The possibility of later adoption of your software into Qt (particularly for library code). * The possibility of later adoption of your software into Qt by someone other than yourself (which [requires](http://qt-project.org/legal.html) your software use LGPL *v2.1* as of this writing). The list of acceptable licenses for KDE software is chosen in order to meet multiple (and sometimes conflicting) goals: 1. Above all, maintaining a source base that guarantees the KDE Project's ability to deliver on its goal of developing software that can be freely examined, modified, and redistributed. 2. Maximizing the ability of individual contributors to make contributions to the KDE Project in a way that satisfies the contributor's concerns regarding the eventual use of their software. 3. Enabling cooperation and source code sharing within the wider community to the maximum extent possible, to ensure the overall health of Free and open-source Software. 4. Minimizing the license compliance workload of our downstream packagers, to the extent possible. 5. Maintaining the health of software essential to the overall KDE Project even when the current copyright owner is unavailable. ## Contributor Viewpoint Of course, the individual contributor has views and ideas of their own regarding the proper use and licensing of their contribution. Many types of contributors have made important contributions to the Project. * Some contributors care only that their software is as widely available as possible, and are willing to license permissively to make this happen. * Some contributors are concerned that their contribution is not adopted by a business and taken proprietary, and use a copyleft license to achieve this. * Some contributors share the same concern as above, with the exception of the Qt Project's commercial usage, and use copyleft licenses with specific exemptions for usage with the Qt libraries. * Some contributors want to ensure that their software is automatically protected from future threats to Free or open-source Software by pre-emptively granting licenses for future versions of the GNU General Public License (GPL) and/or Lesser General Public License (LGPL). * Some contributors want to ensure that their software can be used by the KDE
Re: [kde-community] licence policy updates
On Fri, February 14, 2014 20:34:51 Albert Astals Cid wrote: El Divendres, 14 de febrer de 2014, a les 10:31:24, Jonathan Riddell va escriure: I've made some proposed changes to the KDE Licensing Policy http://techbase.kde.org/Policies/Licensing_Policy/Draft Most significant is the inclusion of GPL 3+ as an option in response to a request by GCompris and a desire voiced by a few people not to treat it as an exception. Our current policy is designed to allow maxium code reuse around KDE and beyond, allowing GPL 3+ would mean some code could not be reused in GPL 2+ code without a relicence, but as pointed out this problem already happens when moving GPL 2 code to platform. The policy has nothing to do with whether GPL 2 or 3 is more or less commercially acceptable. Given a blank sheet I'd pick GPL 3 every time as it prevents DRM lock-in and patent abuse. Changes... #* '''GPL''' version 3 or later, where a KDE repository uses this it must be clearly marked by adding the full licence in a file called COPYING.GPL3 in the top directory of the repository ...and add GPL 3 headers Do you guys think that it would make sense to explicitely suggest that applications use the GPL version 2 or version 3 or later versions approved by the membership of KDE e.V. variant unless they really have special needs in aim to improve inter-app code shareability? That makes sense. In fact it would probably be a good idea to develop a How to Pick a License guide to help inform developers on *why* they'd pick a license, in addition to this document informing developers on *what* is appropriate to choose. This doesn't need to be directive policy of course, but presumably there is some type of license structure that we as a project would generally prefer for our developers to choose, all things being equal. The big thing I worry about is that figuring out what we thing would turn into a giant bikeshed discussion and I doubt any of us have time for that. :P Perhaps something similar exists online as well. Regards, - Michael Pyne ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
