I'm currently working on a port of Swift to Android. Since Android's libc is missing a few required methods, I added code from a few other sources to implement the functionality. Specifically, I added an implementation of posix_spawn from the FreeBSD libc, floating point routines from Android NDK's copy of SunSoft FDLIBM (which just requires attribution), and a getline implementation from the Android source (Apache licensed).
I'm wondering whether I'm allowed to do this. While their licenses are compatible with Apache license, they all require attribution at the top of the source, but Swift's contribution guidelines only allows the Swift license header. I don't think there's any third-party code in Swift currently, so I can't find a precedent for what to do in this situation.
Is the inclusion of third party code allowed, and if so, what should the license header on their files look like?
I'm currently working on a port of Swift to Android.
Great!
Since Android's libc is missing a few required methods, I added code from a few other sources to implement the functionality. Specifically, I added an implementation of posix_spawn from the FreeBSD libc, floating point routines from Android NDK's copy of SunSoft FDLIBM (which just requires attribution), and a getline implementation from the Android source (Apache licensed).
I'm wondering whether I'm allowed to do this. While their licenses are compatible with Apache license, they all require attribution at the top of the source, but Swift's contribution guidelines only allows the Swift license header. I don't think there's any third-party code in Swift currently, so I can't find a precedent for what to do in this situation.
Is the inclusion of third party code allowed, and if so, what should the license header on their files look like?
This is very problematic from a licensing perspective. We’d really like to keep the license of the swift project simple and consistent. OTOH, I don’t want you to be blocked from contribution. Here are some possible paths forward:
- For things like posix_spawn, it is probably straight-forward to change the uses in swift to use LLVM’s existing abstractions (e.g. see https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/Program.h\).
- getline in particular has lots of prior art, I’d suggest asking the lldb folks in particular if they have suggestions.
- The people who originally wrote the code may be willing to license it to the swift project under the swift license. If so, we can accept it directly from them.
- It may be possible to rewrite the code “clean room” as part of the LLVM or Swift projects. LLVM has a “libsupport” library for papering over system idiosyncrasies that swift relies on, for example.
- It may be possible to motivate the android folks to improve their platform to incorporate this stuff, it seems like doing so would benefit portability in general.
I’m not familiar with Android or its ecosystem, nor with the specific code you’re talking about, so some of these are likely non-sensical...
-Chris
···
On Dec 19, 2015, at 12:26 PM, Zhuowei Z via swift-dev <swift-dev@swift.org> wrote: