Re: Licensing for models and datasets
On 26.03.24 17:33, Volker Krause wrote: 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 don't think we can directly use the current licensing policy for ML models and datasets. But I suppose we should discuss extending it to cover these use cases as well. CC-BY or CC-BY-SA are not the best choice for data as their attribution requirements can make it impractical to work with data under these licenses. There are some good arguments why data should rather not be licensed at all (https://plus.pli.edu/Details/Details?fq=id:(352066-ATL2)). This would suggest to use CC0 as closest practical form of it. For models, attribution requirements seem to be less of an issue. But as Volker described the copyright situation is quite complicated and it's not clear yet, what consequences this will have in the future. From this point of view a permissive license could a good choice as it is likely to not create problems in the future. As the MIT is already mentioned in the licensing policy, maybe this is the best choice? In addition to the licensing itself it could also be good to consider how to convey more information about the openness of the system. Even if it wouldn't make a difference in terms of copyright for the user of a model, it still might be preferable to use models which are trained on free and open data. Some kind of labeling and making this transparent to end users could be a solution to that. In the context of the Sustainable Software goal we have a bit of discussion around the labeling. There are some ongoing efforts, such as OSI's attempt to define what Open AI actually should mean (https://opensource.org/deepdive), or Nextcloud's Ethical AI labeling system (https://nextcloud.com/blog/nextcloud-ethical-ai-rating/). Maybe it would be worth thinking about adopting something like that in KDE as well. Who would be interested to discuss this? We have it on the agenda for the upcoming Goals sprint end of April, but it might be worth extending this discussion if there is broader interest. -- Cornelius Schumacher
Re: Copyright years (and minimizing the burden on developers and maintainers)
On 04.02.23 20:58, Toni Asensi Esteve wrote: Do you think that changing and reviewing too many changes every year is worth it? What do you think that would be better? Another perspective is this: https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code. Matija suggests to add the year once as the year of file creation, but not change it afterwards. -- Cornelius Schumacher
Re: KDE Apps name trademarks
On Wednesday, 22 July 2020 09:53:58 CEST Uli Klinkhammer wrote: > > So, do we need those use cases and rights? Or is it better maybe, like > Martin said, to speak with people violating our rights? (that are > naturally given by using those names) Or is registering a domain name > for every application an alternative? We have the rights on the names of our applications, also without corresponding domain names, so there is probably no need to register additional domains. Keeps things more simple :-) Speaking to people who we consider to violate our rights is always a good idea. We would need to do that anyway and it's often enough to resolve these kind of issues without the need to take formal legal steps. This should be a last resort. In any case it helps if we can point people to a written policy which makes it clear how we expect our trademarks to be used, what we consider to be acceptable and what not. -- Cornelius Schumacher
Re: KDE Apps name trademarks
On Monday, 20 July 2020 12:55:25 CEST Albert Vaca Cintora wrote: > > I think we should be happy there are packagers that distribute our software > on Windows, the same way we are happy there are packages distributing our > software on Linux distros. Yes. The copyright licenses allow distribution of our software. We support that. We do want to have a community of distributors who are getting our software to end users. The trademark should not get in the way here. So our trademark policy should be open and allow and support these cases. What we don't want is confusion about where the software is coming from. It should be clear if something is coming from us or from a third party. In the case of Linux distributors this is very clear, there is no issue there. In the case of mobile apps that can be more problematic because there is less transparency there. That's something we probably should clarify in a trademark policy. -- Cornelius Schumacher
Re: KDE Apps name trademarks
On Sonntag, 12. Juli 2020 22:45:17 CEST Jonathan Riddell wrote: > > My proposal would be to trademark all app names since they are all liable > to be hijacked by third parties for whatever purposes. It would mean > adding a ™ symbol on web pages where we promote those apps. They would be > owned by KDE e.v. Other apps like KOffice have done this in the past as I > say. However it seems nobody is very much in suppose of the idea so we'll > just have to live with third parties living off our good names. I think this needs some clarification. First of all, a trademark is established by starting to use it. We own the trademarks of KDE application names, because we use them to designate our applications. Adding a TM symbol might have informational value, but is has no direct legal consequences. It's not necessary to trademark our apps by adding some symbol. We already have done that by giving them the names they have and using them as our marks. The missing piece here is a trademark policy. We need to define how and under which circumstances our trademarks can be used. This is a balance act as we want them to be used widely, but we also need to defend them to prevent abuse. This is a bit tricky as trademark law is not made for openly used marks. Still, by defining clear conditions we can set out how we want them to be used. . One critical part of this trademark policy would be what "we" actually means. Who owns the trademarks? By default, the people who start using them, own them. In our case we want this to be owned by the community, so we need to establish a process to make KDE e.V. the owner of the KDE trademarks. In some cases, such as KOffice, this has happened in the past in a somewhat informal way, but to have clarity, it probably would be best to have a formal process. Then, as an additional step, there is registration of trademarks. This actually makes a difference from a legal point of view. It makes the mark more defendable. It is some paperwork and costs some money, and it has done separately for different regions of the world. In short, it is significant effort. We have done this for KDE as a general mark. We haven't done it for app names. Which is probably ok, because we do own the trademarks we use, also without registration. So I don't think we should add the TM symbol everywhere. This would be quite some effort, and it might even be counter-productive if not done consistently. But if there are situations where third parties are living off our good name, we should fight this. We already have the rights to do so. The most important thing, though, would be to formulate our trademark policy so we have a clear base to operate from for now and the future. We should look at the trademark policies of other projects and use them as inspiration and maybe something like a template. -- Cornelius Schumacher
Re: Proposal: Allow REUSE compatible License Statements in License Policy
On Dienstag, 7. Januar 2020 06:33:11 CET Andreas Cord-Landwehr wrote: > > Regarding the license statements for the "accecpted by KDE" clause: My main > motivation was to introduce a workaround with some licensing mixups we have > in our repositories. For example (there are many more, these are only the > first in my list): > - LGPL-2.0-only OR LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL: > https://github.com/KDE/kio/blob/master/autotests/kfilecopytomenutest.cpp > - LGPL-2.1-only OR LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL: > https://github.com/KDE/attica/blob/master/src/projectparser.cpp > So, there are two LGPL based licenses with the same accepted-by-KDE clause, > which relies on the LGPL-3 clause for defining a proxy. Yet, they state > different LGPL-2.* versions, once LGPL-2.0-only and once LGPL-2.1-only. The > KDE clause -- in my opinion -- does not need this distinction, as it only > relates to the LGPL-3 version for defining is meaning. > So another option would be to define that later versions of the LGPL-3.0 are > meant. This should not change any meaning of the current license > statements. What do you think? Are there really that many different combinations with the KDE exception? Is there more than * LGPL-2.0-only OR LGPL 3.0-only OR LicenseRef * LGPL-2.1-only OR LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL * LGPL 3.0-only OR LicenseRef-KDE-Accepted-LGPL for LGPL and * GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL * GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL for GPL? Your suggestion to specify the LicenseRef with the 3.0 versions as reference makes sense in any case, I think, assuming that this is in all combinations and it gives a clear and well-defined meaning for the versions, which matches the current license headers when combined with the ORed other versions. > Regarding the second point: I fully agree and will do this. And I want to do > this together with examples how to state the licenses correctly. However, I > think, stating the examples for REUSE compatible license usage should best > be put on a separate wiki page for better readability. Great, makes sense to me. -- Cornelius Schumacher
Re: Proposal: Allow REUSE compatible License Statements in License Policy
On Sunday, 5 January 2020 16:40:20 CET Andreas Cord-Landwehr wrote: > Hi, I want to propose to allow SPDX-based [5] and REUSE.software [1] > compatible license statements as a new option in our KDE licensing policy. This is great. Thanks for working on this. Very nicely done. > Here is my policy update proposal: > * Proposal: > https://community.kde.org/Policies/Licensing_Policy/Draft_SPDX_v2 * Diff to > current policy: https://community.kde.org/index.php? > title=Policies%2FLicensing_Policy%2FDraft_SPDX_v2=revision=87138 > ldid=87134 > > I would be very happy to receive feedback if this proposal goes into the > right direction and if we shall go forward this way. Also (mostly for the > legal experts), I would be glad if you could carefully read the > LicenseRef-KDE- Accepted-LGPL and LicenseRef-KDE-Accepted-GPL statements > and give me feedback. Those are based on our current license statements but > try to better integrate with the SPDX based license statements. In general I think the proposal makes a lot of sense. It definitely is going into the right direction. Regarding the LicenseRef-KDE-Accepted-(L)GPL texts: * What's the exact reasons for changing them compared to our current license statements? I tend to think it's better to keep them as they are and leave the versions in. Otherwise they are missing the reference to what "later" is relative to. * The texts are not meant to be used as license headers in source files but as stand-alone files, so the refeence in a SPDX identifier such as "LGPL-2.1-only OR LGPL-3.0-only OR LicenseRef-KDE-Accepted-LGPL" can be resolved. Maybe that could be made more explicit in the policy. Maybe by moving them to the end as an appendix with an explanation how these are to be stored as files according to SPDX and REUSE conventions. Then the LicenseRef* identifiers in the bullet points in the policy could maybe also turned into hyperlinks pointing to these sections in the appendix. It would also be nice to have examples for license headers which don't use the full text of the headers but only the SPDX identifiers as specified by REUSE. This is the more concise version and I think the one we would like to settle on longer term. So it would be good to have explicit examples which show how this will look like. That could be a later step, though. -- Cornelius Schumacher
Re: Licensing policy change proposal
On Sonntag, 27. Januar 2019 21:14:10 CET Mirko Boehm wrote: > > I need to point out that CC0 licenses are problematic in many jurisdictions, > as there is no simple way to dedicate a work to the public domain. The > correct way in for example France or Germany would be to use a permissive > FOSS license. Let us avoid the mine field of public domain. Isn't the CC0 license the attempt to solve the issues of the term "public domain" across jurisdictions and provide a license which works as what people expect from public domain? What are the issues of public domain that CC0 doesn't solve? -- Cornelius Schumacher
Re: Nominate key KDE frameworks and packages for inclusion in the OIN Linux System Definition
On Mittwoch, 29. August 2018 18:53:39 CEST Mirko Boehm wrote: > > KDE software is covered in the definition, but not in the latest version. > KDE 3 and 4 packages are included. I would like to see the KDE frameworks > and key shared libraries included. The system definition includes reusable > components, applications (“leafs” of the dependency tree) are usually not > included. The Linux System is updated every 18-24 months. We just finished > one round of updates, so now is a good time to think about nominating > updates to the latest versions of “legacy" KDE packages, and nominating new > packages for inclusion. Agreed. Let's get this updated. > I am looking for somebody in the community to act as a “champion” for these > nominations. Since I am involved in the review process in a stewardship > role, I cannot also act as the nominator. The job entails working with the > community to select the packages, put them all together in a spreadsheet, > and then working with the OIN tech committee until the nomination is > accepted. This needs to be completed by roughly mid 2019. > > Who wants to work with me on that? I'm happy to do that. I'm generating this kind of data for inqlude.org already, so extending it for the use in OIN won't be too difficult. -- Cornelius Schumacher
Re: Improving our integration with KDE application teams, and supporting companies
On Montag, 20. August 2018 00:30:37 CEST Thomas Pfeiffer wrote: > > Interestingly, in almost all conversations I had at Akademy about this > topic, people were actually very positive about the prospect of growing an > ecosystem of companies around KDE. Maybe it's the difference between the > people who are still active and want to see people spend paid time on KDE, > and those who are mostly watching KDE from the sidelines and want to go > back to "the good old timeṣ"™ when KDE was just a bunch of enthusiastic > geeks who wanted to change the world as a hobby. As one of the people who is more on the sidelines now but has seen the "good old times" I can say that I don't think what you are describing is the issue. We always had paid people working on KDE. I would even say we had more paid people in the past. The distributions were much more involved at the beginning and we had projects such as all the work around Kolab which had many paid people working on KDE full-time. I don't think that anybody has a problem with having a healthy ecosystem of companies around KDE. That's not the debate we are having. > For those people who claim that having paid people work on a Free Software > project will inevitably kill all motivation for volunteers, let's look at > some examples within or close to KDE: We need to get clear on what we are debating. It's not that paid people are a problem. It's about how this is done and who is paying them. We have a very conscious standing decision that KDE e.V. does not pay developers. This clearly separates paid and volunteer work there so that there can be no issue with harming volunteer motivation. We might want to revisit this decision but would need to be very clear about the governance of this work. In the cases where people are paid by companies we have a clear governance structure, the company decides, and it's very clear how you can get paid, by becoming hired by the company. This is much less prone to conflicts than if the organization which is mostly representing the volunteers is paying people. We have seen unsuccessful attempts in the past such as bounty programs which did more harm than good. That's something we can learn from. We also have made some experience such as with the Kolab project where a lot of good community work was done by paid people, but in the process of the project basically all volunteers turned into paid people. When the project was done this left the community with a painful lack of developers, as neither paid people nor volunteers were there anymore. We have to consider such situations as well. It would be good if we can have a rational debate about how we make best use of paid work in KDE. I have the feeling that some emotions are in the way of actually discussing the real questions. Let's put them aside for now and talk actual business. -- Cornelius Schumacher
Re: Sysadmin notice: static website generation revamped
On Sonntag, 27. Mai 2018 09:59:35 CEST Bhushan Shah wrote: > > To fix this, we have come up with docker image with LTS ubuntu 16.04 and > we are now running the website generation on binary factory [1]. This is sweet. Thanks for the update. > If you spot any regressions with this websites, please feel free to reach > to us through sysadmin ticket. I see an issue with inqlude.org. I'll open a ticket. -- Cornelius Schumacher <schumac...@kde.org>
Re: Happy 20th Birthday, KDE!
On Friday 14 October 2016 10:47:56 Lydia Pintscher wrote: > > Today is KDE's 20th birthday. I'm proud of all the things we've > achieved since Matthias sent his announcement email 20 years ago > today. I've written a short text for the dot here: > https://dot.kde.org/2016/10/14/happy-20th-birthday-kde I'd love to see > many personal reflections from all of you on PlanetKDE. Mine is here: http://blog.cornelius-schumacher.de/2016/10/twenty-years-of-kde.html > I want to take the time to ask us all 2 questions: What are you most > proud of in KDE? What are you most excited about in KDE right now? I'm most proud of having achieved the goal of having a free software desktop I (and many others) can use every day for my personal and professional life. I usually don't compile my desktop myself anymore, but it feels so good to be able to do so. I'm most excited about all the fresh contributors joining the community. Students who come through the summer of code, projects like the amazing WikiToLearn, or new people wherever they come from. KDE is an amazing community. -- Cornelius Schumacher <schumac...@kde.org>
Re: [kde-community] KDE Wiki Organisation
On Mittwoch, 9. März 2016 11:20:50 CET Alex Merry wrote: > > We have outlines of how the wikis will be laid out internally, which > will be documented in Help:Structure pages on the wikis. Community won't > change much, other than gaining some new top-level sections from > TechBase. TechBase will change substantially, becoming more > product-based, so you can easily search for information on Frameworks, > or Plasma, or Marble, or what have you, and kdelibs4-based information > can be kept with a clear separation from Frameworks, for example. Thanks for sorting this out. I think this is a valuable and important step. Will you update http://wiki.kde.org as well to reflect what you decided about the structure? -- Cornelius Schumacher <schumac...@kde.org> ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - second draft for discussion
On Tuesday 23 February 2016 22:46:56 Stephen Kelly wrote: > > This is just my understanding that I've encountered as a result of reading > what Ingo wrote and comparing with the website list. I know others have > different understandings, but I wanted to be specific about what insights > I'm thanking Ingo for! I like the direction. Thank you for writing this up. It expresses pretty much exactly what I'm thinking as well. I like the direction very much. -- Cornelius Schumacher <schumac...@kde.org> ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - first draft for discussion
On Monday 08 February 2016 12:16:41 Sebastian Kügler wrote: > On Friday, February 05, 2016 05:00:28 PM Ingo Klöcker wrote: > > > > So, how about > > "KDE enables everyone to control their digital life without compromising > > their privacy." > > That's getting really catchy! > > Really useful feedback, thanks Ingo. I agree with the points you make. Same here. This is what is resonating most with me from what I have seen in this thread. Thanks, Ingo. It captures what I perceive as the common ground of what we want to reach. The exact wording could maybe be improved. But it has the right element. "enables everyone" expresses that we are giving people access to technology, that we break down barriers, that we imagine a world where software freedom is the norm. "control their digital life" captures the end user target and that it is about giving control to people. Again something which goes very well with the ideals of free software, but on a more general level. "without compromising their privacy" might be a bit limited in the concrete mention of privacy, but it expresses that the world we want to reach is one where fundamental rights are respected, individuals are respected, and technology is used in a responsible way. I'm thinking of a "free society" here. Having such a vision statement might not be for everyone, but I think this is ok. This is not about convincing anybody, but about expressing the common driver which already is there. I do think it's motivating, but I also think there are many other motivations and concrete reasons which bring people to KDE. In the end I feel they are compatible with a vision statement as Ingo expressed it and it actually describes the core of where we can go as a community. -- Cornelius Schumacher <schumac...@kde.org> ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] finding a clear vision for KDE - first draft for discussion
On Friday 05 February 2016 08:20:22 Martin Graesslin wrote: > > Thus now my question: How will this vision provide us guidance for the next > disruption? How will we be able to use this vision to be a leader in the > next disruption? Please explain why you think that the vision will help in > the next disruption. If you don't think that the vision is for that please > also explain why you think that. E.g. if you think we shouldn't care about > the next disruption, please explain the reasoning for it. I'm not sure if disruption is the right target for us. It is a term mostly used in context of disrupting a commercial market. Sure the commercial market for desktops has been disrupted by mobile and other factors, it's hard to sell desktop software, Microsoft is looking hard for other business models, Apple is already giving away their software for free. But this is not affecting us in the same way, we don't lose the opportunity to make money, on the contrary, we actually gain an opportunity to provide desktop software, because we have a sustainable model how to produce this without a commercial market. I'm all for innovation, creating new stuff, riding waves of new technology. But on the other hand there also is a lot of value in simply scratching your own itch, in focusing on bringing freedom to technology-wise established markets, and playing to our strengths. I'm perfectly fine with a vision which provides me with a perspective to give me control and freedom of my own computing needs, and leave being the uber of mobile big data cloud containers to somebody else. -- Cornelius Schumacher <schumac...@kde.org> ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Improving the TechBase Wiki to help new contributors getting involved in KDE
On Sunday 08 March 2015 01:24:47 Mathieu Tarral wrote: I would like to raise your attention to the state of the TechBase Wiki. The main purpose of this wiki is to contain the technical information needed by new contributors and everyday developers to get involved in the project, and stay up to date with new development procedures. When we set up Techbase, we targeted at developers using KDE technology, i.e. ISVs, sysadmins, any third-party developer creating applications using KDE libraries. It was supposed to lower the barrier for external developers writing applications, but who usually wouldn't be part of the community. So it's not primarily about contributors to KDE software or getting developers to join the community, but about polished technical resources for a broad audience of people using KDE technology. For contributors and people who work as part of the KDE community on KDE software itself, we have community.kde.org. The information there goes deeper, sometimes requires more background knowledge, and is more in flux. It's in a separate Wiki, so it doesn't confuse or distract third-party developers who don't have the intention or time to dig deeper into the community. With this separation in mind the structure makes more sense. That said, there certainly are many areas where it still can be improved. -- Cornelius Schumacher schumac...@kde.org ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] KDE fundraisers and things we've learned
On Monday 22 December 2014 21:00:25 Mario Fux wrote: One can see it from the perspective of distracting each other and fighting for the audience. But I'd see this as a rather destructive way of handling this discussion. I would like to talk about the opportunities we miss(ed), we can and should learn from each other, base new fundraisers on the what we've learned before, use our strength like the KDE community as a social network, the dot.kde.org as one of our bigger communication channels, so let's crowd distribute the information for our crowd funding. We can and will do better than we do now. It's great to see that we have increasing success with fund raisers. Last year we have raised more money with fund raisers than ever before, and that is an excellent sign that we have a community which is able to sustain the work we are doing for free software. The discussion has gone on some tangents which don't do this success justice. We should not discuss how to distribute a fixed cake, but how we can grow the cake bigger. Bruno has put it the right way, that successful campaigns demonstrate that projects are active and are doing the right things, and Boud has told the stories about how Krita reaches out to people we have never reached before. This is the stuff which I find exciting. We can build on that. It is a truism that our money is finite. But this community consistently deals with requests for money in an extremely responsible way. It actually is amazing how many people try hard to only request the money they really need, bring in own resources or try to get others to help before they ask KDE e.V. Of course we need to manage the budget of KDE e.V., but the best way we can do that is with the happy feeling that we are able to help, not with a feeling of envy or unfairness, if an active and successful project gets a good amount of support. Mario is right in saying that taking the perspective of fighting for the audience within KDE is destructive. We don't need to go down this path. We can grow our audience. We can multiply our success by working together. Fund raising is about asking for money. We should not be afraid of doing that, no matter if it's for a single application or for the overall community. If we do it with the passion for our work and with the awareness of being part of a bigger community, we can reach much more than if we try to limit and control it. What we definitely need is better coordination and communication. What do you think, would a fundraising workgroup help? Not really a group that's doing a fundraising but that's there to help, coordinate and teach and distribute their knowledge. Coordination is extremely important. It should be clear to everybody that each project and we as community are operating in a larger context. I don't think we need to introduce more formal organization here. People do want to do the right thing, and we should remove obstacles, not create new ones. We do have the kde-ev-campa...@kde.org mailing list, which is meant as the central place to coordinate fund raising campaigns. Let's try to make best use of this, invite people working on fund raisers to subscribe there and share their plans, so we can all learn and align the activities which need to be aligned. Additionally we should add it to our Manifesto. Money is not an easy topic but avoiding it doesn't solve the problems. And if people don't know about certain things like that they should coordinate with KDE e.V. in the case of money they won't. So it's on us to tell the community and tell new members of the community. I don't think that this should be in the Manifesto. It is a very concrete issue and it is valid, but I think it is not on the level of what should be in the Manifesto. The Manifesto and other documents like the code of conduct define higher-level values, and things such as coordinating about fund raising can be derived from them. We should approach this from a pragmatic point of view of how to get things done best and do what is needed for that. This will be much more helpful than trying to nail down a documented rule. -- Cornelius Schumacher schumac...@kde.org ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Give People Access to Great Technology - a possible vision
On Friday 19 September 2014 19:04:53 Valorie Zimmerman wrote: On Fri, Sep 19, 2014 at 9:56 AM, Andrew Lake jamboar...@gmail.com wrote: Image: http://wstaw.org/m/2014/09/19/A_possible_vision.png I would say Plasma and Frameworks at the center. I think it's right to put the KDE desktop in the center in addition to the KDE frameworks. It's Plasma and the application which are our base and where we are coming from. It's this whole set which gives us the integration points we can use to expand to cloud, to devices, to other services. The desktop is a great starting point. -- Cornelius Schumacher schumac...@kde.org ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Proposal: KDE Manifesto wording revision
On Monday 11 November 2013 13:56:32 Eike Hein wrote: After the exchanges in this and the other leg of the subthread there ended up being a follow-up discussion on IRC, with Aaron, Sune (svuorela), me (Sho_) and others contributing. Ultimately, we've together settled on this wording suggestion: All project assets must be hosted on infrastructure available and writable to all KDE contributor accounts. Thanks for the nice progress and the good discussion. Summing up the thoughts behind this: * This is intended to cover the ideas behind both the original ALL and ONLY clauses by specifying that 'all project assets' must be on infrastructure that's covered by our contributor account system. The way this implements ONLY is by implicitly ruling out mirrors that contain additional assets - in other words, it's meant to ensure that KDE's repositories are ca- nonical for projects, and not outdated. This brings parity between what ReviewBoard is doing and what a GitHub mirror is doing. When I read the suggestion and this explanation I wonder why we don't just say what is meant: The canonical version of the project is hosted on KDE infrastructure? This doesn't cover the part that all KDE contributors have write access to all projects, but that would be covered by the original proposal of “All KDE contributor accounts are granted direct, universal write access to the software assets * The new wording hopefully succeeds in being less off-putting to readers, to avoid defeating the purpose of the original ONLY cause (i.e. we want to successfully pitch/convince people to be part of the community, not appear to force them). I'll give you my feedback here, from when I read the proposed wording for the first time: I perceived it as off-putting, because it says all and it says must. That feels as a pretty scary statement to me, especially looking from the perspective of someone trying to move closer to KDE, but not being there yet. It also sounds like it would rule out using any other tools, which are not hosted on KDE infrastructure. In the IRC log there were mentioned Google Docs, Trello, there are certainly more (and not only closed-source ones). I don't think we are trying to say that, as that would obviously go against the status quo, and the manifest is supposed to document our current view, not a future goal. Maybe that's not what's meant as you explain in the paragraph below, but it isn't obvious to me from just reading the suggested wording. Could be that it's just me, though ;-) * Hosting location is still not nailed down further than KDE contributor accounts must have r/w access, answering a de- mand in the original Manifesto discussion. I guess the reason why I'm perceiving this as excluding non-KDE hosted infrastructure is that I read KDE contributor accounts must have r/w access as I must be able to log in with identity.kde.org. That's obviously not possible with many services hosted by other parties. -- Cornelius Schumacher schumac...@kde.org ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Qt Community partner
On Wednesday 04 September 2013 00:35:41 Aleix Pol wrote: I don't really understand how can it happen that Digia has a community program around Qt and we don't know about it... What am I missing? The partnership program was presented at the DevDays last year and some KDE people were there. So it's not that we know nothing. That doesn't mean that the communication around it can't be improved. From our point of view, I would just take it from where we are and get involved. -- Cornelius Schumacher schumac...@kde.org ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
