|
|
|
# Development
|
|
|
|
|
|
|
|
The Fenrir project is made of 3 different subprojects:
|
|
|
|
- [libFenrir](https://www.fenrirproject.org/Fenrir/libFenrir)
|
|
|
|
- Fenrir (not yet started)
|
|
|
|
- Fenrird (not yet started)
|
|
|
|
|
|
|
|
Plus the [libRaptorQ](https://www.fenrirproject.org/Luker/libRaptorQ) library, which could be considered a separate project.
|
|
|
|
|
|
|
|
Choose the one you want to contribute to, sign the [CLA](CLA) (one for all of them) and start coding :)
|
|
|
|
|
|
|
|
## Contacts
|
|
|
|
|
|
|
|
Use the forums or mailing lists dedicated to each subproject to discuss everything. I am also on IRC at **#fenrirproject** on **Freenode** if you need me. Mail me @ luker _at_ fenrirproject.org if you want.
|
|
|
|
|
|
|
|
## Copyright & License
|
|
|
|
|
|
|
|
For now If you want to send any code you need to write me a [CLA](CLA) (the CLA is the same for all subprojects).
|
|
|
|
|
|
|
|
This will grant me full control over the code, leaving you the copyright and the possibility to use it elsewhere.
|
|
|
|
|
|
|
|
The CLA assigns all the right to **me**.
|
|
|
|
In a couple of months I will start a foundation, technical committee or something, and that will be the one that gets all the rights on the code.
|
|
|
|
If you sign now, you won't have to sign it again, I will simply sign the document myself and all my rights will be transferred to the foundation/commitee.
|
|
|
|
|
|
|
|
I will never make this project close source, but this is why I need this CLA:
|
|
|
|
|
|
|
|
The project will be split in three parts:
|
|
|
|
* **libFenrir**, LGPL3 license, dual-licensing for those who need it.
|
|
|
|
* **Fenrird**, GPL3 in dual-licensing for those who need it.
|
|
|
|
* **Fenrir**, GPL3 in dual-licensing for those who need it.
|
|
|
|
|
|
|
|
The CLA comprehends also the [libRaptorQ](https://www.fenrirproject.org/Luker/libRaptorQ) library, so you won't need to sign too many things.
|
|
|
|
|
|
|
|
The rationale is simple:
|
|
|
|
* **libFenrir**: LGPL3 grants us linking flexibility, and maintains the core of this project free-software.
|
|
|
|
* **Fenrird**: this can be GPL3. I still have to think to a scenario where GPL3 is a bad idea. Remember, this is the main authentication server. You won't run it on your computer.
|
|
|
|
* **Fenrir**: This will be a qt5 client in GPL3 that you can install on your computer to easily manage all the accounting information.
|
|
|
|
|
|
|
|
Dual-licensing will be available for all 3 parts, **libfenrir**, **Fenrird**, **Fenrir** and for **libRaptorQ**, so if you really need it, convince me and I can grant a license.
|
|
|
|
|
|
|
|
### Why dual licensing?
|
|
|
|
|
|
|
|
I don't plan on making money from dual-licensing, and won't make this closed source.
|
|
|
|
|
|
|
|
My main objective is to keep this software free. But a lot of people do not like the LGPL3 and much less the GPL3.
|
|
|
|
|
|
|
|
Their reasons aside, I still want them to be able to use this project. The other licenses will need to be defined, but what I am aiming towards is a new license that
|
|
|
|
* protects from **patents litigations**.
|
|
|
|
* grants **usage** on closed source usage, optionally with linking for libfenrir/libRatporQ, without "tivoization" clauses.
|
|
|
|
* makes it so the one who gets the license can **not modify the source** code (their contributions must be LGPL3)
|
|
|
|
* deterministic builds must be used and the data to reproduce them must be public
|
|
|
|
|
|
|
|
Such a license does not seem to exist today, so I will need help to design it, especially from lawyers. The whole process will be public, I hope a bit more open than the GPL3 discussions. If needed, there could be discussions of making the availability of such a license something permanent (I'd like to, don't know how at the moment).
|
|
|
|
|
|
|
|
This seems to restrict the development a lot for those who receive the license. I am willing to dedicate new git-branches on the main project and assign to them the maintainer the company will require.
|
|
|
|
|
|
|
|
I am trying to do this to avoid code-duplication between projects, forks of bsd-like projects that become closed, and to still maintain a single-point of development, even with differences of maintainers and platform.
|
|
|
|
|
|
|
|
One of the thing that pushed me to do this is that the Apple market and products seem to really dislike including GPL and LGPL software, and their two reasons seems to be the **tivoization** clause and the fact that the need to modify binaries to **add signatures** to cryptographically-verify the provenience of that software.
|
|
|
|
|
|
|
|
I don't care that much about tivoization. I just want to be sure everyone is running a safe version of what I hope will be a widespread security protocol. If a vendor stops updating a platform, you won't get much out of it anyway. If your problem is having a free platform, this is the wrong place to enforce it.
|
|
|
|
|
|
|
|
All of this should be handled by more than a single person, so a foundation or something similar will probably be created.
|
|
|
|
|
|
|
|
## Coding Style
|
|
|
|
|
|
|
|
This is not well defined yet. I am aiming on something in between LLVM coding style and the Linux kernel coding style, for now a few things are decided:
|
|
|
|
* **C++11** is the standard.
|
|
|
|
* **no exceptions**: I know, it kinda sucks for you, but error management is still easy and we might speed up things a little.
|
|
|
|
* **no garbage collectors**: I don't even want to hear about this things.
|
|
|
|
* **no struct**: just use classes with public methods. For the compiler it's the same anyway.
|
|
|
|
* comments are fine in both C89 and C++ style. But please use the '//'
|
|
|
|
* **no standard types**: that is, do **NOT** use "int". Use "int32_t". It's better for portability.
|
|
|
|
* **80 colums**: This way I can keep 4 files on one screen, thankyouverymuch.
|
|
|
|
* **4-space tabs**: use spaces, not tabs, 4-space equivalent. Rationale: portability between editors.
|
|
|
|
|
|
|
|
In the future we might start to use clang-format.
|
|
|
|
|
|
|
|
In general I'm trying to write C++11 code. But I've just started learning the C++11 variant, and I usually code in C, so I might be missing lots of things. Please point them out :)
|
|
|
|
|
|
|
|
## Sending a patch:
|
|
|
|
|
|
|
|
**After** you have signed a [CLA](CLA) you can email me @ luker _at fenrirproject.org.
|
|
|
|
|
|
|
|
Or better, write to the [mailing list](https://www.fenrirproject.org/lists) of the project you are contributing to:
|
|
|
|
|
|
|
|
You can use the "git format-patch" to generate the required patch from your local repository.
|
|
|
|
|
|
|
|
In the future I will set up a github/sourceforge repository automatically synced with my main one, and you can use those platform to send me pull requests.
|
|
|
|
Still, use this website for error reporting. signing with github accounts is already active.
|
|
|
|
|
|
|
|
I always generate my commits with "git commit -sS", so that its always signed. All tags are signed. The master branch can only have signed merges. Please check those.
|
|
|
|
|
|
|
|
## General
|
|
|
|
|
|
|
|
### The environment
|
|
|
|
|
|
|
|
Everything is developed under GNU/Linux. Currently I'm using qtcreator for its C++ support, clang as a compiler. As soon as I can I will switch to clang's libc++ as the default library.
|
|
|
|
|
|
|
|
Since I work under ArchLinux I might have a newer version of some packages, but I'll try not to be too bleeding-edge on the requirements. The project won't be considered complete for a while, so for now: the newer, the better.
|
|
|
|
|
|
|
|
Compatibility with the latest red-hat/contos 7 is required, though.
|
|
|
|
|
|
|
|
### Linking
|
|
|
|
|
|
|
|
If you contribute new features, please don't link to too many libraries. Try to avoid it. We already have the libunbound, libevent, and will have to link libRaptorQ, openssl/gnuTLS for some crypto algorithms, and maybe libcds.
|
|
|
|
|
|
|
|
That's already enough. If you have to link to something, please try to be sure it is something portable, as later in the development we will have to port this project to **BSD and Windows
|
|
|
|
|
|
|
|
## Windows porting
|
|
|
|
|
|
|
|
I have no experience of programming under windows, but I'm using standard libraries and calls, so it shouldn't be too difficult.
|
|
|
|
|
|
|
|
Aside from that, it should only be a different socket API.
|
|
|
|
|
|
|
|
All the code is under the C++11 standard, so as long as the compiler supports it, it should be fine (meaning no visualc++ support?). |
