Undesireable licenese

1

I’m currently overhauling how we process License information internally. I was rather suppressed to see that we’re allowing a lot of licenses indiscriminately. Basically our software accepts everything in this list: SPDX License List | Software Package Data Exchange (SPDX)

As you can see there are a lot of licenses in there which are neither approved by OSI nor FSF. I think we should only include apps which are released under a license approved by either OSI or FSF. Or should we be even more strict? What do you think? @contributors

Currently app license are distributed like this:

  • 9 - apps in our repo use a license without approval of either-one OSI or FSF
  • 64 - apps in our repo use a license not approved by OSI
  • 17 - apps in our repo use a license not approved by FSF
  • 72 - apps in our repo use a license without approval of both OSI and FSF
    (total apps 3117, there are also a couple public domian apps in our repo, I ignored those here)
    (edit: numbers also exclude disabled apps)
6 Likes
2

What’s the active state of these apps? Last update date?

1 Like
3

Thanks for doing this work, @uniqx! I think at the minimum, we should only accept licenses that are approved by either FSF or OSI. I think that’s important, since we’re not at all set up to review licenses. Personally, I’d like to see us require FSF approved licenses only.

8 Likes
4

Just wondering: shouldn’t those have popped up on rewritemeta during our YAML conversion? I didn’t encounter any such warning (or I must have missed it). I guess those are all older apps (no “new additions” of the last year)?

Apart from that: I agree with what Hans wrote. And go with his minimum for now, to keep the ball low. Remaining question: What to do with such apps when they’re “stale” (i.e. no longer maintained, so questions for upstream adjustments would go unanswered)? Move to archive? Delete? Ignore, and only apply this to new apps? (I’d go with “archive” here as a minimum)

1 Like
5

Currently fdroid lint just checks whether there’s a SPDX identifier in the license filed. But we don’t have any checks for licneses which are actually libre by the definiton of FSF or open source by the definition of OSI.

1 Like
6

@uniqx what about @Licaon_Kter’s question? Could you include the things
like whether Disabled: or ArchivePolicy: 0 versions are set?

I would just remove any Disabled: that don’t meet the minimum. For
active ones with non-free licenses, I agree, they should be archived.

1 Like
7

I think we have to be FOSS as we say F-Droid is FOSS. So let’s see what is really FOSS and if those licenses are applied to the definition.

8

Sounds great, I support this.

9

Oh, I should have been more specific, the numbers I initially provided exclude disabled apps. (Not sure about the archive status thou.)

10

Ok, then the last update date might be interesting, eg. like old apps that where added with prebuild JARs.

Are these modern, currently developed apps? Like @Izzy said… I don’t remember seeing odd licenses…

11

Here’s the list of apps we’ve got which do not use a FSF approved license:

{'bughunter2.smsfilter.yml': 'Fair',
 'com.atr.tedit.yml': '0BSD',
 'com.example.openpass.yml': 'BSD-2-Clause',
 'com.foxykeep.lifecounter.yml': 'Beerware',
 'com.gladis.tictactoe.yml': 'Beerware',
 'com.hermit.btreprap.yml': 'CC-BY-SA-3.0',
 'com.longevitysoft.android.appwidget.hstfeed.yml': 'CC-BY-NC-SA-3.0',
 'com.powerje.nyan.yml': 'CC-BY-NC-3.0',
 'com.rj.pixelesque.yml': 'CC-BY-NC-3.0',
 'de.naturalnet.mirwtfapp.yml': 'MirOS',
 'de.naturalnet.zahnarztgeraeusche.yml': 'MirOS',
 'edu.cmu.cs.speech.tts.flite.yml': 'MIT-CMU',
 'fr.ornidroid.yml': 'CC-BY-NC-4.0',
 'org.dyndns.warenix.web2pdf.yml': 'AML',
 'org.gfd.gsmlocation.yml': 'CC-BY-SA-3.0',
 'org.openobservatory.ooniprobe.yml': 'BSD-2-Clause',
 'pl.sanszo.pcis.yml': 'NPOSL-3.0',
 'uk.co.keepawayfromfire.screens.yml': 'BSD-2-Clause'}
3 Likes
12

Okay, @hans just found out that SPDX is buggy. They list BSD-2-Clause as non-FSF approved. But FSF sais it is: Various Licenses and Comments about Them - GNU Project - Free Software Foundation

edit: I opened an issue about this: spdx/license-list-data#52

4 Likes
13

You already figured about the BSD-2-Clause (which actually is FOSS). From your list, I’m positively sure the CC-BY-NC ones are not (due to the NC) and a plain CC-BY should be. Just from gut feeling, a CC-BY-SA should be pretty much FOSS, and quite close to GPL (you must give credits to the original author and share under the same terms). Not sure which ones (3.0/4.0) would be approved here if that list has errors.

No idea about the others.

14

CC 4.0 licenses are approved by FSF and OSI, older versions are not. And NC is clearly non-free since that stands for Non-Commercial.

MIT-CMU should be free software, since its a variant of MIT. SPDX gives Python Pillow as a reference for that license, which is included in Debian, so its DFSG-free. Seems like that’s a SPDX bug too. Fedora lumps it in as an MIT variant: Licensing:MIT - Fedora Project Wiki

1 Like
15

Isn’t allowing only licenses approved by the FSF, leaving OSI-approved-only ones out, a bit overzealous, considering that today some of the most popular apps in F-Droid, namely OsmAnd, have a dodgy license that is only free if you take the legal view that the licensor is making some of their own terms null and void, and there’s proprietary copyright claimed not even just on the assets, but on the UI layout itself?

I think OSI approval (plus FSF, of course) is a very acceptable bar to set.

16

I checked (tried to check) the license for all the apps @uniqx listed:

  • bughunter2.smsfilter’s source code is offline. The Fair license consists of one sentence besides a warranty disclaimer, and I don’t understand it-- is “instrument” supposed to refer to the license? It’s also unspecific in the way that it doesn’t explicitly grant the four freedoms, it only permits “Usage”, which sounds like freedom to use is granted, but studying, sharing and improving might not be.

Usage of the works is permitted provided that this instrument is retained with the works, so that any entity that uses the works is notified of this instrument.

  • com.atr.tedit.yml: 0BSD, which the FSF doesn’t list but I suppose this as the only sentence besides a warranty disclaimer qualifies as free software:

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.

  • com.example.openpass: BSD-2-Clause, which as discussed is approved by the FSF
  • com.foxykeep.lifecounter, com.gladis.tictactoe: Beerware should qualify as an Informal license

You can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return.

  • com.hermit.btreprap: CC-BY-SA, however at least the README doesn’t specify a version code:

Bluetooth RepRap is ditributed [sic] under the Creative Commons - Attribution Share-Alike license. No animals were harmed in the creation of this software.

This is a little difficult, considering that Creative Commons besides CC0 does not consider itself a software license. We can’t really be sure that the source code has actually been freed.

There is also a new Non-Profit OSL 3.0, identical to OSL 3.0 except that: Under Non-Profit OSL 3.0, Licensor disclaims certain warranties and limits liability from certain types of damages. Those differences are summarized in § 17 of the Non-Profit OSL 3.0, a section that does not appear in OSL 3.0 or AFL 3.0. Because of § 17(a), only non-profit distributors may use the Non-Profit OSL 3.0 license.

The other minor differences among OSL 3.0, AFL 3.0 and Non-Profit OSL 3.0 are highlighted on the copy of OSL 3.0 that is posted at www.rosenlaw.com/OSL3.0-comparison.pdf.

  • uk.co.keepawayfromfire.screens: BSD-2-Clause

I see a direct reason to act concerning com.longevitysoft.android.appwidget.hstfeed, as it is not licensed under a free software license, and fr.ornidroid, unless someone can find a place a license for it is declared.

I have opened a merge request to fix the incorrect license fields I noticed above.

5 Likes
17

“public domain apps” are undesirable, not in the least because that isn’t a license.
Just writing “public domain” doesn’t do anything in most jurisdictions, meaning it (most often) falls under the authors copyright by default. As such, nobody can contribute to it under the same terms, you need to ask to use it, etc. And before we get there, aping public domain in a copyright license does not make it so, even if you call it ~public domain license or somesuch.

1 Like
18

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.