How to address common FOS license problems? - About creditstealing and ruthless cashcowing

Question

I am a hobbyist software developer and had some disputes with a group of passionate FOSS proponents.

Although they didn't manage to convince me, It made me think about what the issues with FOSS licensing are (from my point of view).

And now I am asking myself if I can put things under a FOSS license without suffering from these issues.

The first issue is that I don't want anyone to make money with my software.

This one is adressed easily.

The second issue, "credit stealing", is described below:

It is difficult to solve using licenses that allow derivatives, because it's hard to define.

I have drafted the following license to address both issues:

===================================================================
Copyright and License of this work:
===================================================================
Copyright (C) date pseudonym : name <mail>

This work comes without any warranty,
to the extent permitted by applicable law.

License:
0.
you are allowed to use this work for personal use.
1.
A "derivative work", below, means either the work or any derivative work under copyright law.
Especially, if this work is a text or program, any translations of it into another language are seen as derivative works as well.
the "creator", below, refers to the single author of this work.
2.
you are allowed to create derivative works for personal use.
3.
You are allowed to redistribute derivative works non-commercially, as long as you give "proper credits", as explained below, to the creator of this work.
This means that you are not allowed to redistribute work based on this work if this causes you to gain money by any means.
giving proper credits to the creator of this work at a time when distributing a derivative work means that:
I.
given the derivative work that is distributed, anyone must be able to find out that it is based on this work and thus partly made by the creator of this work.
II.
shown any of the "places" where the work is distributed, anyone must be able to find out that it was based on this work and made by the creator of this work.
III.
If the creator of this work "requests it properly" (as defined below), you must be able to proove that the credits are "perceived enough".
You have to proove this using the following procedure.
let n be the number of times your derivative work got distributed during the week the creator sent his request.
if n can't be evaluated, n is estimated to be 100000.
You have one month time to proove that (n/10)+1 (rounded down) people you distributed the derivative work to noted that the derivative work contains this work.
If that month passes and you fail to proove that, you are not allowed to distribute the derivative work anymore.
Such a request by the creator is not called "requested properly", if you provided a legal way to contact you at the expense of less than 1 euro in your derivative work in a way that a human can find it easily, and the creator didn't use that way aldough it was available to him/her, or if the creators request was not cognizable as such or didn't contain the date it was sent.
If the way of contacting you you provide the creator of this work
In all other cases, such a request is called requested properly.
4.
You are allowed to offer services provided by derivative works (softwares that are derivative works) non-commercially, as long as you give "proper credits", as explained below, to the creator of this work.
This means that you are not allowed to offer services provided by software based on this work if this causes you to gain money by any means.
giving proper credits to the creator of this work (at a specific time) when offering a service provided a derivative work means that:
I.
given the information available to these who use the service, anyone must be able to find out that the software used is based on this work and thus partly made by the creator of this work.
II.
If the creator of this work "requests it properly" (as defined below), you must be able to proove that the credits are "perceived enough".
You have to proove this using the following procedure.
let n be the number of times the service provided by your derivative work got used during the week the creator sent his request.
if n can't be evaluated, n is estimated to be 10000.
You have one month time to proove that (n/100)+1 (rounded down) people who used the service provided by the derivative work have noted that the derivative work contains this work.
If that month passes and you fail to proove that, you are not allowed to offer services provided by the derivative work anymore.
Such a request by the creator is not called "requested properly", if you provided a legal way to contact you at the expense of less than 1 euro in your derivative work in a way that a human can find it easily, and the creator didn't use that way aldough it was available to him/her, or if the creators request was not cognizable as such or didn't contain the date it was sent.
If the way of contacting you you provide the creator of this work
In all other cases, such a request is called requested properly.

However, I don't think that this draft is particularly useful.

I just added it to this post to point out what I want to achieve in more detail.

Now my questions are:

Is there a license that already adresses those problems and solves them?

If not, can you draft me one?

Answer 1

Making your software available under free and open source terms means the legal terms under which you make your software available meet certain standards (namely, the FSF's four freedoms and the OSI's Open Source Definition). Those definitions allow commercial reuse/distribution, so any legal terms that don't allow commercial reuse will not fall within the definitions of free or open source software licenses. I point this out first to highlight that you and the FOSS proponents you argue with have different goals, and you aren't likely to convince one another of anything. One of your fundamental tenets (disallowing commercial reuse) is in conflict with one of their fundamental tenets (allowing commercial use). Understanding this disagreement might help you have fewer or more constructive arguments.

In any case, no FOSS license will meet your non-commercial requirement. The traditional way this is resolved in practice is by using a copyleft license like the GNU GPL, which requires that all downstream distribution must be under identical permissive terms, with source code. This ensures no one has a monopoly on any changes, so the commercial value of any public distribution approaches zero as the software becomes universally available.

As for the problem of attribution, virtually all FOSS licenses require the preservation of copyright notices, so your name must remain attached to the software. The Apache License 2.0 goes even further and allows you to specify a NOTICE file that must be preserved in a specific way:

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file... in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear.

I would advise against drafting your own license without consulting a legal professional. Many jurisdictions have rules about how licenses are interpreted, what terms are possible or impossible to enforce, how external statements and intent interact with license text, etc. Any license should be drafted by someone with a full awareness of such legal issues so your license functions as intended.

As for your specific suggested terms, I would not personally feel comfortable redistributing software under such terms because I do not know how I would go about proving that any number of "people... noted that the derivative work contains this work". Even if this happens to be true for my distribution, I don't know how to rigorously prove what a user did or did not note. Furthermore, if the methodology of proving this is at all onerous, a licensor could easily harass me by constantly requesting I produce this proof, e.g., on monthly basis. I expect many other people -- whether they are proponents of FOSS licenses or not -- would stay away from using software under such terms for similar reasons.

I'll also note that placing terms on how the software may be executed (versus how it may be modified or distributed), as you do in section 4 for services, falls outside the capability of a copyright license and will need to rely on a different legal instrument. Consult a lawyer to ensure this is done correctly.