Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

license? #293

Closed
emiltin opened this issue Jun 11, 2012 · 13 comments
Closed

license? #293

emiltin opened this issue Jun 11, 2012 · 13 comments
Milestone

Comments

@emiltin
Copy link
Contributor

emiltin commented Jun 11, 2012

i just read up on the differences between GPL, LGPL, MIT and BSD licenses. http://producingoss.com/en/license-choosing.html

i'm curious (not critical) about the choice of license for OSRM, specifically the choice of LGPL over MIT?

it's relevant to us because we want to make it easy for everyone to build on what we're going, but GPL doesn't allow commercial use. if i understand the differnces correctl, LGPL does allow commercial use, but the license is more complex than MIT.

@DennisOSRM
Copy link
Collaborator

i'm curious (not critical) about the choice of license for OSRM,
specifically the choice of LGPL over MIT?

I don't know about the specific differences of LGPL over MIT. OSRM is AGPL.

it's relevant to us because we want to make it easy for everyone to
build on what we're going, but GPL doesn't allow commercial use. if i
understand the differnces correctl, LGPL does allow commercial use,
but the license is more complex than MIT.

AGPL was chosen for OSRM for one reason. Everyone is free to use it,
either commercially or not. But any changes that are made to the source
have to be published again.

@emiltin
Copy link
Contributor Author

emiltin commented Jun 11, 2012

thanks for the answer.
LGPL and AGPL are just to words for the same thing. (Lesser GPL / Affero GPL).
my understandig is that AGPL/LGPL and MIT are essentially similar. they're also combatible: http://en.wikipedia.org/wiki/MIT_License.

so no problems :-)

@DennisOSRM
Copy link
Collaborator

thanks for the answer. LGPL and AGPL are just to words for the same
thing. (Lesser GPL / Affero GPL).

No, in fact they are not. LGPL is freely linkable where AGPL code is
not. Also, running customized LGPL code on a public server does not
imply that the changes have to be open-source where AGPL forces you to
give out all local changes.

my understandig is that AGPL/LGPL and MIT are essentially similar.
they're also combatible: http://en.wikipedia.org/wiki/MIT_License.

Please consult the virality component of theses licenses. You are right,
that MIT licensed code can be used in an AGPL licensed project, but the
licenses are not exchangable. Escpecially, AGPL is quite viral while MIT
is quite liberal.

so no problems :-)

@emiltin
Copy link
Contributor Author

emiltin commented Jun 11, 2012

it seems that the GPL family of licenses are generally not as free as the BSD and MIT licences.

http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses
http://en.wikipedia.org/wiki/Affero_GPL

wikipedia states that you're not allowed to link AGPL libs from software using a different license.

Copyleft Yes
Linking from code with a different license No (except for GNU GPLv3)

@emiltin
Copy link
Contributor Author

emiltin commented Jun 11, 2012

ok. so AGPL licensed code can be used for all commercial purposes, but any derived work must be open source. i guess this requirement could discourage some companies, but it might be better for the open source community.

@DennisOSRM
Copy link
Collaborator

ok. so AGPL licensed code can be used for all commercial purposes,
but any derived work must be open source. i guess this requirement
could discourage some companies, but it might be better for the open
source ommunity.

Right, that was the main idea behind the license. Once, the scripting
engine is running, the scripts will be licensed as MIT (or BSD).
Organizations which choose to use OSRM can use their own extraction
routine but any substantial changes have to open again.

Disclaimer: I am not a lawyer ;-)

@lafriks
Copy link

lafriks commented Jun 29, 2012

Does that mean that if OSMR generated route is displayed in some webpage that also the whole webpage code must be made as opensource?

@DennisOSRM
Copy link
Collaborator

No, this does not extend to the data this is computed. Changes to AGPL code or other code that is linked against AGPL code has to be published under the same licence.

@lafriks
Copy link

lafriks commented Jul 2, 2012

does calling web service API also counts as linking?

@DennisOSRM
Copy link
Collaborator

does calling web service API also counts as linking?

No, it does not.

@systemed
Copy link
Member

I can understand the reasoning and background behind choosing AGPL for OSRM.

Using it for OSRM-Web, however, seems a little strange. AGPL is (of course) intended to address the case where the software is not distributed but is accessed across a network. But since OSRM-Web is largely JavaScript, the code is indeed distributed to the user and there's no need for AGPL's additions over GPL.

The components of OSRM-Web are really good and worth reusing for any non-trivial deployment of OSRM - particularly draggable markers, RoutingDescription etc. It's not clear, however, to what extent the AGPL would affect (say) the design and text of an embedding page if these components are used in it. Personally that's reasonably likely to make me want to code an alternative with the same functionality but a more permissive licence, which would be a great shame given the excellent OSRM-Web code.

Would it therefore be possible to consider a switch to LGPL for OSRM-Web?

@DennisOSRM
Copy link
Collaborator

@DennisSchiefer

@DennisSchiefer
Copy link

I am open to change the license, but as far as I am aware, all previous contributors have to agree with the change - and at the moment I cannot hunt down all of them. According the the authors.md there are by now 30 contributors - mostly translators though.

springmeyer pushed a commit that referenced this issue Dec 15, 2016
76de7eb bump to v0.3.0
a2f36f0 Merge pull request #301 from mapbox/v8-5.1.281.47
e06010e Merge pull request #300 from mapbox/v8-3.14.5.10
61021d9 build xcode-toolchain for darwin [skip ci]
a17d47e Update Android compile flags
8adc05a Merge pull request #298 from mapbox/c11-for-tc
91cc1ce adjustments to tippecanoe build
3693450 download tar of 1.15.1
1563d66 update to c++11 for tippecanoe
ca2cf2f fix conditional building of libcxx with llvm 4.x
e92a050 Add iwyu to llvm packages + conditionally build libc++ (to avoid potential conflicts with apple system)
ecbe161 clang++ subpackage: rebundling asan_symbolize from llvm
a04d31a llvm: install asan_symbolize script
f81ff0f Merge pull request #297 from mapbox/boost_fixes
3c4201f also trigger build for header-only package
394db3d only need to build the header-only package once for all platforms
6f6dd89 avoid the header-only package reporting ldflags
2bef25b fix boost library name for ldflags
8abd030 bump to v0.2.0
434da41 Merge pull request #293 from mapbox/gdb
2c5e104 add texinfo [skip ci]
001e1d0 build gdb with g++ [skip ci]
fa89a91 attempt to workaround gdb bug [skip ci]
7a573b0 add gdb [skip ci]
33b8c85 Merge pull request #292 from mapbox/binutils-latest
d88af66 Upgrade Android NDK to r13b
ce29128 add Android NDK r13b [skip ci]
fcaff69 include llvm-ar and llvm-ranlib in clang++ package for full LTO support on linux
5fa738d add disable-werror to binutils build [skip ci]
b38b22e add texinfo dep [skip ci]
a9c038a add latest binutils
09a1272 add geojson 0.4.0 [skip ci]
f787753 add geometry 0.9.0 [skip ci]
649178c add variant 1.1.4 [skip ci]
f29bc15 Merge pull request #285 from mapbox/pkgconfig
5c3a26d add pkgconfig 0.29.1
228784d Fix bug in wagyu
e9cfd69 Merge pull request #284 from mapbox/wagyu2
0dab0ba Update travis script
b580a12 Updated hash as it was not md5 -- something I forgot
a5c6b7b Merge pull request #283 from mapbox/wagyu
dd05da8 Added wagyu 0.1.0
5407ddc Merge pull request #282 from mapbox/boost-1.62.0
fa6d51a add boost 1.62.0, remove obsolete boost packages
d0210bb drop the boost 'all' packages
66d8a26 remove empty before_install
7527555 Merge pull request #281 from mapbox/mason-travis-token
af4a2c6 [[email protected]] Skip linking with pthread on android
2115889 rename TRAVIS_TOKEN to MASON_TRAVIS_TOKEN to avoid conflicting with travis.rb (https://github.com/travis-ci/travis.rb/blob/b75c38bcdb736d1011e0d2a0022344a9870acaf4/README.md#environment-variables)
8117c1c Merge pull request #279 from mapbox/llvm-libstdcxx
3c9029e strip version modifier
9e1edca Add llvm 3.8.1 package that sets BUILD_AND_LINK_LIBCXX=false - refs #278
9724ef5 make building and linking libcxx/libcxxabi optional - refs #278
6c4c5d5 solve #152
8f3a877 Merge pull request #277 from mapbox/central-secure
9350c34 New travis keys
f442ddc add secure variables on-demand in trigger command
36d4801 remove global variables
4fff08a Add mesa 13.0.0-egl{,-cxx11abi}
e3f2a2c [mason] Add support for nested pkg-config files
3b79550 Add ICU 58.1 (#275)
20a394d make contributing.md tagging more DRY [skip ci]
58ae447 bump to v0.1.1
c5ef33f rename llvm 4.x to 4.0.0 [skip ci]
5d5d26b add llvm 4.x based sub-packages
9708680 only set LIBCXX_ENABLE_STATIC_ABI_LIBRARY for linux [skip ci]
6918fb0 install LLVMgold.so on linux [skip ci]
ab20ff7 binutils: using 'all-gold' breaks make install on linux [skip ci]
cb8b15f fix binutils install [skip ci]
df77b02 properly set LLVM_BINUTILS_INCDIR value [skip ci]
295d4db binutils gold fixes [skip ci]
ac85676 enable LLVMgold.so for linux [skip ci]
acc4249 add binutils 2.27
16d4452 add lldb and llvm-cov 3.8.1 packages
757b908 remove patching no longer needed [skip ci]
69415b5 better fix for statically linking/linked libc++ with llvm 3.8.1 [skip ci]
43933ed Added mesa-13.0.0-glx (non-CXX11ABI)
2bb81cc Added mesa-13.0.0-glx
d70e3ef LLVM_EXTERNALIZE_DEBUGINFO is osx specific
ba737bf llvm 3.8.1 linux build fixes
4279f58 Updates for mesa 13.0.0
d544278 Revert typo in mason.sh
03ecb2c Add mesa 13.0.0 (Gallium-OSMesa)
0997905 Add expat 2.2.0
211d8f4 v8 libplatform depends on libbase [skip ci]
c9d2371 thin archives are only an linux thing [skip ci]
bd4964b ensure v8 static libs are portable [skip ci]
f41eb6d mason.cmake: multiple static libs also need to be split
c9fcd1a add lldb to llvm 3.8.1 [skip ci]
6d8e16c minor llvm/clang++ improvements
65a5418 fix static_libs
31a424f add v8 5.1.281.47
1afa241 fix v8 include dir [skip ci]
b2bdb33 Add note that we need to create a github release [skip ci]
17d9b09 linux fixes
95b4f2e add v8 3.14.5.10

git-subtree-dir: third_party/mason
git-subtree-split: cf3561bf78cb146821dba3d95c308fc44db05f46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants