Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Ah, but actually the upstream respond JS doesn't seem to be in the whitelist yet, so re-purposing for that.
https://github.com/scottjehl/Respond seems to be the canonical repo and according to README.md it's dual-licensed MIT and GPL. Marking RTBC for the upstream library. For any Panopoly-specific modifications, those should happen with just standard 3rd-party-library patching in the drupal_org.make file, IMO.
I think, with some of the original ones I added, I had mistakenly added MIT *and* GPLv2 because of the repetition with the libraries being added. You may find one or two more like that.
CreditAttribution: apaderno as a volunteer commented
Actually, the license was added on November, 2013, later than when the library was added to the whitelist here. It could be the author changed mind later.
Hrm. Removing respondjs is going to break releasing Panopoly and all Panopoly-based distributions. :-/ I only just discovered it now, when trying to do a security release of Panopoly for the Features release (SA-CONTRIB-2016-020) yesterday.
Is it possible to get special dispensation for this one security release and then allow the Panopoly community to figure out a solution immediately afterwards?
Actually, since this library is to support IE6-8, I think I'm just going to remove it from Panopoly and put instructions to install the library in the release notes. This would have been nicer to do when doing a non-security release, but we'll make do. :-)
Not sure why this was removed. MIT can now be committed to a project, but it can still be whitelisted. Not being able to inform developers (or even being able to figure out who is using this entry) is why we haven't removed any of the whitelist entries that violate the clarified policy. If you have suggestions for how we should handle this moving forward, please add them to #2307487: Warn distributions using non-whitelisted licenses that entries will be removed
For now, I'd recommend restoring the whitelist entry, and having the LWG handle any removals, which ideally could come with ample notice to project maintainers like dsnopek so they're not caught unawares whilst trying to get a security release out.
CreditAttribution: apaderno as a volunteer commented
I apologize for my mistake, but I took there was a problem with the licensing of the library, which was changed in the while. If LWG means Library Packaging Whitelist, I am part of the LWG. I don't watch this project queue as moderator.
Hrm, I wish I had waited 4 more hours to release! We have a policy of releasing the same day (or at latest the next day) for any security issues in core or contrib that affect Panopoly, and so I felt like I was already running late. :-/
Anyway, thanks for adding it back and the clarification on what's allowed, but especially for the plans to give more notice in the future! That would really help a lot. :-)
I have a feeling we may want to have another informal meeting at this year's DrupalCon to talk about policy/process for a package's removal, plus where things are going in terms of Composer support and its impact on this entire whitelisting effort...
The meeting in LA wasn't really planned. I was actually shocked that we were able to discuss licensing and packaging with key people as long as we were. Unfortunately most of the LWG won't be in NOLA including me. The most of the University of Colorado's development teams will be there, but we're expecting a baby that week. I'm actually going on paternity leave soon, so I can commit to getting all of the LWG changes published for community feedback to keep things moving forward.
There are a number of conversations going on about both licensing and packaging in various issues and email threads. The DA has also asked for professional legal advice on some of these topics.
I've started publishing the proposed changes to documents that we've actually been able to agree on to http://drupal-lwg.github.io/. We've started with FAQ and haven't even gotten into the backlog of whitelist issue, but please provide feedback or PRs.
Comments
Comment #1
webchickAnother one of these. :) Could we do this with patches instead, so the whitelist only references the canonical library?
libraries[ckeditor][patch][] = "http://drupal.org/files/1337004-ckeditor-remove-samples-3.patch"
Comment #2
webchickAh, but actually the upstream respond JS doesn't seem to be in the whitelist yet, so re-purposing for that.
https://github.com/scottjehl/Respond seems to be the canonical repo and according to README.md it's dual-licensed MIT and GPL. Marking RTBC for the upstream library. For any Panopoly-specific modifications, those should happen with just standard 3rd-party-library patching in the drupal_org.make file, IMO.
Comment #3
geerlingguy CreditAttribution: geerlingguy commentedAdded Respond.JS: http://drupal.org/node/1509884
Comment #5
kreynen CreditAttribution: kreynen commentedI don't know why this was tagged as MIT and GPLv2. Based on https://github.com/scottjehl/Respond/blob/master/LICENSE-MIT, I think it's only MIT.
Comment #6
geerlingguy CreditAttribution: geerlingguy commentedI think, with some of the original ones I added, I had mistakenly added MIT *and* GPLv2 because of the repetition with the libraries being added. You may find one or two more like that.
Comment #7
apadernoActually, the license was added on November, 2013, later than when the library was added to the whitelist here. It could be the author changed mind later.
Comment #8
apadernoIn fact, in https://github.com/scottjehl/Respond/blob/master/README.md I now read Licensed under the MIT license. I am going to remove the library.
Comment #9
apadernoIn the case it is needed, these are the whitelisted URLs it contained.
Comment #10
dsnopekHrm. Removing respondjs is going to break releasing Panopoly and all Panopoly-based distributions. :-/ I only just discovered it now, when trying to do a security release of Panopoly for the Features release (SA-CONTRIB-2016-020) yesterday.
Is it possible to get special dispensation for this one security release and then allow the Panopoly community to figure out a solution immediately afterwards?
Comment #11
dsnopekActually, since this library is to support IE6-8, I think I'm just going to remove it from Panopoly and put instructions to install the library in the release notes. This would have been nicer to do when doing a non-security release, but we'll make do. :-)
Comment #12
webchickEr. Since when is it a problem for MIT-only licensed code to be in the whitelist?
Comment #13
kreynen CreditAttribution: kreynen at University of Colorado Boulder commentedNot sure why this was removed. MIT can now be committed to a project, but it can still be whitelisted. Not being able to inform developers (or even being able to figure out who is using this entry) is why we haven't removed any of the whitelist entries that violate the clarified policy. If you have suggestions for how we should handle this moving forward, please add them to #2307487: Warn distributions using non-whitelisted licenses that entries will be removed
Comment #14
webchickFor now, I'd recommend restoring the whitelist entry, and having the LWG handle any removals, which ideally could come with ample notice to project maintainers like dsnopek so they're not caught unawares whilst trying to get a security release out.
Comment #15
kreynen CreditAttribution: kreynen at University of Colorado Boulder commentedI've added this back https://www.drupal.org/node/2706545
Comment #16
apadernoI apologize for my mistake, but I took there was a problem with the licensing of the library, which was changed in the while. If LWG means Library Packaging Whitelist, I am part of the LWG. I don't watch this project queue as moderator.
Comment #17
dsnopekHrm, I wish I had waited 4 more hours to release! We have a policy of releasing the same day (or at latest the next day) for any security issues in core or contrib that affect Panopoly, and so I felt like I was already running late. :-/
Anyway, thanks for adding it back and the clarification on what's allowed, but especially for the plans to give more notice in the future! That would really help a lot. :-)
Thanks again!
Comment #18
geerlingguy CreditAttribution: geerlingguy commentedI have a feeling we may want to have another informal meeting at this year's DrupalCon to talk about policy/process for a package's removal, plus where things are going in terms of Composer support and its impact on this entire whitelisting effort...
Comment #19
kreynen CreditAttribution: kreynen at University of Colorado Boulder commentedThe meeting in LA wasn't really planned. I was actually shocked that we were able to discuss licensing and packaging with key people as long as we were. Unfortunately most of the LWG won't be in NOLA including me. The most of the University of Colorado's development teams will be there, but we're expecting a baby that week. I'm actually going on paternity leave soon, so I can commit to getting all of the LWG changes published for community feedback to keep things moving forward.
There are a number of conversations going on about both licensing and packaging in various issues and email threads. The DA has also asked for professional legal advice on some of these topics.
I've started publishing the proposed changes to documents that we've actually been able to agree on to http://drupal-lwg.github.io/. We've started with FAQ and haven't even gotten into the backlog of whitelist issue, but please provide feedback or PRs.
Comment #20
geerlingguy CreditAttribution: geerlingguy commented@kreynen - Thank you so much for your leadership here, and enjoy the baby!