From 73dfa1130b709eab28059bf0255d2a20e615cecd Mon Sep 17 00:00:00 2001 From: dakle Date: Tue, 9 Jun 2026 20:45:58 +0200 Subject: [PATCH 1/3] Reflect licensing changes since 4.10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MidPoint is not dual-licensed anymore (EUPL only), but the versions ≥4.0 and ≤4.9 still are. This commit modifies the relevant articles so that they reflect the new reality. --- .../code-contribution-guidelines.adoc | 17 +++--- community/dual-licensing.adoc | 61 ++++++++++--------- copyright.adoc | 50 +++++++-------- 3 files changed, 66 insertions(+), 62 deletions(-) diff --git a/community/development/code-contribution-guidelines.adoc b/community/development/code-contribution-guidelines.adoc index 0731b9fae..867c28296 100644 --- a/community/development/code-contribution-guidelines.adoc +++ b/community/development/code-contribution-guidelines.adoc @@ -62,9 +62,11 @@ See below for details. Your contribution may be great and it may improve midPoint today. But even big and substantial contributions may be refused if it is likely that a contribution becomes a maintenance burden in the future. -. *Licensing*: MidPoint is xref:/community/dual-licensing/[dual-licensed] under Apache License and EUPL. -Therefore we have to require Contributor License Agreements (CLAs) from all midPoint contributors. -We need that to re-license the contributions under both licenses. +. *Licensing*: MidPoint 4.10 and newer is xref:/copyright/#source-code-licenses[licensed under the EUPL]. +MidPoint 4.0-4.9 is xref:/community/dual-licensing/[dual-licensed] under the Apache License and the EUPL. +Therefore, for contributions to these versions, we have to require the Contributor License Agreements (CLAs) from all midPoint contributors. +We need that to re-license the contributions under both licenses. + +No such CLA is required for contributions to versions 4.10 and newer. == Contribution Quality and Maintainability @@ -364,12 +366,13 @@ This will cause that your contribution might corrode over time and it may even b * For more details about contributing using git please see the link:http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project[Distributed Git - Contributing to a Project chapter of the Git book.] In fact the whole book is more than worth reading. -== Contributor License Agreements +This section *does not apply to midPoint 4.10 and newer*. -MidPoint is xref:/community/dual-licensing/[dual licensed under Apache License 2.0 and European Union Public License 1.2]. MidPoint users may choose any of those two licenses for their use of midPoint. +MidPoint 4.0-4.9 is xref:/community/dual-licensing/[dual licensed under the Apache License 2.0 and the European Union Public License 1.2]. +MidPoint users may choose any of those two licenses for their use of midPoint. -But the situation is more complicated for the contributors. -While midPoint was single-licensed, the intent of a contributor to contribute under that license was quite clear. +But the situation is more complicated for the contributors to these midPoint versions. +For the single-licensed midPoint versions (≤3.9 and ≥4.10), the intent of a contributor to contribute under that license is quite clear. However, if users may to choose which license to use, contributors might be able to choose as well. And that may lead to confusion and uncertainty about midPoint licensing and other legal issues. diff --git a/community/dual-licensing.adoc b/community/dual-licensing.adoc index b607e903e..d34915f84 100644 --- a/community/dual-licensing.adoc +++ b/community/dual-licensing.adoc @@ -6,9 +6,10 @@ :page-wiki-metadata-modify-user: semancik :page-wiki-metadata-modify-date: 2020-09-22T09:22:06.368+02:00 -MidPoint 4.0 and all following releases are dual-licensed under the terms of Apache License 2.0 and European Union Public License (EUPL). +MidPoint versions from 4.0 to 4.9 are dual-licensed under the terms of the Apache License 2.0 and the European Union Public License 1.2 or later (EUPL). This page explains the details and motivation. +Information on *this page does not apply to midPoint 4.10* and newer. == Introduction @@ -59,43 +60,44 @@ We want to stick with Apache License. == Dual Licensing -Therefore we have decided to use dual licensing approach: midPoint will be provided under both Apache License and EUPL license at the same time. +Therefore, we have decided to use dual licensing approach: midPoint (versions 4.0-4.9) is provided under both the Apache License and the EUPL at the same time. The users may choose the license that suits their needs. This would be almost ideal approach to have the best of both worlds. -Therefore midPoint 4.0 is released under two licenses: +MidPoint versions from 4.0 to 4.9 are released under two licenses: * Apache License 2.0 * European Union Public License (EUPL) 1.2 -The user of midPoint can choose any of those licenses use midPoint. -Therefore nothing should change for current midPoint users that use midPoint under the terms of Apache License. - +Users of midPoint can choose any of those licenses to use midPoint. == Contributions -However, there is a catch. -If midPoint is licensed under just one license, the situation is quite clear. -It is clear that users are using midPoint under that license. -But even more importantly, it is clear that contributions are provided under that license as well. -That is the reason why no extra paperwork was necessary to accept contributions to midPoint project. -But the situation is much more complicated if there are two licenses. -Users may choose any of these licenses, therefore it is not entirely clear how the contributions are licensed. -In addition to that, we need contributions to be licensed under two licenses at the same time. -Therefore in this case more paperwork is needed for midPoint contributions. +Dual licensing may seem like an ideal approach, but there is a catch. +If midPoint were licensed under just one license, the situation would be quite clear. +It would be clear that users are using midPoint under that license. +But even more importantly, it would be clear that contributions are provided under that license as well. +That is why no extra paperwork was necessary to accept contributions to midPoint. + +The situation is much more complicated when there are two licenses. +Users may choose any of the two licenses, so we need contributions to be licensed under the two licenses as well. +Therefore, more paperwork is needed for midPoint contributions. + +The dual licensing approach forces us to apply the _Contributor License Agreement_ (CLA) to all midPoint contributions. +This agreement gives us the right to publish (re-license) the contributions under the terms of both licenses. -The dual licensing approach is forcing us to apply Contributor License Agreements (CLAs) for all midPoint contributions. -Those agreements give us the right to re-publish (re-license) the contribution under the terms of both licenses. -We cannot accept a contribution without a CLA. -This means additional paperwork both for us and for the contributors. -We are really sorry about that. -But that is a necessary evil to make midPoint project thrive. +We cannot accept a contribution without the CLA, +even though it means additional paperwork for both us and the contributors. +We are really sorry about that, +but it is a necessary evil to make the midPoint project thrive. +If you contribute as an employee of a company, the CLA needs to be signed by your employer. -== Translations, Samples and More -We can live with CLAs for contributors to core midPoint code. +== Translations, samples, and more + +We can live with CLAs for contributors to the core midPoint code. MidPoint is quite a comprehensive project. There is lot of code and the code can be quite complex. Understanding the code is no simple feat. @@ -105,14 +107,13 @@ Applying CLAs to code contributions is painful, but it is something that we can But the situation is quite different for translations, samples and other parts of midPoint that are more or less supplemental. We do not want to put a high entry barrier for those. -We think that it is essential that community cooperation for those parts of midPoint is as easy as possible. -Therefore translations and samples will be moved to separate projects. -Those projects will be single-licensed under the terms of Apache License. -*Therefore no CLAs will be necessary to contribute to translations and samples.* It is also likely that some testing scenarios (e.g. xref:/midpoint/reference/samples/story-tests/[Story Tests]) will be separated from midPoint in the future. - -Similarly, the connectors remain single-licensed under Apache License. -At least for the time being. +We consider it essential that the community contribution to those parts of midPoint is as easy as possible. +Therefore, translations and samples are in separate projects. +Those projects are single-licensed under the terms of the Apache License +and *no CLA is necessary to contribute to translations and samples.* +Similarly, connectors remain single-licensed, usually under the Apache License. +See the `LICENSE` file in their particular repo to make sure. == See Also diff --git a/copyright.adoc b/copyright.adoc index 7381d70c6..ff51ef40d 100644 --- a/copyright.adoc +++ b/copyright.adoc @@ -3,12 +3,11 @@ Unless explicitly stated otherwise, all work published on this site and all other Evolveum sites is *Copyright © Evolveum, s.r.o., all rights reserved*. +== Documentation license -== Documentation License +All Evolveum documentation is available under the terms of *https://creativecommons.org/licenses/by-nc-nd/4.0/[Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) license]*. -All evolveum documentation is available under the terms of *https://creativecommons.org/licenses/by-nc-nd/4.0/[Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) license]*. - -The _documentation_ means all the texts that are publicly available on https://docs.evolveum.com/[docs.evolveum.com] web site. +The _documentation_ means all the materials that are publicly available on https://docs.evolveum.com/[docs.evolveum.com] web site. While the license says _NonCommercial_, you can use the documentation for almost all the usual things that you can think of, that are not primarily intended for commercial advantage or monetary compensation. @@ -45,8 +44,9 @@ While doing that, you *must*: * *Give attribution*. You are supposed to mention author of the document when quoting from it or using it in any similar way. -Use appropriate text for that, which will usually be along the lines of `Evolveum` or `docs.evolveum.com`. -Please, provide a link to the original document whenever you can. +Use appropriate text for that; +it should include a mention of `Evolveum` or `docs.evolveum.com`. +Provide a link to the original document whenever you can. * *Keep us free from any liability*. The documentation is provided "AS IS". @@ -109,10 +109,10 @@ Such license is usually part of Evolveum partner agreement. == Source Code Licenses -MidPoint source code is dual-licensed under the terms of https://www.apache.org/licenses/LICENSE-2.0[Apache License 2.0 (AL)] and https://eupl.eu/[European Union Public License (EUPL)]. -Dual licensing means that you can choose any of these licenses for your particular use of our source code. +== Source code licenses -If you choose any of these licenses: +Since version 4.10, midPoint source code is licensed under the terms of link:https://eupl.eu/[European Union Public License 1.2 or later (EUPL)]. +The EUPL gives you the following freedoms and obligations: * You can use the code for pretty much any purpose, including commercial purposes. @@ -125,16 +125,19 @@ It is your responsibility to make sure it works for you, not ours. * You are not granted any right to use our trademarks. -If you choose EUPL license, in addition to the above you have to: +* If you modify the source code, you must publicly distribute it ("copyleft" license). -* Distribute modified source code if you make any modifications ("copyleft" license). +MidPoint versions 4.0-4.9 are dual-licensed under the terms of link:https://www.apache.org/licenses/LICENSE-2.0[Apache License 2.0 (AL)] and link:https://eupl.eu/[European Union Public License 1.2 (EUPL)]. +Dual licensing means that you can choose any of these licenses for your particular use of our source code. + +If you choose the Apache licence, you do not have to distribute the source code if you make any modifications to it. This explanation is simplified. Please refer to full text of the licenses for details. -NOTE: That are some parts of code, that are licensed under Apache License only. +NOTE: That are some parts of code that are licensed under Apache License only. They are not dual-licensed for simplicity, to make contributions easier. -This usually applies to parts of the code that are outside of midPoint core and auxiliary data such as samples and translations. +This usually applies to parts of the code that are outside of midPoint core and to auxiliary data such as samples and translations. Such parts are single-licensed under the terms of Apache License, as this license is more liberal of the two. Also, the connectors are usually single-licensed under the terms of Apache License. However, due to historical reasons, some connectors may use a different license, most notably CDDL. @@ -143,20 +146,17 @@ Each project has its own `LICENSE` file that specifies the licensing condition. === Contributions -MidPoint is dual-licensed. -You can choose any of the two licenses to use midPoint. -However, when you contribute back, it is not clear which license is the contribution under. -Additionally, we need to publish the contribution under both licenses, otherwise we could not maintain midPoint as a single product. -Therefore we need the right to re-license your contribution. +If you decide to contribute to midPoint 4.10 and newer, your contribution will be licensed under the EUPL. +There is no paperwork you would need to sign as long as your contribution stays in the versions 4.10 and newer. + +It is more complicated for the dual-licensed versions 4.0-4.9. -If you want to make a contribution to midPoint core, we will ask you to sign _Contributor License Agreement (CLA)_. -The agreement sets the conditions for contribution. -It is relatively short document, just a couple of pages. -If you contribute in context of being employed, the CLA needs to be signed by your employer. +Since midPoint versions from 4.0 to 4.9 are dual-licensed under Apache Licence 2.0 and European Union Public License 1.2, there is additional paperwork involved in contributing to these versions. +In short, we need you to sign the _Contributor License Agreement (CLA)_, which allows us to re-license your contribution and publish it under both licences. +Please refer to xref:/community/dual-licensing/#contributions[] for more details. -If you contribute to parts that are not dual-licensed, the CLA is not needed. -Licensing conditions are clear in that case. -This applies to translations, samples and most of the connectors. +If you contribute to parts that are not dual-licensed, the CLA is not needed, because licensing conditions are clear in that case. +This applies to midPoint versions 4.10+, translations, configuration samples, and most of the connectors. == Services From b78aa44f05303a6f507f2be6cebd4114233716c7 Mon Sep 17 00:00:00 2001 From: dakle Date: Tue, 9 Jun 2026 20:50:57 +0200 Subject: [PATCH 2/3] add TOC; add meta KWs & description --- community/development/code-contribution-guidelines.adoc | 3 ++- community/dual-licensing.adoc | 3 +++ copyright.adoc | 3 +++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/community/development/code-contribution-guidelines.adoc b/community/development/code-contribution-guidelines.adoc index 867c28296..a9ec0a291 100644 --- a/community/development/code-contribution-guidelines.adoc +++ b/community/development/code-contribution-guidelines.adoc @@ -6,7 +6,8 @@ :page-wiki-metadata-modify-user: petr.gasparik :page-wiki-metadata-modify-date: 2019-09-06T15:50:13.427+02:00 :page-toc: top - +:page-description: This article explains how to contribute code to midPoint: contribution criteria, quality standards, CLA requirements, pull request process, and communication guidelines. +:page-keywords: midPoint code contribution, contribution guidelines, pull request, contributor license agreement, CLA, maintainability, bugfix, new feature contribution, automated tests, developer documentation, GitHub, mailing list, Apache License, EUPL == Introduction diff --git a/community/dual-licensing.adoc b/community/dual-licensing.adoc index d34915f84..0dc34b10c 100644 --- a/community/dual-licensing.adoc +++ b/community/dual-licensing.adoc @@ -5,6 +5,9 @@ :page-wiki-metadata-create-date: 2019-01-21T17:51:19.810+01:00 :page-wiki-metadata-modify-user: semancik :page-wiki-metadata-modify-date: 2020-09-22T09:22:06.368+02:00 +:page-toc: top +:page-description: This article explains dual licensing of midPoint versions 4.0-4.9. It does not apply to midPoint 4.10 and newer. +:page-keywords: dual licence, dual licensing, eupl, apache, public code, funding, open source MidPoint versions from 4.0 to 4.9 are dual-licensed under the terms of the Apache License 2.0 and the European Union Public License 1.2 or later (EUPL). This page explains the details and motivation. diff --git a/copyright.adoc b/copyright.adoc index ff51ef40d..3b5af1384 100644 --- a/copyright.adoc +++ b/copyright.adoc @@ -1,5 +1,8 @@ = General Copyright and Licensing Guidelines :page-visibility: auxiliary +:page-toc: top +:page-description: This article explains midPoint and its documentation licensing, your liberties, obligations, and contribution conditions. +:page-keywords: contribute, contribution, dual licence, licence, liberties, documentation, dual licensing, eupl, apache, open source Unless explicitly stated otherwise, all work published on this site and all other Evolveum sites is *Copyright © Evolveum, s.r.o., all rights reserved*. From a3e2d76120551332f9178878d8578285b94a3d16 Mon Sep 17 00:00:00 2001 From: dakle Date: Tue, 9 Jun 2026 20:54:22 +0200 Subject: [PATCH 3/3] Grammar, punctuation, and typography fixes --- .../code-contribution-guidelines.adoc | 134 +++++++++--------- community/dual-licensing.adoc | 35 +++-- copyright.adoc | 38 +++-- 3 files changed, 104 insertions(+), 103 deletions(-) diff --git a/community/development/code-contribution-guidelines.adoc b/community/development/code-contribution-guidelines.adoc index a9ec0a291..ae311d3d7 100644 --- a/community/development/code-contribution-guidelines.adoc +++ b/community/development/code-contribution-guidelines.adoc @@ -1,4 +1,4 @@ -= Code Contribution Guidelines += Code contribution guidelines :page-wiki-name: Code Contribution Guidelines :page-wiki-id: 27361410 :page-wiki-metadata-create-user: semancik @@ -14,21 +14,21 @@ This short guide provides instructions for the developers that plan to contribute code to the midPoint project. MidPoint project was started by small and very dedicated team of engineers that knew each other quite well. -Therefore the early years of midPoint development went without any major organizational issue. +Therefore, the early years of midPoint development went without any major organizational issue. There were xref:/midpoint/devel/guidelines/[development guidelines], but those in fact were not really necessary. In fact the first rule of midPoint development was that there are no rules of midPoint development. As the code base matured and midPoint gained wider adoption first external contributions began to appear. Those were usually small and simple things. But later on bigger contributions appeared. -And those were not entirelly without problems. +And those were not entirely without problems. This is quite an expected development. MidPoint core team communicates in a very natural and efficient way. And this is something we do not want to change as this is the pillar of midPoint development efficiency. But it is much harder to maintain good communication with a broader, geographically and culturally diverse community. Hence the need for contribution guidelines. -== Communication Channels +== Communication channels There are two communication channels for developers: @@ -45,12 +45,13 @@ And please maintain appropriate levels of politeness and civility. On the other hand, we strongly discourage private communication with midPoint developers. Please do *not* address midPoint developer privately, whether it is private mail or private chat message. -Private communication is not visible to the public and therefore it limits propagation of knowledge about midPoint code. +Private communication is not visible to the public; +therefore, it limits propagation of knowledge about midPoint code. It is our *policy* not to respond to such private messages. -Therefore do not be surprised if you won't get any reply. +Therefore, do not be surprised if you won't get any reply. Private communication is reserved for midPoint xref:/support/subscription-sponsoring/[subscribers]. *Community communication is always kept open.* Including communication about code contributions. -== Accepting Contributions +== Accepting contributions Generally speaking, midPoint project is open to contributions of any kind. However, there are three critical criteria for accepting a contribution: @@ -69,17 +70,17 @@ Therefore, for contributions to these versions, we have to require the Contribut We need that to re-license the contributions under both licenses. + No such CLA is required for contributions to versions 4.10 and newer. -== Contribution Quality and Maintainability +== Contribution quality and maintainability This section provides guidelines for quality of midPoint contributions and explains our maintainability strategy. Please read those guidelines carefully before you start your work on midPoint contribution. A contribution may be refused if it violates any of those guidelines. We would hate to refuse contributions as that means that a developer's work is wasted. That is always a terrible thing. -Therefore please, make sure you follow those guidelines when preparing a contribution. +Therefore, please make sure you follow those guidelines when preparing a contribution. -=== Discuss The Contribution +=== Discuss the contribution First and most important guideline: *Discuss your contribution before starting the work.* @@ -94,12 +95,12 @@ But as midPoint itself is big, the documentation is also big. And it may be confusing. It is easy to miss something. Especially if you are first-time contributor. -Therefore *discuss your idea* with midPoint core team. +Therefore, *discuss your idea* with midPoint core team. We may point out a better way to implement a particular feature. It also often happens that we have designed similar feature in the past and that there is already some preparatory work done in midPoint. That may make your work much easier. Such preparatory work is almost never documented, as such work is almost never funded and documenting it would be too much overhead. -Therefore do not be afraid to ask. +Therefore, do not be afraid to ask. We will be glad to respond. However, make sure that you mention contribution in your question. @@ -107,16 +108,16 @@ Ideally include the word "contribution" in the subject of the mail message. There are too many questions on mailing list. Many of the questions are asked by people that do not contribute back to the community. Such questions are low priority for MidPoint core developers. -However, if you plan to contribute to midPoint please let us know and make your question stand out. +However, if you plan to contribute to midPoint, please let us know and make your question stand out. That will attract attention of midPoint developers. Make sure you discuss your contribution especially if it is new functionality. There is no need for discussion if you contribute just a simple and quite obvious bugfix. But if you extend midPoint functionality, then discussing the contribution before you do any work is almost a necessary condition for contribution acceptance. -Therefore please avoid future disappointments and discuss your ideas very early. +Therefore, please avoid future disappointments and discuss your ideas very early. Discussing the contribution significantly lowers the risk of a contribution being refused. -=== Content of Contribution +=== Content of contribution Contribution should contain: @@ -150,7 +151,7 @@ The master branch is the only long-term "living" branch for midPoint development Support branches are "dead end" branches. They will never get merged back into the master. Those branches are there only for support (backport) purposes. -Therefore contribution based on those branches does not really make sense. +Therefore, contribution based on those branches does not really make sense. The only exception from the above rule are security fixes. We will accept security fixes at any time and for any branch. @@ -209,7 +210,7 @@ But there is also a documentation that is supposed to make writing tests easier: * xref:/midpoint/tools/schrodinger/[] -=== Developer Documentation +=== Developer documentation Provide inline documentation at an appropriate granularity. We are no overly strict about javadoc we do *not* require javadoc for every class or method. @@ -254,11 +255,11 @@ This is the only way how to improve the code later. Code with hard design decisions is likely to be accepted if those design decisions are justified and explained in the code. Code with unreadable design decisions that are not documented is very likely to be refused - even if those design decisions are good. -=== User Documentation +=== User documentation If your contribution contains a new feature, there usually needs to be at least some user documentation. MidPoint documentation is maintained in this wiki. -Therefore it requires a separate contribution. +Therefore, it requires a separate contribution. If you discuss new feature beforehand (which you should) and if you keep communication (which you also should) you can get write access to wiki to contribute the documentation. New feature documentation usually contains two related, but slightly different pages: @@ -272,7 +273,7 @@ This page should contain configuration snippets, pointers to samples and so on. No user documentation is needed for bugfixes. Smaller improvements are often OK with small updates to existing documentation. -=== Contribution Quality and Maintainability +=== Contribution quality and maintainability Generally speaking, contributions should (at least) reach the average quality of midPoint code. But the quality requirement varies with the size and complexity of the contribution: @@ -292,7 +293,7 @@ The team consists of professional, dedicated, full-time developers. MidPoint development is their day job. Even though the team is geographically distributed, good communication paths are established and maintained. Fluctuation is very low and most of the developers that started the project are still part of the team. -Therefore if any of midPoint core developers discovers an issue with midPoint code, it is easy to track down the author, discuss the problem and find appropriate solution.This usually takes hours or even minutes. +Therefore, if any of midPoint core developers discovers an issue with midPoint code, it is easy to track down the author, discuss the problem and find appropriate solution.This usually takes hours or even minutes. And this makes midPoint maintenance very efficient. However, situation is very different for contributed code. @@ -304,11 +305,11 @@ This means that we cannot rely on efficient communication with contributors. When we accept a contribution to midPoint code base, we are also accepting responsibility for maintenance of the contributed code. If the contribution is small and simple, we are quite sure that maintenance overhead will be acceptable. -Therefore we are willing to accept lower-quality contributions if they are small and their impact is limited. +Therefore, we are willing to accept lower-quality contributions if they are small and their impact is limited. But for big and complex contributions we have to be more careful. We need to consider the effect of the contribution on overall maintenance effort. Also, big contributions are increasing risks, such as risk of instability, incompatibility risk, security risk or risk of leading that particular part of the system into a development dead end. -Therefore we need to scrutinize big contributions much more carefully. +Therefore, we need to scrutinize big contributions much more carefully. And we have to insist on higher quality. Big contributions need to be perfectly readable, design decisions must be documented and the contribution must be covered with appropriate tests. Otherwise we risk that the contribution will become a maintenance burden and we will need to remove it. @@ -316,22 +317,23 @@ And then the whole effort of developing a contribution, accepting it, maintainin MidPoint would be better off if we have refused the contribution at the beginning. Less work would be wasted - for everybody involved. -Therefore, if you plan to make big contribution please make sure that you understand the size and complexity of midPoint code and that you are not overestimating your abilities. +Therefore, if you plan to make big contribution, please make sure that you understand the size and complexity of midPoint code and that you are not overestimating your abilities. In that case it is absolutely essential to *discuss the contribution* before you start any real work. And make sure that high quality standards are applied while developing the contribution. Otherwise the contribution may pose a risk for midPoint maintainability and we will have to refuse such contribution. -=== Tips and Best Practice +=== Tips and best practice * *Do not submit each individual commit* unless the commit itself is a complete contribution. If your contribution is divided into several commits (which is perfectly fine) then send all the commits together so the maintainer can apply and test them together. * If you have many commits but you want only to show them as one in the final midPoint history you might want to *squash* these commits to one. -You can use git interactive rebasing to do this. +You can use Git interactive rebasing to do this. (`git rebase -i`, the link:http://git-scm.com/book/en/Git-Tools-Rewriting-History[Git book] provides more details) * Provide a meaningful *commit message*. If the commit message is longer than a single line provide a *short summary of the message in the first line* and then provide more details in subsequent lines. -Most git tools display just the first line of the commit message therefore the developers should be able to get an idea about the commit just from the first line. +Most Git tools display just the first line of the commit message. +Therefore, the developers should be able to get an idea about the commit just from the first line. * If there is an issue created in our xref:/support/bug-tracking-system/[bug-tracking system] it is recommended to include issue identifier in the commit message. @@ -341,7 +343,7 @@ Most git tools display just the first line of the commit message therefore the d Not in the midPoint development team and we do not provide that to the contributions as well. All code belongs to every developer and anyone has the right to modify any code. The only thing that we care about is the quality of the modification, not its origin. -Therefore feel free to modify any code and fix bugs anywhere in the midPoint core or in any of the contributions. +Therefore, feel free to modify any code and fix bugs anywhere in the midPoint core or in any of the contributions. Just please make sure you know what you are doing. If you are not you are free to discuss that on `midpoint-dev` mailing list. If you contribute a code be prepared that others may modify it. @@ -350,8 +352,8 @@ If you do not want others to ruin you code then do not contribute it. * MidPoint core team is trying to be quite careful about the state of the `master` branch in main midPoint repository. We try very hard not to break the build and we are also careful about passing tests and overall code quality. But this is software development and we are only human beings. -Therefore it may happen that we break something occasionally. -Therefore it is good idea to *check the state of the source code before pulling* from the main midPoint repository. +Therefore, it may happen that we break something occasionally. +Therefore, it is good idea to *check the state of the source code before pulling* from the main midPoint repository. The easiest way to do this is by looking at our xref:/midpoint/devel/continuous-integration/[continuous integration system]. If it is mostly green then it is probably OK to pull changes. If it is too red it is better to postpone the pull for a while. @@ -365,7 +367,9 @@ If you have good tests for the code the problem will be detected soon after the If you have no tests then you code will break without anyone noticing it for quite a long time. This will cause that your contribution might corrode over time and it may even be removed from the main code if its quality drops too low. -* For more details about contributing using git please see the link:http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project[Distributed Git - Contributing to a Project chapter of the Git book.] In fact the whole book is more than worth reading. +* For more details about contributing using Git please see the link:http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project[Distributed Git - Contributing to a Project chapter of the Git book.] In fact the whole book is more than worth reading. + +== Contributor license agreements This section *does not apply to midPoint 4.10 and newer*. @@ -377,32 +381,32 @@ For the single-licensed midPoint versions (≤3.9 and ≥4.10), the intent of a However, if users may to choose which license to use, contributors might be able to choose as well. And that may lead to confusion and uncertainty about midPoint licensing and other legal issues. -Therefore it is necessary to require contributor license agreements (CLA) from midPoint contributors. +Therefore, it is necessary to require the Contributor License Agreements (CLA) from midPoint contributors. The purpose of the license agreements is to make licensing of midPoint code completely clear. -Therefore if you submit a contribution to midPoint you will be asked to sign a CLA before the contribution can be accepted. +Therefore, if you submit a contribution to midPoint, you will be asked to sign the CLA before the contribution can be accepted. == Credit Git maintains the commit meta-data of the original commit. And this is what will be recorded in the history trail of main midPoint repository. -Therefore the *original contributor will be recorded in each commit*. Apart from this the contributors are free to add their names to the appropriate place in the file header (e.g. Java `@author` annotation) if they feel their contribution is big enough to justify it. +Therefore, the *original contributor will be recorded in each commit*. Apart from this the contributors are free to add their names to the appropriate place in the file header (e.g. Java `@author` annotation) if they feel their contribution is big enough to justify it. -== Contribution Mechanics (Pull Requests) +== Contribution mechanics (pull requests) -Preferred way to make a contribution is to follow the pull _request procedure_ on github. +Preferred way to make a contribution is to follow the pull _request procedure_ on GitHub. This method is quite simple, fast and straightforward. Old school developers may also use the traditional way (sending patches in development mailing list) and we will be perfectly happy to accept such contributions as well. -To start working on your contribution simply fork the project on github. +To start working on your contribution simply fork the project on GitHub. Smaller contributions can be easily developed directly on `master` branch in your fork. For bigger contributions we recommend to create a new branch (feature branch). That's the same approach that we use for midPoint core development and it works quite well. -When you are done with the contribution simply create new pull request on github. +When you are done with the contribution simply create new pull request on GitHub. MidPoint core team will be notified, we will review the code, provide feedback, you will have the chance to improve the contribution and finally we will either accept or refuse the contribution. -All of that can be done on github. -For the old school developers the process is the same, but mailing list is used instead of github. +All of that can be done on GitHub. +For the old school developers, the process is the same, but mailing list is used instead of GitHub. -The code of midPoint core is currently in a single git repository. +The code of midPoint core is currently in a single Git repository. But there are other repositories that contain related code: connectors, clients, overlay projects and so on. Each repository has its maintainer (or maintainers). Maintainer is responsible for keeping the project in shape. @@ -412,7 +416,7 @@ Please be patient when it comes to interactions with midPoint core team. Our day job is to develop midPoint. If you are planning a contribution then you are supposed to get higher priority than usual. But do not expect immediate response, especially at times when midPoint development is reaching crucial milestone and the time is tight. -Therefore if you plan for your contribution to be included in a particular release then make sure the timing is appropriate. +Therefore, if you plan for your contribution to be included in a particular release then make sure the timing is appropriate. New feature contributions are accepted only during the development phase of midPoint (between start of new version development and feature freeze). New features submitted after feature freeze will need to wait until the development of a new version starts. Bugfix contributions can be accepted any time. @@ -422,36 +426,36 @@ And, as you probably know very well, free time is a precious commodity especiall If you submit your contribution close to the deadline then the risk of postponing the contribution to the next release is very high. [TIP] -.Github, Gitlab and big evil corporations +.GitHub, GitLab, and big evil corporations ==== -Some people will certainly express concerns about our use of github. -After all, github is a centralized platform. +Some people will certainly express concerns about our use of GitHub. +After all, GitHub is a centralized platform. And as such, there are always concerns of abuse, monopolization and single point of failure. We are more than aware of such concerns. And we highly value project autonomy. -Despite that we have decided that centralized platforms such as github are providing good value - if they are used in moderation. +Despite that we have decided that centralized platforms such as GitHub are providing good value - if they are used in moderation. -We are using github to publish the code (git repositories) and to govern pull requests. -We are *not* relying on github for anything else. -We are not using github issues, wiki or any similar feature. +We are using GitHub to publish the code (Git repositories) and to govern pull requests. +We are *not* relying on GitHub for anything else. +We are not using GitHub issues, wiki or any similar feature. And we do not plan to. Because we value our autonomy. -Github was acquired by a certain corporation which has done questionable things in the past and there is no telling what will be done in the future. -Therefore we need a freedom to evacuate our projects from github when things start to move in wrong direction. -Git makes this easy, as migrating git repository is basically a question of a single _push_. Therefore we use github today, but it may be gitlab tomorrow and we may migrate to a completely self-hosted solution the day after. -But the situation is quite different for github issues and wikis - those are not that easy to migrate. -Therefore we do not use them at all. -We still use github pull requests, though. +GitHub was acquired by a certain corporation which has done questionable things in the past and there is no telling what will be done in the future. +Therefore, we need a freedom to evacuate our projects from GitHub when things start to move in wrong direction. +Git makes this easy, as migrating Git repository is basically a question of a single _push_. Therefore, we use GitHub today, but it may be GitLab tomorrow and we may migrate to a completely self-hosted solution the day after. +But the situation is quite different for GitHub issues and wikis - those are not that easy to migrate. +Therefore, we do not use them at all. +We still use GitHub pull requests, though. Those provide very good value. And pull requests are temporary anyway - if handled correctly. -Accepted pull requests are transformed into git history. -And we do not rcare about refused pull requets that much. -Therefore there is very little risk of losing pull request history. -Everything we value is part of git and git is easy to migrate any time. +Accepted pull requests are transformed into Git history. +And we do not care about refused pull requests that much. +Therefore, there is very little risk of losing pull request history. +Everything we value is part of Git and Git is easy to migrate any time. ==== -== Issue Reports +== Issue reports Bug reports, improvement suggestions, feature requests and similar issues are appreciated, but they are not considered to be _contributions_. Except for one case: security vulnerability reports. Security vulnerability reports gets highest priority and they will be addressed immediately without any concern to who reports them. @@ -473,12 +477,12 @@ There are only two ways how to be sure that the bug will get fixed: purchase mid Do *not* report issues using GitHub. If you do it anyway, then do not be surprised that we do not react. -See the exaplanation above. +See the explanation above. -== See Also +== See also -* xref:/midpoint/devel/guidelines/[Development Guidelines] +* xref:/midpoint/devel/guidelines/[] -* xref:/community/development/[Development Participation] +* xref:/community/development/[] -* xref:/support/bug-tracking-system/[Issue Tracking System] +* xref:/support/bug-tracking-system/[] \ No newline at end of file diff --git a/community/dual-licensing.adoc b/community/dual-licensing.adoc index 0dc34b10c..411b87288 100644 --- a/community/dual-licensing.adoc +++ b/community/dual-licensing.adoc @@ -1,4 +1,4 @@ -= Dual Licensing += Dual licensing :page-wiki-name: Dual Licensing :page-wiki-id: 27361612 :page-wiki-metadata-create-user: semancik @@ -34,38 +34,37 @@ Evolveum has a good business model based on support, subscription and other serv This business model works in many environments such as enterprise or academia. However, it does not work very well when public money are directly involved. - == European Union There are great initiatives such as link:https://publiccode.eu/[Public Money, Public Code]. However, those ideas as not yet universally adopted. And even those initiatives alone will not provide funding to open source projects. But all is not lost. -Evolveum is an European company. -And European Union runs several programs to support open source projects. -For example there is link:https://joinup.ec.europa.eu/collection/eu-fossa-2[Free and Open Source Software Audit (FOSSA)] program focused on improving security of open source software. +Evolveum is a European company. +And the European Union runs several programs to support open source projects. +For example, there is the link:https://joinup.ec.europa.eu/collection/eu-fossa-2[Free and Open Source Software Audit (FOSSA)] program focused on improving security of open source software. Even though those programs are very useful, they provide funding for open source testing. There is no funding for open source maintenance. -Simply speaking, FOSSA will pay for discovery of the bug, but they will not pay for the fix. -But there are other programs, and there is a chance to get funding even for the maintenance. -However, there are some limitations for projects that can be eligible. -European Union created its own license for open source software: link:https://opensource.org/licenses/EUPL-1.2[European Union Public License (EUPL)]. We believe that we can significantly increase our chances to get EU funding if we play by the EU rules. -Simply speaking, we thing that if midPoint is licensed under EUPL we would be able to secure funding that will cover at least some parts of midPoint maintenance. +Simply speaking, FOSSA will pay for discovery of a bug, but they will not pay for the fix. +But there are other programs and there is a chance to get funding even for the maintenance. +However, there are some limitations for projects to be eligible. +The European Union has created its own license for open source software: link:https://opensource.org/licenses/EUPL-1.2[European Union Public License (EUPL)]. We believe that we can significantly increase our chances to get EU funding if we play by the EU rules. +Simply speaking, we think that if midPoint is licensed under the EUPL we would be able to secure funding that will cover at least some parts of midPoint maintenance. == Apache -On the other hand, we are completely happy with Apache License and we do not want to forfeit the liberties that Apache License provides. +On the other hand, we are completely happy with the Apache License and we do not want to forfeit the liberties that the Apache License provides. We like the liberty of a software used by anyone for any purpose. We do not want to forfeit that liberty. We do not like the idea of software use being limited, not even by a copyleft open source license. -We want to stick with Apache License. +We want to stick with the Apache License. -== Dual Licensing +== Dual licensing Therefore, we have decided to use dual licensing approach: midPoint (versions 4.0-4.9) is provided under both the Apache License and the EUPL at the same time. The users may choose the license that suits their needs. -This would be almost ideal approach to have the best of both worlds. +This is almost an ideal approach to have the best of both worlds. MidPoint versions from 4.0 to 4.9 are released under two licenses: @@ -104,11 +103,11 @@ We can live with CLAs for contributors to the core midPoint code. MidPoint is quite a comprehensive project. There is lot of code and the code can be quite complex. Understanding the code is no simple feat. -Therefore contributing to midPoint core has quite a high entry barrier already. +Therefore, contributing to the midPoint core has quite a high entry barrier already. Code contribution is a process with significant overhead, as each code contribution has to be reviewed. Applying CLAs to code contributions is painful, but it is something that we can live with. -But the situation is quite different for translations, samples and other parts of midPoint that are more or less supplemental. +But the situation is quite different for translations, samples, and other parts of midPoint that are more or less supplemental. We do not want to put a high entry barrier for those. We consider it essential that the community contribution to those parts of midPoint is as easy as possible. Therefore, translations and samples are in separate projects. @@ -118,8 +117,8 @@ and *no CLA is necessary to contribute to translations and samples.* Similarly, connectors remain single-licensed, usually under the Apache License. See the `LICENSE` file in their particular repo to make sure. -== See Also +== See also * xref:development/code-contribution-guidelines.adoc[] -* xref:/copyright/[Copyright and Licensing Guidelines] +* xref:/copyright/[Copyright and Licensing Guidelines] \ No newline at end of file diff --git a/copyright.adoc b/copyright.adoc index 3b5af1384..7a83e0779 100644 --- a/copyright.adoc +++ b/copyright.adoc @@ -1,4 +1,4 @@ -= General Copyright and Licensing Guidelines += General copyright and licensing guidelines :page-visibility: auxiliary :page-toc: top :page-description: This article explains midPoint and its documentation licensing, your liberties, obligations, and contribution conditions. @@ -16,7 +16,7 @@ While the license says _NonCommercial_, you can use the documentation for almost Simple speaking, you are *allowed* to: -* *Read the documentation, learn from it and use the knowledge* for any purpose, which may include commercial use. +* *Read the documentation, learn from it, and use the knowledge* for any purpose, which may include commercial use. In fact, commercial use of your knowledge is more than encouraged. We want you and your organization to prosper. @@ -25,7 +25,7 @@ You can use the quoted parts for any purpose, as long as the size of the quoted For example, you can copy samples from the documentation and use it in your configuration, even for commercial purposes. You can copy reasonable parts of the documentation in your academic paper, in your blog, even in a wiki dedicated to your commercial project. If you are publishing such parts in a form that is supposed to be read by a human, you are supposed to include proper attribution (see below). -Just remember, that these parts must be small. +Just remember that these parts must be small. When in doubt, look up how your applicable copyright legislation defines "fair use". * *Link to the documentation* from anywhere, whether the source is public or private, commercial or non-commercial. @@ -33,11 +33,11 @@ All the documentation is publicly available, therefore a simple link is usually Linking to our documentation is strongly encouraged. We want the knowledge to spread far and wide. -* *Share the documentation freely* in your organization, team or research group. -You can save the documentation of off-line use. +* *Share the documentation freely* in your organization, team, or research group. +You can save the documentation for off-line use. You can copy the information as it is and share it. You can even convert it to a different format, as long as the meaning and general look of the document stays the same. -E.g. you can convert the documents to make them readable for visually-impaired persons. +E.g., you can convert the documents to make them readable for visually-impaired people. Just make sure you give proper attribution in all such cases (see below). If you do this, you do not need to contact us or let us know. @@ -53,22 +53,22 @@ Provide a link to the original document whenever you can. * *Keep us free from any liability*. The documentation is provided "AS IS". -While we make reasonable effort to main quality of the documentation, we are people too. +While we make reasonable effort to maintain the quality of the documentation, we are people too. We can make mistakes, we can omit details, we may forget to update outdated information. Please bear with us. If you find a problem, let us know. We fill fix it as soon as possible. However, we make no guarantees. -If bet your fortune on the information in the documentation, it is your responsibility to make sure the information is correct, complete and up-to-date. +If you bet your fortune on the information in the documentation, it is your responsibility to make sure the information is correct, complete, and up to date. You are *not allowed* to: * *Copy significant part of the documentation for profit*. -You must not take our documentation, make a book out of it and sell the book. +You must not take our documentation, make a book out of it, and sell the book. If you want to do that, please contact us. -We can grant you a special license in exchange for reasonable royalties. +We could grant you a special license in exchange for reasonable royalties. You must not download documents from our site, convert it into a manual for your commercial project and deliver that to the customer. -Linking to our documentation is OK, copying, modifying and reformatting it for your project is not OK. +Linking to our documentation is OK, copying, modifying, and reformatting it for your project is not OK. If you want to do that, please contact us. We can agree on a license in exchange for a reasonable share of your profit. You must not use significant parts of our documentation to compile an operation manual for your service provider company. @@ -79,7 +79,7 @@ We can negotiate a reasonable license that can cover your use case. If you modify the documentation, we no longer know that it is correct. It may confuse or mislead the users. Documentation is not code, there is no simple way how to _test_ the documentation. -Therefore we want to keep some degree of control over the quality of the documentation. +Therefore, we want to keep some degree of control over the quality of the documentation. If you would like to reuse the documentation for your project, convert or translate the documentation, please contact us. We will find a way how this could work. We would just like to have an opportunity to assure the quality of the final result. @@ -104,13 +104,11 @@ If the thing that you are trying to do is usual, and it feels like an appropriat If it does not feel right, or you feel that you are pushing the boundaries too far, the best strategy would be to contact us. We will try to find a way how to cooperate. -NOTE: This license applies to _documentation_ only. -You are not allowed to use Evolveum sales, marketing and any other materials. +NOTE: This license applies to the _documentation_ only. +You are not allowed to use Evolveum sales, marketing, and any other materials. You are not allowed to use our trademarks. -You will need special license for this. -Such license is usually part of Evolveum partner agreement. - -== Source Code Licenses +You need a special license for this. +Such a license is usually part of Evolveum partner agreement. == Source code licenses @@ -172,6 +170,6 @@ However, the situation is entirely different when it comes to our services. Please feel free to use our software for any purpose that you want to. As long as you do not want anything from us, you do not have to pay anything to us. However, if you want anything from us, be prepared to compensate us for our time. -If you need a bugfix, if you want to consult your configuration, or even you want us to teach you about midPoint you have to pay a fair price. +If you need a bugfix, if you want to consult your configuration, or even you want us to teach you about midPoint, you have to pay a fair price. There are inherent _liberties_ in open source, but there is also a _cost_ to pay. -The license grants you the liberties of open source _software_, but it does not automatically grant you the time and attention of open source _engineers_. +The license grants you the liberties of open source _software_, but it does not automatically grant you the time and attention of open source _engineers_. \ No newline at end of file