-
-
Notifications
You must be signed in to change notification settings - Fork 939
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
[Bug]: Use of CC-BY-SA 3.0 licensed code (CLA violation) #1058
Comments
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. |
@slightfoot are you a good contact for pushing this forward? |
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. |
Not from my side, I don't have the bandwidth |
Adding @mhadaily who reviewed the initial PR. |
@stuartmorgan I will investigate and fix this asap, will let you know. |
@stuartmorgan @TzviPM I'll pick this up as a reimplementation. |
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? |
Spec would be great. I can confirm I've never seen it before. |
@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 ( Line 68 in d1d7ad5
This is accomplished using plus_plugins/packages/network_info_plus/network_info_plus/ios/Classes/FLTNetworkInfoPlusPlugin.m Line 181 in 82474e7
Using this, we can eliminate our use of |
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 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 ( 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 did you get a chance to look at this yet? |
@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. |
Sorry fell off my radar. Really busy the next few weeks. |
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 |
And update the LICENSE accordingly. |
My concern would be twofold:
|
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 |
Maybe I'm misunderstanding something. The file in question here is |
I didn't. Read my words like this:
|
The stack overflow post is based on It's fairly unlikely that libnatpmp had the code from stack overflow since |
Amazing! Excellent find indeed. |
Platform
ios
Plugin
network_info_plus
Version
1.1.0
Flutter SDK
N/A
Steps to reproduce
It recently came to my attention that #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: #1045 (comment) 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
Logs
Flutter Doctor
The text was updated successfully, but these errors were encountered: