5 ms·

So after reading this commit: https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582a81b306e1ef5f9 https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c3

by Argorak 13y ago

So after reading this commit: https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582a81b306e1ef5f9 https://github.com/ffi/ffi/commit/346c80ad6b8c0e6dc3c390b582... and this discussion https://twitter.com/bascule/status/393509979711213568 https://twitter.com/bascule/status/393509979711213568 I have the impression that no one can safely fork ruby-ffi without opening himself to legal trouble. It seems like the licensing of the project is a horrible mess. IANAL, so I hope I am reading this wrong?

logn 13y ago
It's not that big of a deal. It's an LGPL-licensed codebase which incorporated BSD-licensed modules (there's nothing wrong with that). Since LGPL places some requirements on being intermingled with incompatibly-licensed software, the author made sure to point out which parts were under the more permissive BSD license so people could re-use those parts and not be subject to LGPL by using his project as a whole. In a nutshell, if you use an LGPL codebase, make sure either: (1) your code is LGPL or under a compatible license or (2) that you only use the code on an API level and dynamically link to it. Btw, LGPL is a license accepted by many enormous communities, such as Qt. If you want to fork this project, easiest route is to just re-apply the LGPL license and fork after the point where notice of BSD parts was added, because it's a violation of BSD to not mention their license. IANAL
- Argorak 13y ago
  I have no problem with the LGPL (beyond the occasional problem with legal, but thats legals problem) or the dual-licensing in general. The linked commit hints at additional problems with missing licensing etc. In the absence of good documentation on this, a new maintainer has the problem of not being able to make heads or tails of it if someone had claims on the code.
rtb 13y ago
I don't think that's the case. It appears to be LGPL + BSD. That should be fine for pretty much any use. "Postmodern" has it from the linked twitter thread: "they [are] probably confusing LGPL with GPL/AGPL, or are afraid of getting Stallman cooties."
- justincormack 13y ago
  No it is not LGPL+BSD according to the license, it is LGPL3 https://github.com/ffi/ffi/blob/master/LICENSE https://github.com/ffi/ffi/blob/master/LICENSE Parts of it being BSD does not mean it is dual licensed, it just means you can remove the BSD parts and reuse them elsewhere as BSD; you cannot just take BSD files and strip out the license as the terms say the license must remain included.
  - belorn 13y ago
    The license of the combined work is under LGPLv3, but the individual code parts is either under LGPLv3 or Modified BSD License (or LGPL+BSD for short). Its correct however that one can not remove the actually license text from the BSD licensed code. Doing so would be a license violation of the BSD license terms #1. This is the good part about BSD for FOSS projects. One do not need to do any active action to be in compliance with the license. Do changes, add any licenses, and so long the license text on the BSD source code is intact, you are in the green.
protomyth 13y ago
It looks like given this https://twitter.com/luislavena/status/394228584199372800 https://twitter.com/luislavena/status/394228584199372800 That the old BSD header and copyright were removed and LGPL added. You can only do this if you have the agreement of all copyright holders. The BSD does not allow you to remove the copyright. Sadly, I agree with your conclusion, this is a minefield.
- belorn 13y ago
  Looking at the repo now, it seems to include both the LGPL and BSD header on those files mentioned in the diff. Just a guess, but maybe someone was initially confused, and removed the BSD license rather than simply adding the LGPL license?
  - protomyth 13y ago
    Probably, it seems a common thing with the BSD that people forget they cannot remove the header without all the authors permissions. If someone was going to fork it, they probably should go back before the license change and solve whatever bug fixes in an independent manner just to avoid the whole thing.
Argorak 13y ago
Answering my own to bring some conclusion to this: https://github.com/ffi/ffi/issues/288 https://github.com/ffi/ffi/issues/288 Seems like the current maintainers are on a good way of actually contacting everyone to agree on a license change.

by Argorak 13y ago

logn 13y ago

It's not that big of a deal. It's an LGPL-licensed codebase which incorporated BSD-licensed modules (there's nothing wrong with that). Since LGPL places some requirements on being intermingled with incompatibly-licensed software, the author made sure to point out which parts were under the more permissive BSD license so people could re-use those parts and not be subject to LGPL by using his project as a whole. In a nutshell, if you use an LGPL codebase, make sure either: (1) your code is LGPL or under a compatible license or (2) that you only use the code on an API level and dynamically link to it. Btw, LGPL is a license accepted by many enormous communities, such as Qt. If you want to fork this project, easiest route is to just re-apply the LGPL license and fork after the point where notice of BSD parts was added, because it's a violation of BSD to not mention their license. IANAL

Argorak 13y ago
I have no problem with the LGPL (beyond the occasional problem with legal, but thats legals problem) or the dual-licensing in general. The linked commit hints at additional problems with missing licensing etc. In the absence of good documentation on this, a new maintainer has the problem of not being able to make heads or tails of it if someone had claims on the code.

rtb 13y ago

I don't think that's the case. It appears to be LGPL + BSD. That should be fine for pretty much any use. "Postmodern" has it from the linked twitter thread: "they [are] probably confusing LGPL with GPL/AGPL, or are afraid of getting Stallman cooties."

justincormack 13y ago
No it is not LGPL+BSD according to the license, it is LGPL3 https://github.com/ffi/ffi/blob/master/LICENSE https://github.com/ffi/ffi/blob/master/LICENSE Parts of it being BSD does not mean it is dual licensed, it just means you can remove the BSD parts and reuse them elsewhere as BSD; you cannot just take BSD files and strip out the license as the terms say the license must remain included.
- belorn 13y ago
  The license of the combined work is under LGPLv3, but the individual code parts is either under LGPLv3 or Modified BSD License (or LGPL+BSD for short). Its correct however that one can not remove the actually license text from the BSD licensed code. Doing so would be a license violation of the BSD license terms #1. This is the good part about BSD for FOSS projects. One do not need to do any active action to be in compliance with the license. Do changes, add any licenses, and so long the license text on the BSD source code is intact, you are in the green.

protomyth 13y ago

It looks like given this https://twitter.com/luislavena/status/394228584199372800 https://twitter.com/luislavena/status/394228584199372800 That the old BSD header and copyright were removed and LGPL added. You can only do this if you have the agreement of all copyright holders. The BSD does not allow you to remove the copyright. Sadly, I agree with your conclusion, this is a minefield.

belorn 13y ago
Looking at the repo now, it seems to include both the LGPL and BSD header on those files mentioned in the diff. Just a guess, but maybe someone was initially confused, and removed the BSD license rather than simply adding the LGPL license?
- protomyth 13y ago
  Probably, it seems a common thing with the BSD that people forget they cannot remove the header without all the authors permissions. If someone was going to fork it, they probably should go back before the license change and solve whatever bug fixes in an independent manner just to avoid the whole thing.

Argorak 13y ago

Answering my own to bring some conclusion to this: https://github.com/ffi/ffi/issues/288 https://github.com/ffi/ffi/issues/288 Seems like the current maintainers are on a good way of actually contacting everyone to agree on a license change.