plus_plugins
plus_plugins copied to clipboard
fluttercommunity
[Bug]: Use of CC-BY-SA 3.0 licensed code (CLA violation)
Platform
ios
Plugin
network_info_plus
Version
1.1.0
Flutter SDK
N/A
Steps to reproduce
It recently came to my attention that https://github.com/fluttercommunity/plus_plugins/pull/355 pulled in code copied from stack overflow under a prohibited license under Google's CLA. (CC-BY-SA 3.0).
The specific file is this one: packages/network_info_plus/network_info_plus/ios/Classes/getgateway.c
You can see where I noticed this in my PR: https://github.com/fluttercommunity/plus_plugins/pull/1045#issuecomment-1236345199 and my comment on stack overflow requesting more permissive licensing: https://stackoverflow.com/questions/4872196/how-to-get-the-wifi-gateway-address-on-the-iphone/29440193#comment129969427_29440193
The way to solve this is either a clean room re-implementation of that file, or having it relicensed. I have been unable to reach the original poster on stack overflow. I also tried to get in contact with them via github and twitter to no avail, and they have no activity on stack exchange in over 4 years. For these reasons, it seems that re-implementing the file in a way that does not pose licensing issues is the path forward.
In the meantime, I would suggest reverting the original PR or else removing the code from this repo to prevent licensing issues.
Code Sample
N/A
Logs
N/A
Flutter Doctor
N/A
I'm not sure if fluttercommunity requires agreeing to Google's CLA. I noticed that the contributing guidelines specify that they follow flutter's style guide which itself delegates licensing concerns to Google's CLA.
Because this project is a fork from Google, my guess is that Google's CLA licensing requirements are gone. Probably the Contributor guidelines need a cleanup in this aspect. But it is still good to get this straight and get proper licensing for the implementation.
Regardless of whether you are using Google's CLA, this package currently lists its license as MIT.
@miquelbeltran Is there a plan to resolve this shortly? The Flutter Favorites program requires a permissive license, so this package is not currently in compliance with the criteria.
/cc @slightfoot as someone who is both a contributor here and on the Flutter Favorites committee.
Thanks @slightfoot. I'll write up a quick description of what the API needs to do for you so that you can implement it to the spec. Can you confirm that you haven't come across the stack overflow implementation before such that your implementation may inadvertently be based on it?
@TzviPM Did you have time to writ a description of the API you were talking about?
Sorry, I've been away from my usual work for a couple weeks. I'll be back tomorrow and have in mind to write this up and send it. Thanks again @slightfoot for offering to help and thanks @vbuberen for checking in.
As I was looking through this, I think we actually don't need this header file anyway. The functionality we need is simply to get the socket address of the default gateway. In macos, this is accomplished by looping through all of the interfaces and finding the one with the correct name (en0): https://github.com/fluttercommunity/plus_plugins/blob/d1d7ad56f2c080bd18084c1d52394feca58e8bd2/packages/network_info_plus/network_info_plus_macos/macos/Classes/NetworkInfoPlusPlugin.swift#L68
This is accomplished using CoreWLAN, which doesn't exist for ios. I believe that getgateway.h was originally added due to this. However, we already have a method that enumerates all of the network addresses here: https://github.com/fluttercommunity/plus_plugins/blob/82474e7f46df1402fd42421e15d8bd3b6e5f8aec/packages/network_info_plus/network_info_plus/ios/Classes/FLTNetworkInfoPlusPlugin.m#L181.
Using this, we can eliminate our use of getgateway.h and simply use the same logic as for macos, AFAICT.
As it turns out, I'm way over my head here. I have practically no experience with ios development nor Objective C.
I'm wondering if this is the wrong approach, though. In particular, I'm quite suspicious that the swift code used in our macos code was at one point also taken from the same stackoverflow question or vice versa (it looks almost identical).
Both of these functions essentially loop through all of the network interfaces to find the default interface, which is essentially just used to provide information about the connected wifi network. That said, there does seem to be a more straightforward way of doing this as per developer.apple.com/forums/thread/679038.
How difficult would it be to rewrite our implementation for macos and ios to use this approach?
@slightfoot thoughts? It seems the goal is to get the networking information for the default gateway on the ios device. The method we're using right now (the one that we'd need to re-implement) takes, as input, a pointer to a socket address (in_addr_t). It returns an int status which is non-negative (>= 0) if successful and negative otherwise. Upon successful return, the input pointer should dereference to the socket address of the default gateway.
If you'd like to do a direct re-implementation, that's the spec you'd code to. Otherwise, it may be simpler to re-implement the entire flow based on the discussion in developer.apple.com/forums/thread/679038.
@slightfoot Would like to draw your attention to this as you were willing to help with this serious issue we have here.
This should not be auto-closed.
As mentioned above, this plugin is currently not in compliance with the requirements of Flutter Favorites. If no action is taken here I don't see any way for it to keep that designation.
@slightfoot we are waiting for you on this task, please confirm if you cannot do it, so we can find another way. @stuartmorgan if Simon is busy, I'll take over it and fix it by next week. I'll tag this as urgent to be addressed
Cc @vbuberen @jpnurmi
I started on this issue right away; either I will find a contributor to fix it or will do it by end of the week myself.
For what is worth, the original file is actually from libnatpmp, which is licensed under 3 clause BSD license.
Great finding! Thank you, @knopp! So the only practical difference to the original BSD-3 code is an additional "en0" check. We could simply replace getgateway.* with the original, properly attributed sources, add the "en0" check assuming it's necessary, and hope it builds on iOS without bigger changes.
My concern would be twofold:
-
Our codebase seems to indicate that the reference point was the stack overflow post, not the libnatpmp library.
-
If the libnatpmp library was our source, but they themselves took it from stackoverflow, then they released it under their license in error, and it doesn't now make it allowable for us to use it under their BSD license, to my knowledge. I do not have any legal background, but I'd be happy to check into this with Google's legal counsel.
but they themselves took it from stackoverflow
How did you come to that conclusion? The git history for that file goes back several years before the SO post.
We've been using libnatpmp since about 2010. You can get a really old source tarball from http://miniupnp.free.fr/files/ (as far as 2007, which predates SO), you'll see the file is there.
Maybe I'm misunderstanding something. The file in question here is getgateway.c, which has a comment explicitly stating it was copied from that stackoverflow post.
but they themselves took it from stackoverflow
How did you come to that conclusion? The git history for that file goes back several years before the SO post.
I didn't. Read my words like this:
if ((ourCode.source == libnatpmp) && (libnatpmp.source == stackoverflow)) {
// they released it under their license in error
}