Copying code, and especially copying the entire application without mentioning the source, is disrespectful to all contributors. Over the past few years, many products based on Organic Maps have appeared on the market, and not all of them, unfortunately, mention our project to their users.

Fair enough.
I bet you've contacted them and required additions of an attribution notice as per the license?

If you did and they haven't complied anyway, then adding this text to the README won't help unfortunately :)

The map files are mostly reformatted databases of OpenStreetMap data, which is under ODbL and requires its own attribution.

This seems completely missed by the new legal stuff.

warning: I am not a lawyer

Over the past few years, many products based on Organic Maps have appeared on the market, and not all of them, unfortunately, mention our project to their users.

note that Apache License, Version 2.0 seems to be not blocking this as notice requirement can be fulfilled without making it noticeable to users.

is this PR relicensing Organic Maps from Apache License, Version 2.0 to custom derivative of this license? If yes, then maybe earlier claims about license also need to be changed?

or is it adding non-binding request to credit Organic Maps in a visible place? In addition to what is required by Apache License, Version 2.0?

(Is Organic Maps mentioning MAPS.ME in such manner?)

is this PR relicensing Organic Maps from Apache License, Version 2.0 to custom derivative of this license?

The NOTICE file is informational and can not change the license, see https://www.apache.org/licenses/LICENSE-2.0.html#redistribution

You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

To change the license OM has to change the text in the LICENSE file.

So this extra attribution request is non-binding and is like a suggestion / recommendation.

Can you clarify whether this PR intends to add nonbinding request?
Or is it intending to change license away from Apache License, Version 2.0 to something different? (as allowed by Apache license)

warning: I am not a lawyer

I also wonder who is the copyright holder for the "compiled binary files"?

Probably the one who hit a button / started a script to generate them?

Ah, so we shall add the NonFreeAssets anti-feature to F-Droid, yes?

Yes, if the explicit attribution requirement is not compatible with the FDroid free license philosophy.

Not sure I follow.

You've set a different license for the maps, right?

Maybe I'm lost in translation?

That licence is not-FLOSS, hence "NonFreeAssets"

Did I get this right?

• Yes, a different license for the maps.
• Is "CC-BY" license FLOSS or not? Our current short license text has the same meaning.

Is "CC-BY" license FLOSS or not?

depends, see the list at https://spdx.org/licenses/ some are not

which one is this exactly?

Our current short license text has the same meaning.

it does not work like this

you need to say "It's licensed under CC-BY-WHATEVER" and have that actual text in the LICENSE file, not your own made up text

Thanks for the link. Probably, we will choose one from this list next time.
So, your point is that any custom license (not from the FSF or OSI-approved list) is not FLOSS, regardless of what is written there?

Look at the header of the table in https://spdx.org/licenses/, then look at the license that you seek, if one or both last columns have a Y, then it's considered FLOSS, if not... not

eg. CC-BY-SA-4.0 and CC-BY-4.0 are fine, the rest... not so much

Ok, but you didn't answer: any custom license is considered not FLOSS (by FDroid), regardless of what is written there?

From my perspective, our license states the same as CC-BY-4.0, Section 3(a)(1), indicating the specific place where we want to see the attribution.

Can you clarify whether this PR intends to add nonbinding request (for source code)?

Or is it intending to change license away from Apache License, Version 2.0 to something different? (as allowed by Apache license)

current situation is quite confusing, and I am curious what you intended to do here

Our current short license text has the same meaning.

it does not work like this

+1

An you can easily end with so called "crayon license" that has unwanted side-effects, does not work like it was intended or is otherwise broken.

warning: I am not a lawyer

@vng imho, yes, your custom license will be considered non-FOSS

If it matches one of the existing ones, that would be nicer ;)

Telling if a particular license is FLOSS or not takes effort and skill to analyze. Most people would just prefer to use known authoritative lists like from FSF/OSI and might prefer to stay away from unknown custom licenses and/or consider them non-FLOSS by default as its a much safer choice.

E.g. I've actually expected all CC-BY licenses to be FLOSS (disclaimer: I haven't read them though), I'm quite surprised to see the most of them are not! And even CC-BY-4.0 is not OSI approved!

So there are some important details in the license text which could be not obvious for laymen.

TBH as you've left the list of compiled binary files open ("including but not limited to .mwm map files") now its not even clear whether its possible to e.g. fork OM and have it build and run without such files and hence without triggering the new OM data license which is very well might be non-FOSS.
(e.g. I'm not sure that the OM Apache 2.0 code contains all the tools/scripts to produce/compile all necessary binary files from the sources)

OM Apache 2.0 code

it is also possible that after this modification Organic Maps is violating Apache 2.0 license or at least going against what it strongly recommends. And that part of NOTICE is misleading, deliberately or not.

Note this part of license

You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

and this PR added

To respect the work of all project contributors and to comply with license attribution terms, this notice should appear in user-visible locations, such as the product’s “About” and “Main Menu” screens.

"to comply with license attribution terms" looks to me like something that may easily be construed as modifying the License.

To me it looks like this part of license was intended exactly to stop confusion-generating stuff like this one where codebase pretends to be Apache 2.0 but you have trap in form of much stronger license terms. Note that as I understand Apache 2.0 allow to take code into project on a different license, so this kind of tricks is not needed.
If you decided that you do not want code to be freely reusable and forkable, then you can change to a different license. Just please, make clear that it is not Apache 2.0 license project anymore.
Rather than adding this kind of things to NOTICE (that probably may be freely ignored anyway)

warning: still not a lawyer

@licaon-kter Ok, we will consider using CC-BY-4.0 for assets.
@matkoniecz Source code is under Apache 2.0

@matkoniecz Source code is under Apache 2.0

yes, but with confusing NOTICE file that has

to comply with license attribution terms, this notice should appear in user-visible locations, such as the product’s “About” and “Main Menu” screens

part.

which either:

(1) redefines Apache 2.0 license where NOTICE content may be present, going against Apache 2.0 license with "provided that such additional attribution notices cannot be construed as modifying the License."

(2) does not need to be followed at all, making "to comply with license attribution terms, this notice should appear" highly misleading (and this NOTICE text must be preserved and will be extremely hard to remove in future)

both seem undesirable, no matter what is the goal of this changes.

warning: I am not a lawyer

EDIT: or maybe it is a request to add an attribution rather than an attribution notice, so therefore "must include a readable copy of the attribution notices contained within such NOTICE file" allows derivative works to skip this request?

Ok, but you didn't answer: any custom license is considered not FLOSS (by FDroid), regardless of what is written there?

It takes a lawyer well-versed in copyright to even attempt to determine that, so vast majority of people will just go with authoritative source like FSF/OSI, e.g. as simply selectable on https://spdx.org/licenses/.

Common wisdom with licenses is as with encryption -- unless you're world renowned expert in the field, please do not try to roll your own, because it will fail miserably in hundred ways completely unfathomable to you.

I would thus highly suggest that OM chooses one of common FLOSS licenses instead of trying to roll their own.

If OM chooses to do a different FLOSS license, it is within their right to do so (as long as new license is compatible with previous ones, of course), but if they expect the rest of the world to recognize them as FLOSS, they would need to submit for OSI or FSF (or some other well-accepted org) to approve their license. (Note that this might - or might not - come with some cost, and will certainly take some time).

I would still suggest against custom FLOSS license, as license proliferation is a bad thing to be avoided if at all possible.

And of course, going for non-FLOSS license (unintentionally, or worse, intentionally), while legal, is the least attractive option for community...

@matkoniecz Source code is under Apache 2.0

@vng then you should remove those additional attribution notices from NOTICE file (used with Apache2.0 for code), as you're failing Apache 2.0 4.(d) section:

(d) You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

As they add additional requirements not present in original Apache 2.0 license, they can be construed as modifying the Apache license for code (IMHO, IANAL). Having them in DATA_LICENSE.txt should be fine from that point, though.

Note that DATA_LICENSE.txt has another issue; as it does not follow ODbL requirements. When putting a file specifying how the data must be attributed, you should list all requirements, not just some of them which suit you the best. IOW, both "OpenStreetMap" and "Organic Maps" must be attributed, not just OM.

@licaon-kter Ok, we will consider using CC-BY-4.0 for assets.

It would be great to do that before a new version of OM is released with current license (in order for tainted release to not get F-droid antifeature until the issue is fixed with following release). (see above #10987 (comment))

Actually this merged commit has made it to the 2025.08.06-4 release already (its going to be built in the current F-Droid build cycle).

fyi https://gitlab.com/fdroid/fdroiddata/-/commit/d2cc063994082d92b2ca98a8746c0ac8d4743d89

ping us when this changes

/LE: fixed ink

Note that DATA_LICENSE.txt has another issue; as it does not follow ODbL requirements. When putting a file specifying how the data must be attributed, you should list all requirements, not just some of them which suit you the best. IOW, both "OpenStreetMap" and "Organic Maps" must be attributed, not just OM.

I've created a new issue regarding the possible violation of ODbL.

#11138