JSON code is not compatible with GPL

[anonymous]

The JSON code (in /src/org/json/) is licensed under the restriction of the morality clause "The Software shall be used for Good, not Evil." which violates point 6 of the open source definition (​http://opensource.org/osd) and software freedom 0. This means that this code is proprietary and not open source. (The license is also incompatible with the GPL if used in the same program.)

Under the JSON morality license the code cannot be safely distributed as free and open source software by downstream projects like GNU/Linux distributions. For the sake of downstreams, it would be great, if you provided the option to exclude the problematic parts without losing substantial functionality.

[Don-vip]

I'll see if we can use ​jsonp which is released in CDDL+GPLv2.

[bastiK]

Replying to Don-vip:

I'll see if we can use ​jsonp which is released in CDDL+GPLv2.

I think there would be problems using GPLv2 code together with Apache 2.0 licensed code (e.g. bzip2 support).

Edit: Nevermind, jsonp is licensed under GPLv2/Classpath exception, so we can use it. (This is effectively like LGPL)

[Don-vip]

why it would have been a problem ? Isn't JOSM itself licensed as GPLv2/v3 ?

[bastiK]

Replying to Don-vip:

why it would have been a problem ? Isn't JOSM itself licensed as GPLv2/v3 ?

Yes, most of the files are. However, the complete software is distributed under GPLv3, only. (see ​debian copyright file)

If you want to ship JOSM under GPLv2, you first have to remove all incompatible code, i.e. the Apache libraries. (So we don't gain much by offering GPLv2, but it doesn't hurt much either. At least someone can take JOSM code and use it in another GPL 2-only project.)

[stoecker]

Wouldn't it be easiest to simply "ASK" the authors if code can be used in JOSM under GPL2+?

[Don-vip]

Replying to bastiK:
(see ​debian copyright file)

Didn't know this file, it is more complete than ours :)

However there are really strange things in it, about the .po files for example. Why some of them are "copyrighted" to very few contributors ? O_o

[Don-vip]

Replying to stoecker:

Wouldn't it be easiest to simply "ASK" the authors if code can be used in JOSM under GPL2+?

That's another option. The author's mail is here: ​https://github.com/douglascrockford/JSON-java

However switching to jsonp is not a bad thing. That's the Oracle reference implementation in Java EE 7, to there's a good chance to see it included in some future Java SE version (9 probably) so we could then drop it later without anyone noticing (OK we won't switch to Java 9 until 2025 but... :D )

[anonymous]

You guys are great! Thank you so much for looking into this! (License problems are always a hassle and other project's maintainers are often rather annoyed by questions like this, if they react at all.)

[stoecker]

Replying to Don-vip:

Replying to bastiK:
(see ​debian copyright file)

Didn't know this file, it is more complete than ours :)

Hmm, it may be more complete, but most additional texts are wrong. E.g. JOSM code is GPL-2.0+ and not 3.0+. Translation copyrights and licenses are wrong as well. Years are totally outdated, e.g. my contributions are 2008-2014, not 2008-2012. Lots of people missing.

[Don-vip]

Replying to stoecker:

Hmm, it may be more complete, but most additional texts are wrong. E.g. JOSM code is GPL-2.0+ and not 3.0+. Translation copyrights and licenses are wrong as well. Years are totally outdated, e.g. my contributions are 2008-2014, not 2008-2012. Lots of people missing.

I will create a bug to Debian. But first we need to clean our own file :) I have started this process in JMapViewer in [o30223].

[stoecker]

Replying to Don-vip:

But first we need to clean our own file :) I have started this process in JMapViewer in [o30223].

I'm not convinced, that stating all the authors is a useful goal. For JOSM the policy is currently to state somebody only if he did major contributions and not only a single patch.
Though the licenses should be collected for the components, as soon as they differ from GPL2+, but everything which is directly convertible into GPL2+ automatically gets GPL2+ when we have it in our repository, as we stated so. That means the JOSM repository has no longer LGPL, PD or BSD code, but GPL2+ were ever applicable.

P.S. JMapViewer is also GPL2+ and not only GPL.

[Don-vip]

Replying to stoecker:

I'm not convinced, that stating all the authors is a useful goal. For JOSM the policy is currently to state somebody only if he did major contributions and not only a single patch.

I agree with you for JOSM :) However concerning JMV, the program is so small that most of the patches can be seen as major contributions :) And the number of contributors is very small, so I think it's ok as it.

For JOSM, what the list would be ? According to SVN stats, people with at least 50 commits are:

stoecker
Don-vip
bastiK
Gubaer
simon04
jttt
framm
imi
ulfl
akks
ce
mjulius
gebner
xeen

Would it be ok to include this list with years of activity ?

P.S. JMapViewer is also GPL2+ and not only GPL.

I will fix that.

[stoecker]

Replying to Don-vip:

For JOSM, what the list would be ? According to SVN stats, people with at least 50 commits are:

...

Would it be ok to include this list with years of activity ?

All of them are already included.

I don't like the years much. JOSM will no longer be in use at all, when the copyrights for the software stop. Even if it would be, what's the sense of stating the years for individual contributors - it's nearly impossible to extract the contributions from code, so always the last change year of all contributors is the only important number.

[bastiK]

Replying to stoecker:

Replying to Don-vip:

But first we need to clean our own file :) I have started this process in JMapViewer in [o30223].

I'm not convinced, that stating all the authors is a useful goal. For JOSM the policy is currently to state somebody only if he did major contributions and not only a single patch.

I agree this is too bothersome. I would guess that this practice is related to old US copyright law, where you had to declare the copyright explicitly in this way, otherwise you'd loose any rights related to your work.

Though the licenses should be collected for the components, as soon as they differ from GPL2+, but everything which is directly convertible into GPL2+ automatically gets GPL2+ when we have it in our repository, as we stated so. That means the JOSM repository has no longer LGPL, PD or BSD code, but GPL2+ were ever applicable.

As GPL2 is not compatible to Apache 2.0 and future GPL versions need not be compatible to anything, the entire work can only be released under GPL 3 at the moment. I don't think we need to change anything explicitly for the BSD / PD parts, we simply use this code under the terms of the GPL 3.

P.S. JMapViewer is also GPL2+ and not only GPL.

"GPL" is better than "GPL2+": If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. (see ​gpl)

[stoecker]

Replying to bastiK:

Though the licenses should be collected for the components, as soon as they differ from GPL2+, but everything which is directly convertible into GPL2+ automatically gets GPL2+ when we have it in our repository, as we stated so. That means the JOSM repository has no longer LGPL, PD or BSD code, but GPL2+ were ever applicable.

As GPL2 is not compatible to Apache 2.0 and future GPL versions need not be compatible to anything, the entire work can only be released under GPL 3 at the moment.

This does not affect our JOSM code which is GPL2+. Everything. That the Bzip code enforces GPL3+ for the whole product does not change that situation.

I don't think we need to change anything explicitly for the BSD / PD parts, we simply use this code under the terms of the GPL 3.

No. However they are licensed outside the JOSM repository, as soon as the are integrated in JOSM, they get GPL2+ when the original license permits that. They are still BSD/PD outside our world, but not for us. So when we change or use these files, the result will be licensed GPL2+. When this is not allowed, then they must be removed. Speaking for the code! Situation with image art and so on is a bit different, as most of these probably aren't GPL'ed.

Don't mix the original license and the usage in JOSM. The licenses permit to use compatible licenses. That does not mean that we have a mix of licenses, but that we use code with our (GPL2+) license or don't use it at all. The integration of GPL3+ code is an exception, as unlike for Debian guys we are no license festishists. But there is not reason to have anything outside the GPL world in JOSM code.

P.S. JMapViewer is also GPL2+ and not only GPL.

"GPL" is better than "GPL2+": If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. (see ​gpl)

That may be the case, but JMapViewer is based on SlippyMapChooser and other things and thus is GPL2+. If GPL1+ may be better does not count here, because this choice no longer exists.

[bastiK]

Replying to stoecker:

Replying to bastiK:

Though the licenses should be collected for the components, as soon as they differ from GPL2+, but everything which is directly convertible into GPL2+ automatically gets GPL2+ when we have it in our repository, as we stated so. That means the JOSM repository has no longer LGPL, PD or BSD code, but GPL2+ were ever applicable.

As GPL2 is not compatible to Apache 2.0 and future GPL versions need not be compatible to anything, the entire work can only be released under GPL 3 at the moment.

This does not affect our JOSM code which is GPL2+. Everything. That the Bzip code enforces GPL3+ for the whole product does not change that situation.

I don't think you can change to a license that hasn't been published yet (unless you are the author). E.g. the Free Software Foundation may decide to publish a version 4 which is incompatible with Apache 2.0. Then you wouldn't have the right to relicense the Bzip code to GPL4, so you certainly cannot offer that promise now. In principle, the same is true for the BSD license (although it is extremely unlikely, that next version of the GPL will be incompatible to BSD).

I don't think we need to change anything explicitly for the BSD / PD parts, we simply use this code under the terms of the GPL 3.

No. However they are licensed outside the JOSM repository, as soon as the are integrated in JOSM, they get GPL2+ when the original license permits that. They are still BSD/PD outside our world, but not for us.
So when we change or use these files, the result will be licensed GPL2+. When this is not allowed, then they must be removed. Speaking for the code! Situation with image art and so on is a bit different, as most of these probably aren't GPL'ed.

Don't mix the original license and the usage in JOSM. The licenses permit to use compatible licenses. That does not mean that we have a mix of licenses, but that we use code with our (GPL2+) license or don't use it at all. The integration of GPL3+ code is an exception, as unlike for Debian guys we are no license festishists. But there is not reason to have anything outside the GPL world in JOSM code.

I think we agree that the libs have to relicensed at some point, such that the whole thing (JOSM) has a common license. In my opinion this can only be the GPL 3. GPL2+ is not really a license, but a list of licenses, the user can freely choose from (GPL2, GPL3 and any future version published by the FSF). It doesn't hurt to add one more license to that list (BSD, PD, Apache 2.0) for some of the source files.

P.S. JMapViewer is also GPL2+ and not only GPL.

"GPL" is better than "GPL2+": If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. (see ​gpl)

That may be the case, but JMapViewer is based on SlippyMapChooser and other things and thus is GPL2+. If GPL1+ may be better does not count here, because this choice no longer exists.

I'm not aware that JMapViewer is based on any JOSM code, isn't it an independent piece of software? (But it doesn't matter obviously.)

[stoecker]

Replying to bastiK:

Replying to stoecker:

Replying to bastiK:

Though the licenses should be collected for the components, as soon as they differ from GPL2+, but everything which is directly convertible into GPL2+ automatically gets GPL2+ when we have it in our repository, as we stated so. That means the JOSM repository has no longer LGPL, PD or BSD code, but GPL2+ were ever applicable.

As GPL2 is not compatible to Apache 2.0 and future GPL versions need not be compatible to anything, the entire work can only be released under GPL 3 at the moment.

This does not affect our JOSM code which is GPL2+. Everything. That the Bzip code enforces GPL3+ for the whole product does not change that situation.

I don't think you can change to a license that hasn't been published yet (unless you are the author). E.g. the Free Software Foundation may decide to publish a version 4 which is incompatible with Apache 2.0. Then you wouldn't have the right to relicense the Bzip code to GPL4, so you certainly cannot offer that promise now. In principle, the same is true for the BSD license (although it is extremely unlikely, that next version of the GPL will be incompatible to BSD).

You somehow misunderstand the licensing. If this situation could arise, then the licenses would already be incompatible nowadays. Licenses are only compatible, when it is allowed to take the code from one license and relicense it with the other one. In this case we take Apache licensed code and make it GPL3+. We don't deliver any Apache licensed stuff. E.g. if we fix bugs in such code it is not possible to copy it back to Apache project, except the author also licenses it as Apache license. This project is GPL.

I think we agree that the libs have to relicensed at some point, such that the whole thing (JOSM) has a common license. In my opinion this can only be the GPL 3. GPL2+ is not really a license, but a list of licenses, the user can freely choose from (GPL2, GPL3 and any future version published by the FSF). It doesn't hurt to add one more license to that list (BSD, PD, Apache 2.0) for some of the source files.

No. JOSM is GPL2+, not a mix of licenses or anything else. It is GPL2+. You can incorporate any code which can be used with GPL2+ and any code which is not usable with GPL2+ you can't use. We have no conglomerate of licenses. The only exception is this Apache and GPL3+ situation, as we want to use that code, we make the final JOSM GPL3+ (which is allowed when it is GPL2+). This means the final JOSM product leaves the user less choices than the JOSM code itself.

That may be the case, but JMapViewer is based on SlippyMapChooser and other things and thus is GPL2+. If GPL1+ may be better does not count here, because this choice no longer exists.

I'm not aware that JMapViewer is based on any JOSM code, isn't it an independent piece of software? (But it doesn't matter obviously.)

"Origin: JMapViewer bases on code written originally for the JOSM plugin slippy map chooser". If I'm not totally wrong that was made by Frederik Ramm.

[stoecker]

An example with my code. Lots of my code is PD. That means you can use it in any possible way including ignoring my authorship completely and selling it as your own (in USA, here in Germany I'm unable to drop my copyright completely, I will always be the legitimate author even if I dropped all rights associated with it). But my code in JOSM project is GPL2+. So anything in JOSM which I did is GPL2+.

If you want to use my stuff as PD, than you need to find a clean copy of my work and only my work (that probably can be found in JOSM SVN when nobody else modified it). If in JOSM context (e.g. for i18n stuff) my old copyright notice remains intact that is fine, but it is perfectly legal to change it to GPL2+ (as the PD statement implies GPL2+ as well as hundreds of other licenses). Assuming that other authors expect that the project license is honored everywhere, it probably is required to state it as GPL2+ as soon as somebody else modified the files.

[bastiK]

Replying to stoecker:

An example with my code. Lots of my code is PD. That means you can use it in any possible way including ignoring my authorship completely and selling it as your own (in USA, here in Germany I'm unable to drop my copyright completely, I will always be the legitimate author even if I dropped all rights associated with it). But my code in JOSM project is GPL2+. So anything in JOSM which I did is GPL2+.

If you want to use my stuff as PD, than you need to find a clean copy of my work and only my work (that probably can be found in JOSM SVN when nobody else modified it). If in JOSM context (e.g. for i18n stuff) my old copyright notice remains intact that is fine, but it is perfectly legal to change it to GPL2+ (as the PD statement implies GPL2+ as well as hundreds of other licenses). Assuming that other authors expect that the project license is honored everywhere, it probably is required to state it as GPL2+ as soon as somebody else modified the files.

Sure, but with PD the situation is simpler.

[bastiK]

Replying to stoecker:

[...] Licenses are only compatible, when it is allowed to take the code from one license and relicense it with the other one.

Correct.

In this case we take Apache licensed code and make it GPL3+.

No, this is not possible. GPL3+ means you offer it under GPL3 (OK) or any later version that the Free Software Foundation will publish in the future (not OK). There is absolutely no way to predict what the FSF will come up with in version 4 of the GPL. For the sake of argument, suppose GPL4 will be a PD-like license. Then you would have published Apache licensed code as public domain. Obviously this would be a copyright violation.
You cannot possibly predict this, so it would be foolish to give a blank check license today and risk a copyright violation later. The best we can do, is to take the Apache licensed code and make it GPL3.

We don't deliver any Apache licensed stuff. E.g. if we fix bugs in such code it is not possible to copy it back to Apache project, except the author also licenses it as Apache license. This project is GPL.

[...]

No. JOSM is GPL2+, not a mix of licenses or anything else. It is GPL2+.

The GPL2+ is already a mix of licenses, namely GPL2 and GPL3. More precisely, it is dual licensed. You can also triple-license parts of the code, e.g. BSD, GPL2 and GPL3. This way the entire code base is covered under a common license (GPL3), but modifications to the library can still be contributed back upstream. This is of course optional, but in my opinion it is more "social" to keep the original license terms in a fork/copy and not restrict it without reason.

[stoecker]

Replying to bastiK:

There is absolutely no way to predict what the FSF will come up with in version 4 of the GPL.

Chapter 14:
"The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns."

A new GPL license cannot use a totally new model or it will not be a GPL license matching the term "or any later license".

You cannot possibly predict this, so it would be foolish to give a blank check license today and risk a copyright violation later. The best we can do, is to take the Apache licensed code and make it GPL3.

Than we should make clear, that JOSM final license is GPL3 (without +).

No. JOSM is GPL2+, not a mix of licenses or anything else. It is GPL2+.

The GPL2+ is already a mix of licenses, namely GPL2 and GPL3. More precisely, it is dual licensed. You can also triple-license parts of the code, e.g. BSD, GPL2 and GPL3. This way the entire code base is covered under a common license (GPL3), but modifications to the library can still be contributed back upstream. This is of course optional, but in my opinion it is more "social" to keep the original license terms in a fork/copy and not restrict it without reason.

We don't talk about what we would like to do, but we can do. And JOSM is GPL2+, See also our wiki start page "It is open source and licensed under GPL​." This was already the case when I started to work for JOSM and not to be changed anymore. We simply don't have the option to keep some additional licenses. The only chance would be to ask each and every contributor for a license change. So while the author of a change can use any license including dual, triple, whatever, the JOSM code is GPL.

[bastiK]

Replying to stoecker:

Replying to bastiK:

There is absolutely no way to predict what the FSF will come up with in version 4 of the GPL.

Chapter 14:
"The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns."

A new GPL license cannot use a totally new model or it will not be a GPL license matching the term "or any later license".

OK, the example was too extreme. But you don't have to go that far: GPL2 is incompatible to Apache 2, so it is certainly possible that GPL4 or a later version will, again, be incompatible.

You cannot possibly predict this, so it would be foolish to give a blank check license today and risk a copyright violation later. The best we can do, is to take the Apache licensed code and make it GPL3.

Than we should make clear, that JOSM final license is GPL3 (without +).

Suggestion:

Index: LICENSE
===================================================================
--- LICENSE	(revision 6747)
+++ LICENSE	(working copy)
@@ -10,9 +10,12 @@
 The GPL v2 is accessible here:
 http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
 
-When compiled with Bzip2 support code included the whole software is 
-licensed GPL v3 or later.
+The license terms for third party libraries may differ, see individual
+source files for details. (A possibly incomplete list of libraries can
+be found in the README file.)
 
+The entire work, including all libraries, is released unter the
+terms of the GPL v3.
 
 
 Note: This is not valid for JOSM plugins. These are not considered

No. JOSM is GPL2+, not a mix of licenses or anything else. It is GPL2+.

The GPL2+ is already a mix of licenses, namely GPL2 and GPL3. More precisely, it is dual licensed. You can also triple-license parts of the code, e.g. BSD, GPL2 and GPL3. This way the entire code base is covered under a common license (GPL3), but modifications to the library can still be contributed back upstream. This is of course optional, but in my opinion it is more "social" to keep the original license terms in a fork/copy and not restrict it without reason.

We don't talk about what we would like to do, but we can do. And JOSM is GPL2+, See also our wiki start page "It is open source and licensed under GPL​." This was already the case when I started to work for JOSM and not to be changed anymore. We simply don't have the option to keep some additional licenses. The only chance would be to ask each and every contributor for a license change. So while the author of a change can use any license including dual, triple, whatever, the JOSM code is GPL.

I'm not talking about the code written by JOSM authors (which is GPL2+), but about 3rd party libraries which we have included more or less without modification. If one component is completely independent of the rest of the program, then you can offer additional licenses for this component.

[Don-vip]

In 6756/josm:

fix #9590 - replace org.json with GPL-compliant jsonp + remove mention of old world image removed in r1680

[Don-vip]

The JSON problem is solved, I also removed an obsolete statement about world image removed long ago. If further clarification need to be done in CONTRIBUTION file, please go ahead :)

I'll submit nevertheless a bug to Debian as their license file is very outdated.

[stoecker]

Replying to bastiK:

I'm not talking about the code written by JOSM authors (which is GPL2+), but about 3rd party libraries which we have included more or less without modification. If one component is completely independent of the rest of the program, then you can offer additional licenses for this component.

Exactly this "more or less" counts. The only useful rule can be, that everything in our SVN is GPL2+, everything else may have different licenses (e.g. the svn:extern's). Otherwise nobody will be able to understand the license model.

[Don-vip]

Replying to Don-vip:

I'll submit nevertheless a bug to Debian as their license file is very outdated.

Reported to Ubuntu instead: ​https://bugs.launchpad.net/josm/+bug/1273178

I am astonished to see how complicated it is to report a bug to Debian ! o_O I assume Ubuntu maintainers will upstream the bug.

[Don-vip]

Two more questions about license. We currently state:

When compiled with Bzip2 support code included the whole software is licensed GPL v3 or later.

Because Bzip2 is licensed under Apache 2.0. But OAuth code (signpost) too ! Shouldn't we change that sentence to:

When compiled with Bzip2 or OAuth support code included the whole software is licensed GPL v3 or later.

We're currently investigating to see why it doesn't work in HTTPS (see #9710). If it appears we can't make it work, could we switch to ​scribe, which is licensed under MIT license (is it compatible with GPL?) ? In that case would the previous sentence apply?

[bastiK]

Replying to Don-vip:

Two more questions about license. We currently state:

When compiled with Bzip2 support code included the whole software is licensed GPL v3 or later.

Because Bzip2 is licensed under Apache 2.0. But OAuth code (signpost) too ! Shouldn't we change that sentence to:

When compiled with Bzip2 or OAuth support code included the whole software is licensed GPL v3 or later.

Yes, but bzip2 and signpost OAuth is not the only Apache 2 code we have in the repository, there is also:

• Metadata Extractor (EXIF reader)
• SVG Salamander
• Apache commons codec
• a list of Entities: org.openstreetmap.josm.data.validation.util.Entities

As long as we make sure that:

1. for each file, the license is clearly stated in the file header
2. all licenses are compatible

it should be alright.

We're currently investigating to see why it doesn't work in HTTPS (see #9710). If it appears we can't make it work, could we switch to ​scribe, which is licensed under MIT license (is it compatible with GPL?) ? In that case would the previous sentence apply?

MIT license is no problem, it is compatible with GPL 2 and 3 (see ​here).

(Should be obvious, but like to mention it anyway: This is no legal advice, I'm just reading and repeating what people have written on the internet...)

[bastiK]

In 6853/josm:

see #9590 - JSON code is not compatible with GPL

[Don-vip]

FYI, the Debian copyright file has been updated thanks to Sebastiaan:
​https://bugs.launchpad.net/ubuntu/+source/josm/+bug/1273178/comments/5