Licensing is confusing. Many $ have been spent by companies on lawyers to intepret their obligations wrt software licenses. Millions of $ in company / IP acquisitions have been held up by incorrect uses of licenses. Add to that, a lot of the competitors here do not use English as their first language. Licensing in English is confusing enough as a native speaker. Frustration is understandable.
\n\nTo this point licensing hasn't been a huge concern in most challenges. By far the most common licenses for open-source ML code are BSD 3.0, Apache 2.0, and MIT -- which can all be made compliant with each other so long as you pass through any of the restrictions/requirements (attributions, non-advertising clauses, reproduction of disclaimers/copyrights, etc). Having a very capable and easy to use package like YoloV5 under the GPLv3 license clearly changes this.
\n\nA recommendation to Kaggle for future challenges, a high level license compatibility matrix embedded in the rules would be very helpful. In plain english, no vagueness, err on being somewhat restrictive/defensive in interpetation for clarities sake. Simply pointing to an external license page isn't really good enough, it still involves license/legal speak. Make it clear what licenses are actually 'compliant' with the required solution license. It'd be easy to do by basically clumping the most common licenses along copyleft and non-copyleft boundaries.
\n\nFor communications with contestants in the forums also strive for clarity. Organizers parroting the 'Solutions that are using a non-MIT license do not comply with the rules to win the competition.' line don't seem to understand that it is really NOT clear to a lot of the people here -- that their SOLUTION needs to be MIT licensed does not imply that the components of the solution must ALL be MIT but must be COMPATIBLE with MIT is the key. You must understand this is a point of confusion yet you don't clarify yourself and let others do it for you.
\n\nIn addition to making it clear to competitors with a simplified grouping. It seems appropriate to educate hosts. In this case, since the host is an education institution, one would assume they may have actually been okay with a GPLv3 licensed solution if they were made aware of the tradeoffs at the start. It's not like most hosts will be taking a given solution, combining it with their own IP, and taking it straight to product.
", "messages": [ { "id": "929660", "postDate": "07/14/2020 20:33:17", "content": "Licensing is confusing. Many $ have been spent by companies on lawyers to intepret their obligations wrt software licenses. Millions of $ in company / IP acquisitions have been held up by incorrect uses of licenses. Add to that, a lot of the competitors here do not use English as their first language. Licensing in English is confusing enough as a native speaker. Frustration is understandable.
\n\nTo this point licensing hasn't been a huge concern in most challenges. By far the most common licenses for open-source ML code are BSD 3.0, Apache 2.0, and MIT -- which can all be made compliant with each other so long as you pass through any of the restrictions/requirements (attributions, non-advertising clauses, reproduction of disclaimers/copyrights, etc). Having a very capable and easy to use package like YoloV5 under the GPLv3 license clearly changes this.
\n\nA recommendation to Kaggle for future challenges, a high level license compatibility matrix embedded in the rules would be very helpful. In plain english, no vagueness, err on being somewhat restrictive/defensive in interpetation for clarities sake. Simply pointing to an external license page isn't really good enough, it still involves license/legal speak. Make it clear what licenses are actually 'compliant' with the required solution license. It'd be easy to do by basically clumping the most common licenses along copyleft and non-copyleft boundaries.
\n\nFor communications with contestants in the forums also strive for clarity. Organizers parroting the 'Solutions that are using a non-MIT license do not comply with the rules to win the competition.' line don't seem to understand that it is really NOT clear to a lot of the people here -- that their SOLUTION needs to be MIT licensed does not imply that the components of the solution must ALL be MIT but must be COMPATIBLE with MIT is the key. You must understand this is a point of confusion yet you don't clarify yourself and let others do it for you.
\n\nIn addition to making it clear to competitors with a simplified grouping. It seems appropriate to educate hosts. In this case, since the host is an education institution, one would assume they may have actually been okay with a GPLv3 licensed solution if they were made aware of the tradeoffs at the start. It's not like most hosts will be taking a given solution, combining it with their own IP, and taking it straight to product.
", "rawMarkdown": "Licensing is confusing. Many $ have been spent by companies on lawyers to intepret their obligations wrt software licenses. Millions of $ in company / IP acquisitions have been held up by incorrect uses of licenses. Add to that, a lot of the competitors here do not use English as their first language. Licensing in English is confusing enough as a native speaker. Frustration is understandable.\n\nTo this point licensing hasn't been a huge concern in most challenges. By far the most common licenses for open-source ML code are BSD 3.0, Apache 2.0, and MIT -- which can all be made compliant with each other so long as you pass through any of the restrictions/requirements (attributions, non-advertising clauses, reproduction of disclaimers/copyrights, etc). Having a very capable and easy to use package like YoloV5 under the GPLv3 license clearly changes this.\n\nA recommendation to Kaggle for future challenges, a high level license compatibility matrix embedded in the rules would be very helpful. In plain english, no vagueness, err on being somewhat restrictive/defensive in interpetation for clarities sake. Simply pointing to an external license page isn't really good enough, it still involves license/legal speak. Make it clear what licenses are actually 'compliant' with the required solution license. It'd be easy to do by basically clumping the most common licenses along copyleft and non-copyleft boundaries.\n\nFor communications with contestants in the forums also strive for clarity. Organizers parroting the 'Solutions that are using a non-MIT license do not comply with the rules to win the competition.' line don't seem to understand that it is really NOT clear to a lot of the people here -- that their SOLUTION needs to be MIT licensed does not imply that the components of the solution must ALL be MIT but must be COMPATIBLE with MIT is the key. You must understand this is a point of confusion yet you don't clarify yourself and let others do it for you.\n\nIn addition to making it clear to competitors with a simplified grouping. It seems appropriate to educate hosts. In this case, since the host is an education institution, one would assume they may have actually been okay with a GPLv3 licensed solution if they were made aware of the tradeoffs at the start. It's not like most hosts will be taking a given solution, combining it with their own IP, and taking it straight to product.", "votes": null }, { "id": "929683", "postDate": "07/14/2020 21:00:58", "content": "I agree and think this has been very well said. Incorporating what Ross has said in to pre-competition checklists would be an excellent idea. Having been involved in setting up a predictive challenge myself I do recognise that it isn't easy, and, situations arise that weren't anticipated. This is why having checklists that are informed by past experiences and are constantly updated is a super helpful idea.
", "rawMarkdown": "I agree and think this has been very well said. Incorporating what Ross has said in to pre-competition checklists would be an excellent idea. Having been involved in setting up a predictive challenge myself I do recognise that it isn't easy, and, situations arise that weren't anticipated. This is why having checklists that are informed by past experiences and are constantly updated is a super helpful idea.", "votes": null }, { "id": "929686", "postDate": "07/14/2020 21:04:15", "content": "Very well said Ross! I agree with your recommendations and think this issue could've been cleared up a lot sooner. I for one, and I'm sure many other competitors, are extremely grateful to you for contributing your time and expertise to help us all. You have provided far more information and help than the Kaggle team or competition organizers. So thank you very much for supporting us throughout this competition, especially on the topic of licensing and for openly sharing your EfficientDet implementation to the competitors here.
", "rawMarkdown": "Very well said Ross! I agree with your recommendations and think this issue could've been cleared up a lot sooner. I for one, and I'm sure many other competitors, are extremely grateful to you for contributing your time and expertise to help us all. You have provided far more information and help than the Kaggle team or competition organizers. So thank you very much for supporting us throughout this competition, especially on the topic of licensing and for openly sharing your EfficientDet implementation to the competitors here.", "votes": null }, { "id": "929762", "postDate": "07/14/2020 23:34:45", "content": "I totally agree, and to add a little bit...
\n\nMany competitors here have literally spent 1000's of hours in the past month or so honing their YOLOv5 models (not to mention the $), only to be stopped cold in their tracks with the confusion about using this particular framework/algorithm.
\n\nThere was a post from one of the hosts Etienne David, and I quote verbatim:
\n\n> Importing or using a software BSD licence does not invalidate your solution because it is not a copyleft licence. LGPL is also authorized if you only import it. Only GPL-v3 is an issue for this competition as it is not clear if your winning solution can stay MIT or not, except if you are only importing the library and not modifying
\n\nSo what does the above post mean exactly?
\n\nWith 21 days to go, are we then going to just abandon all the effort that went to YOLOv5 models and start from scratch?
", "rawMarkdown": "I totally agree, and to add a little bit...\n\nMany competitors here have literally spent 1000's of hours in the past month or so honing their YOLOv5 models (not to mention the $), only to be stopped cold in their tracks with the confusion about using this particular framework/algorithm. \n\nThere was a post from one of the hosts [Etienne David](https://www.kaggle.com/c/global-wheat-detection/discussion/164845), and I quote *verbatim*:\n\n> Importing or using a software BSD licence does not invalidate your solution because it is not a copyleft licence. LGPL is also authorized if you only import it. Only GPL-v3 is an issue for this competition as it is not clear if your winning solution can stay MIT or not, except if you are only importing the library and not modifying\n\nSo what does the above post mean exactly?\n\nWith 21 days to go, are we then going to just abandon all the effort that went to YOLOv5 models and start from scratch?", "votes": null }, { "id": "929893", "postDate": "07/15/2020 03:50:07", "content": "Well said. The host should make an official post specifying what exactly is allowed and what isn't. Though I'm not using YoloV5 and also spent hundreds of hours on my own pipeline, I do appreciate everyone's effort. By the nature of a competition, the host should be crystal clear about the exact rules so that no one's work is wasted.
", "rawMarkdown": "Well said. The host should make an official post specifying what exactly is allowed and what isn't. Though I'm not using YoloV5 and also spent hundreds of hours on my own pipeline, I do appreciate everyone's effort. By the nature of a competition, the host should be crystal clear about the exact rules so that no one's work is wasted.", "votes": null }, { "id": "930233", "postDate": "07/15/2020 09:36:58", "content": "Agreed, Apache, BSD should be OK.
", "rawMarkdown": "Agreed, Apache, BSD should be OK.", "votes": null } ], "comments": [ { "id": 929683, "author_name": "datahobbit", "author_url": "", "post_date": "07/14/2020 21:00:58", "content": "I agree and think this has been very well said. Incorporating what Ross has said in to pre-competition checklists would be an excellent idea. Having been involved in setting up a predictive challenge myself I do recognise that it isn't easy, and, situations arise that weren't anticipated. This is why having checklists that are informed by past experiences and are constantly updated is a super helpful idea.
", "votes": null, "replies": [] }, { "id": 929686, "author_name": "matthewmasters", "author_url": "", "post_date": "07/14/2020 21:04:15", "content": "Very well said Ross! I agree with your recommendations and think this issue could've been cleared up a lot sooner. I for one, and I'm sure many other competitors, are extremely grateful to you for contributing your time and expertise to help us all. You have provided far more information and help than the Kaggle team or competition organizers. So thank you very much for supporting us throughout this competition, especially on the topic of licensing and for openly sharing your EfficientDet implementation to the competitors here.
", "votes": null, "replies": [] }, { "id": 929762, "author_name": "mperutti", "author_url": "", "post_date": "07/14/2020 23:34:45", "content": "I totally agree, and to add a little bit...
\n\nMany competitors here have literally spent 1000's of hours in the past month or so honing their YOLOv5 models (not to mention the $), only to be stopped cold in their tracks with the confusion about using this particular framework/algorithm.
\n\nThere was a post from one of the hosts Etienne David, and I quote verbatim:
\n\n> Importing or using a software BSD licence does not invalidate your solution because it is not a copyleft licence. LGPL is also authorized if you only import it. Only GPL-v3 is an issue for this competition as it is not clear if your winning solution can stay MIT or not, except if you are only importing the library and not modifying
\n\nSo what does the above post mean exactly?
\n\nWith 21 days to go, are we then going to just abandon all the effort that went to YOLOv5 models and start from scratch?
", "votes": null, "replies": [] }, { "id": 929893, "author_name": "alexanderliao", "author_url": "", "post_date": "07/15/2020 03:50:07", "content": "Well said. The host should make an official post specifying what exactly is allowed and what isn't. Though I'm not using YoloV5 and also spent hundreds of hours on my own pipeline, I do appreciate everyone's effort. By the nature of a competition, the host should be crystal clear about the exact rules so that no one's work is wasted.
", "votes": null, "replies": [] }, { "id": 930233, "author_name": "jiwongpark", "author_url": "", "post_date": "07/15/2020 09:36:58", "content": "Agreed, Apache, BSD should be OK.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "929660": "Licensing is confusing. Many $ have been spent by companies on lawyers to intepret their obligations wrt software licenses. Millions of $ in company / IP acquisitions have been held up by incorrect uses of licenses. Add to that, a lot of the competitors here do not use English as their first language. Licensing in English is confusing enough as a native speaker. Frustration is understandable.\n\nTo this point licensing hasn't been a huge concern in most challenges. By far the most common licenses for open-source ML code are BSD 3.0, Apache 2.0, and MIT -- which can all be made compliant with each other so long as you pass through any of the restrictions/requirements (attributions, non-advertising clauses, reproduction of disclaimers/copyrights, etc). Having a very capable and easy to use package like YoloV5 under the GPLv3 license clearly changes this.\n\nA recommendation to Kaggle for future challenges, a high level license compatibility matrix embedded in the rules would be very helpful. In plain english, no vagueness, err on being somewhat restrictive/defensive in interpetation for clarities sake. Simply pointing to an external license page isn't really good enough, it still involves license/legal speak. Make it clear what licenses are actually 'compliant' with the required solution license. It'd be easy to do by basically clumping the most common licenses along copyleft and non-copyleft boundaries.\n\nFor communications with contestants in the forums also strive for clarity. Organizers parroting the 'Solutions that are using a non-MIT license do not comply with the rules to win the competition.' line don't seem to understand that it is really NOT clear to a lot of the people here -- that their SOLUTION needs to be MIT licensed does not imply that the components of the solution must ALL be MIT but must be COMPATIBLE with MIT is the key. You must understand this is a point of confusion yet you don't clarify yourself and let others do it for you.\n\nIn addition to making it clear to competitors with a simplified grouping. It seems appropriate to educate hosts. In this case, since the host is an education institution, one would assume they may have actually been okay with a GPLv3 licensed solution if they were made aware of the tradeoffs at the start. It's not like most hosts will be taking a given solution, combining it with their own IP, and taking it straight to product.", "929683": "I agree and think this has been very well said. Incorporating what Ross has said in to pre-competition checklists would be an excellent idea. Having been involved in setting up a predictive challenge myself I do recognise that it isn't easy, and, situations arise that weren't anticipated. This is why having checklists that are informed by past experiences and are constantly updated is a super helpful idea.", "929686": "Very well said Ross! I agree with your recommendations and think this issue could've been cleared up a lot sooner. I for one, and I'm sure many other competitors, are extremely grateful to you for contributing your time and expertise to help us all. You have provided far more information and help than the Kaggle team or competition organizers. So thank you very much for supporting us throughout this competition, especially on the topic of licensing and for openly sharing your EfficientDet implementation to the competitors here.", "929762": "I totally agree, and to add a little bit...\n\nMany competitors here have literally spent 1000's of hours in the past month or so honing their YOLOv5 models (not to mention the $), only to be stopped cold in their tracks with the confusion about using this particular framework/algorithm. \n\nThere was a post from one of the hosts [Etienne David](https://www.kaggle.com/c/global-wheat-detection/discussion/164845), and I quote *verbatim*:\n\n> Importing or using a software BSD licence does not invalidate your solution because it is not a copyleft licence. LGPL is also authorized if you only import it. Only GPL-v3 is an issue for this competition as it is not clear if your winning solution can stay MIT or not, except if you are only importing the library and not modifying\n\nSo what does the above post mean exactly?\n\nWith 21 days to go, are we then going to just abandon all the effort that went to YOLOv5 models and start from scratch?", "929893": "Well said. The host should make an official post specifying what exactly is allowed and what isn't. Though I'm not using YoloV5 and also spent hundreds of hours on my own pipeline, I do appreciate everyone's effort. By the nature of a competition, the host should be crystal clear about the exact rules so that no one's work is wasted.", "930233": "Agreed, Apache, BSD should be OK." }, "source": "meta" }