Commit graph

9 commits

Author SHA1 Message Date
806db414dd Copyright: clarify and simplify the file headers
* Lumiera source code always was copyrighted by individual contributors
 * there is no entity "Lumiera.org" which holds any copyrights
 * Lumiera source code is provided under the GPL Version 2+

== Explanations ==
Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above.
For this to become legally effective, the ''File COPYING in the root directory is sufficient.''

The licensing header in each file is not strictly necessary, yet considered good practice;
attaching a licence notice increases the likeliness that this information is retained
in case someone extracts individual code files. However, it is not by the presence of some
text, that legally binding licensing terms become effective; rather the fact matters that a
given piece of code was provably copyrighted and published under a license. Even reformatting
the code, renaming some variables or deleting parts of the code will not alter this legal
situation, but rather creates a derivative work, which is likewise covered by the GPL!

The most relevant information in the file header is the notice regarding the
time of the first individual copyright claim. By virtue of this initial copyright,
the first author is entitled to choose the terms of licensing. All further
modifications are permitted and covered by the License. The specific wording
or format of the copyright header is not legally relevant, as long as the
intention to publish under the GPL remains clear. The extended wording was
based on a recommendation by the FSF. It can be shortened, because the full terms
of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
05aaa74422 MERGE Doxygen clean-up done during the last months 2017-04-01 23:59:00 +02:00
2535e1b554 DispatcherLoop: no timeout turnaround necessary in idle state
...since the session loop will be notified on any change via the
interface, adding a command will activate the loop, and the builder
timeout is handled separately via the dirty state. So there is no
need to spin around the loop in idle state.

As a aside, timeout waiting on a condition variable can be intentional
and should thus not be logged as an error automatically. It is up to the
calling context to decide if a timeout constitutes an exceptional situation.

It is always a trade-off performance vs. readability.
Sometimes a single-threaded implementation of self-contained logic
is preferable to a slightly more performant yet obscure implementation
based on our threadpool and scheduler.
2017-01-07 02:46:34 +01:00
8e6936d0ad Doxygen: fill in missing file level headlines for the Library 2016-11-08 13:18:05 +01:00
dbc75fac7d Doxygen: we missed the plain C code 2016-11-03 18:26:43 +01:00
6822a9e2fb DOC: reorganise the Doxygen configuration and structure
- upgrade the configuration to a current version
- provide a frontpage with cross-links to other documentation
- define a set of modules; relevant classes and files can be
  added to these, to create a exploration path for new readers
- fix a lot of errors in documentation comments
- use a custom configuration for the documentation pages
- tweak the navigation, the sections and further arrangements
2013-10-25 06:34:38 +02:00
3f1b7651e9 GPL header whitespace 2010-12-17 23:28:49 +01:00
Christian Thaeter
c15f2247d7 integrating nobug context passing
Somewhat more intrusive than the previous patch,
adds contexts everywhere except for sync.hpp where only default ctors
are used.
2010-01-23 01:40:27 +01:00
Christian Thaeter
b232a4f9f0 errors for locking
* add a 'unknown' error to the error system as fallback
 * lockerror.c|h define all errors which can happen due locking
 * lumiera_lockerror_set() translates posix errors to lumiera errors
 * remove stale errors from sectionlock.h
2010-01-13 00:10:33 +01:00