GpsMid

Hi, I tested the Osmand Android application on a trip, and it seems useful, and has some features which would be nice to use on GpsMid as well. Examples are native Android settings interface, location updater (to a server), biggish arrows for showing navigation instructions, ability to use raster maps, countours at least come to mind. Rather than reinvent the wheel and rewrite those features (many of which are already in GpsMid feature requests) into GpsMid, it would make sense to see if code from Osmand (or other sources) can be used in GpsMid, if possible. Osmand is GPLv3 software, while GpsMid is GPLv2. It seems v2 and v3 are not compatible, see: http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility "Is GPLv3 compatible with GPLv2? (#v2v3Compatibility) No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2. However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits." What do you think about changing the license to GPLv3 or GPLv2 or later? Many years ago, I took a look and decided (like has been decided for GpsMid) that GPLv2 looks relatively clear and preferable. However the goals of GPLv3 seem good, and I don't think back then there was any specific part of GPLv3 which made me prefer GPLv2. I think I'd have no problem changing my code to GPLv3 currently. But to change GpsMid to GPLv3, we'd need OK from all authors of copyright-protected parts (meaning that e.g. a one-line patch probably is not copyright-protected, so permission from author of a one-line patch isn't legally necessary, can't say at what size the limit is though). What do you think of a possible license change to GPLv3?

Hi jkpj. Sounds like this would be (on a small scale) the same as the change from CC-BY-SA to ODbL that OSM is currently undergoing. ;-) But let's just look at it: SunCalc and the ZIP utils both have this statement: "...either version 2 of the License, or (at your option) any later version." So they would be no problem. JMicropolygon is LGPL or Apache license, not sure how that would fit but it would probably be OK also. Regarding our own changes we would have to get the OK from all contributors (including those who supplied patches, as you mentioned) but I think there aren't too many. I haven't checked yet if it would be OK for me to relicense my contributions under GPL 3. But I think the other aspect of this is much more important: Is it realistic to integrate code from an Android only app into GpsMid? It would probably be Android only, which would decide on the question whether we continue to maintain both J2ME and Android or not, wouldn't it? Even if the code was not very platform specific, Have you checked this yet? I mean, before we can decide if we want to go through all this hassle of relicensing, it should be clear if the code integration is doable and what the benefit would be. (I had already typed most of this message on Monday, but then my keyboard froze (PS/2 keyboard, freezes from time to time on Linux, with the last key stuck) so I was frustrated and shut down the PC.) So long, Markus

>But I think the other aspect of this is much more important: Is it realistic to integrate code from an Android only app into GpsMid? >It would probably be Android only, which would decide on the question whether we continue to maintain both J2ME and >Android or not, wouldn't it? I'm all for keeping J2ME support and keeping the J2ME support fully featured when possible (when the platform allows for it and it's not overly complicated). I'm also for keeping the source tree in one place, and when a feature relies on a platform-dependent service - say, speech synthesis on Android - and including or excluding features at compile-time by preprocessor directives, like we currently do for platform-dependent code (GPS interface, camera, audio recording, file access). One particular example which prompted the message about license shift is the navigation images (big arrows) - if the licenses were compatible, the images for navigation instructions from Osmand could be used. Imags work well on J2ME as well as on Android. I would expect there are many smallish, non-platform-dependent features like this where code sharing could be useful. However I'm not strictly against including Android-only code. It might be some work to rework Android code for J2ME, and while a laudable aim, it remains to be seen if we (the developers) are able to use the time for that. Also, there might be technical & performance reasons to prefer native code. Could also be using code from other projects could help to modularize & improve code. I'll take an example. Raster map drawing (which e.g. the Osmand and Androzic GPLv3 apps do, from online and/or offline sources) is a feature missing from GpsMid which could sometimes be useful. (though it's debatable of course what the focus should be, should raster maps be included at all) . Osmand also supports vector maps and overlaying vector maps on raster maps. It seems that in practice Osmand feels quite a bit more responsive in map panning. This is probably at least partly J2MPolish bridging overhead. So, a way to approach starting to use Android native code for map display (for better performance) could be to use Osmand or Androzic view code as a model (or directly as a base) for a direct, native Android map rendering backend. Perhaps raster drawing could easily come with the Android map code. But then how about raster maps for J2ME? To allow for that, could be useful to have a map rendering interface, which could use either J2MEPolish or Android as a backend. Might be the end result from this is not so close to the original Android code, but hopefully could have the benefits of performance and raster maps, and could also bring raster maps to J2ME devices.

Hi jkpj. This is all rather unspecific. I think to be able to decide whether the hassle of changing the license to GPL v3 is worth it (and it IS going to be a hassle to some degree, as we need to get positive feedback from all contributors), it should be clear what the concrete benefits would be. Not in terms of "we may be able to" but what it is specifically needed for and what positive effect this will bring us. > One particular example which prompted the message about license shift is the navigation images (big arrows) - if the > licenses were compatible, the images for navigation instructions from Osmand could be used. I am against using graphical elements from other applications. Each application should have some style of its own, and I think GpsMid also has one, especialy with the menu icons that were drawn by a graphical designer, albeit most elements of GpsMid don't have a particularly sophisticated and good-looking style. ;-) Using images of other applications makes every application look inconsistent unless it's done very carefully, it will not look like made of one piece but there will be fractures which may easily look like things were carelessly thrown together. So long, Markus

What the license change would be useful for: simply, It would make it possible to incorporate GPLv3 code into GpsMid. I think this part is clear enough. In my opinion, this alone brings benefit, allowing more paths for GpsMid develop, more space to live in. What positive effect this could bring and what concrete code would possibly be added: To this I have nothing more specific to add at the moment to the things I said earlier, and I can't anticipate (more exactly than what I said earlier) what possible added code might be. At the moment I don't have opinions on any specific other code worth incorporating. In the ideal world, I do think that incorporating big parts of code from other source might have adverse effects, and writing code / creating code directly for GpsMid can be better in many senses. If GpsMid had a big developer & graphical designer base, it would be better to design from the start for GpsMid and write code for that. Relating to this, touching the practical: However, to take into account the practicalities, Android is apparently quite new to all GpsMid developers, and we don't have a huge developer base. In this practical situation, one practical purpose for license compatibility would be for me to test Android UI code (e.g. map display I mentioned earlier) from some other map viewing app (e.g. by incuding it in GpsMid, perhaps a separate branch, perhaps temporarily). A major goal in this would be learning the Android UI in practice. I don't expect major parts of other programs to be incorporated into GpsMid in this process. However, there can be code snippets which could be of use, and depending on interpretation of copyright this could be enough of a hassle with incompatible licenses that I don't want to do that with code whose license isn't compatible. In the terms of compatibility, apparently "GPLv2 or later" would be the most widely useful license. I know some people don't like to use "or later" because it gives control of the specifics of possible future versions of the license to someone else (in this case the Free Software Foundation, FSF). Personally, I now think "GPLv2 or later" would be a good practical choice for GpsMid. Hopefully this makes it at least a bit more clear what the aims are.