licensing under "oemof developer group"

[Ludee]

I'm sorry to bring you more or less bad news.
After an intensive meeting with FSFE in Berlin we have certainty that "oemof developer group" is not a legal option to host the copyright! I put this issue on the agenda because I think this is quite important for further developments.

Decided on the dev meeting:

Decision: Authorship lies with the "oemof developer group"

Short answer: It does not lie there! It has to be a real or legal person.

Here is an extract from the mail Robbie and I send over the openmod:

Legal matters / Project location
the hosting of projects on neutral terrain is advisable, particularly if several institutes are involved

1. one approach is to set up a legal entity for the project (perhaps a German eingetragener Verein (eV) or incorporated society) and use contributor license agreements (CLA) to assign rights
   [my comment: notwithstanding, there are downsides to this approach, including substantially reduced appeal for casual contributors, increased administrative overhead, more formalized procedures, and the need to canvas and define legal purposes at the outset] [LH: I totally agree with all arguments. An advantage would be an totally independent developer group. Perhaps there are even more? ]
2. Second approach is to keep the copyright with each institute (or company/ persons) in the code (header of each script). But use the “developer group” for communication (GitHub, Website, etc.) [LH: This was the preferred approach by FSFE, because it combines advantages]
3. Additional option is to give the copyright to an already existing entity that operates as an umbrella organisation. One example given by Matthias is the Apache Software Foundation (https://apache.org/index.html#projects-list) [LH: Is there any experience with this kind of approach? Pros and Cons?]

[uvchik]

So we have to found a foundation or association 😄

[simnh]

we already decided, that we don't care about that for now, because we will never charge anyone anyway...

but a association like: 'oemof e.V.' would be nice !

[ckaldemeyer]

we already decided, that we don't care about that for now, because we will never charge anyone anyway...

but a association like: 'oemof e.V.' would be nice !

I guess the question is different: is our license still valid at all if we do not have a legal body?

In the case it is not, the code legally must/will be treated as if there was no license at all.

[jnnr]

Even if it is still half a year to go and we may proceed with this issue in the meantime I already put this as a first topic on the agenda of the dev-meeting in May 2018.

[ckaldemeyer]

Even if it is still half a year to go and we may proceed with this issue in the meantime I already put this as a first topic on the agenda of the dev-meeting in May 2018.

👍

[ckaldemeyer]

I guess the question is different: is our license still valid at all if we do not have a legal body?

In the case it is not, the code legally must/will be treated as if there was no license at all.

@Ludee : Do you know anything about the legal situation here?

[Ludee]

I guess the question is different: is our license still valid at all if we do not have a legal body?
In the case it is not, the code legally must/will be treated as if there was no license at all.
@Ludee : Do you know anything about the legal situation here?

From my understanding, the license itself is valid.
But we prevent that any user is able to fulfil the license obligations (attribution).

The copyright of each script/line (still) lies with the author (or in case of an employment with the employer/institute). We are able to give the copyright to somebody else, but it has to be a real or legal body. Because "dev group" is neither, the copyright shift is invalid.

So we state the wrong copyright owner which leads to incorrect attribution in case of code usage.
In my understanding, this is only a problem if somebody takes out code, makes a fork, etc.
If you just clone/copy the repo and run oemof, you don't have any obligations. Only if you redistribute and reuse code.

Another comment on the Verein was that it is nearly the same, because you need real people to found it. These people are employed by universities, companies and institutes. So in order to be transparent, you should state what background you have.
The shortcut is the open_eGo license model, each line and script stays with the copyright of the person or institute. If you take out code, you need to attribute the authors of that part. It is even more transparent.

But founding a Verein is fun as well:

"Treffen sich drei Deutsche... und gründen einen Verein"

[uvchik]

A foundation/association is additional work but I like the idea of an legal person and the possibility to collect money that way.

BUT I will not have the time to found one.

I do not like the idea of giving the copyright to one person. In my opinion It does not make sense for our project, that might be different in eGo.

[Ludee]

The shortcut is the open_eGo license model, each line and script stays with the copyright of the person or institute.

I do not like the idea of giving the copyright to one person. In my opinion It does not make sense for our project, that might be different in eGo.

Sorry, that was not precise. In eGo, there are only "paid developers" so the copyright is with RLI, ZNES, DLR (NEXT). So every script has a different header. Sometimes just one, sometimes all three, and with different orders. It grows with time.

I like both, option 1 and 2. I have some experience with founding different e.V. We even managed to become "gemeinnützig" with one. I know this will take time, dedication and money (fees, notary, bank account, insurance).
So FSFE strongly supported option 2 for software projects. We just have to find out who participated in each script and change the header accordingly. Then the issue is solved.

You can also collect and spend money without an e.V. ;)