Re: Clarity on current status of Scientific Linux build
On 23/06/2014 14:54, Steven Timm wrote: I was at the HEPiX meeting at which those slides were presented and there was further discussion during the course of the week as to what would happen. RedHat/CentOS was also represented at that meeting in the person of Karanbir Singh. You should not presume that the presentations given at that meeting are the final word. You notice that nobody with a cern.ch or fnal.gov E-mail address has responded to this thread up until now. When they have something concrete they will respond with the details. Steve Timm (Apologies if you've seen this twice. Posting via Hotmail is less than ideal). So, in short, complete clarity is not yet available, if I understand correctly? However, based upon the balance of probabilities, it looks likely that SL7 will not be based directly on RHEL7 but on CentOS. If so, it does raise the question of why continued with SL at all. It would be very sad indeed if this is the case.
Re: Clarity on current status of Scientific Linux build
Thanks to everyone who commented and I apologise for the delay in replying. So it seems that complete clarity is not yet available. Ok. A couple more questions in the search for clarity:- 1) Can anyone confirm or deny that Red Hat places contractual limitations on what a subscriber (who has access to the RHEL7 SRPMs) can do with the source code so obtained? Yes, I know this has been discussed but I don't think it has been explicitly confirmed. One must infer that there are contractual limitations (otherwise why remove public access to SRPMs) but it would be nice to be absolutely clear. 2) This is a legal question but it is relevant: If Red Hat uses a contract with its customers to prevent a customer who is a recipient of the GPLd source code (when received via SRPM) from redistributing it or rebuilding it as they please, wouldn't this mean that Red Hat itself was in breach of the GPL licence conditions?
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 03:28 PM, Mark Rousell wrote: 1) Can anyone confirm or deny that Red Hat places contractual limitations on what a subscriber (who has access to the RHEL7 SRPMs) can do with the source code so obtained? Please read http://lwn.net/Articles/432012/ and http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html (especially the 12th paragraph). For legal advice, you should consult with your lawyer. We non-lawyer types aren't qualified to give legal advice; the lawyers on this list won't likely give you legal advice in public, either.
Re: Clarity on current status of Scientific Linux build
On Fri, Jun 27, 2014 at 08:17:19PM +0100, Mark Rousell wrote: However, based upon the balance of probabilities, it looks likely that SL7 will not be based directly on RHEL7 but on CentOS. If so, ... why continued with SL at all. The 800lbs gorilla in the room is CERN (and other large physics labs), who require a linux (some linux) to run the large compute farms for analysis of LHC data. For historical reasons, this linux has been Red Hat based (and we know it under the names SL and SLC). Will it remain Red Hat based? Will the next cern linux be ubuntu/debian based? Will Red Hat relax their rules to keep CERN (and the HEP community)? As an added kink, with the major changes from RHEL6 to RHEL7, the cost of going from SLC6 to RHEL based SLC7 becomes comparable to going from SLC6 to a ubuntu/debian based SLC? Whatever the case, there will continue to exist a linux of production quality and of free or affordable cost. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 01:14 PM, Lamar Owen wrote: On 06/27/2014 03:44 PM, Konstantin Olchanski wrote: The 800lbs gorilla in the room is CERN (and other large physics labs), who require a linux (some linux) to run the large compute farms for analysis of LHC data. For historical reasons, this linux has been Red Hat based (and we know it under the names SL and SLC). Will it remain Red Hat based? ... The CERN direction I would think is crystal-clear: http://www.karan.org/blog/2014/06/10/centos-community-buildsystem-bootstraping-by-the-cern-linux-team/ http://linux.web.cern.ch/linux/docs/GDB%2020140212%20-%20Future%20of%20Scientific%20Linux%20in%20light%20of%20recent%20CentOS%20project%20changes..pdf http://lists.centos.org/pipermail/centos-devel/2014-June/010517.html In a nutshell: it sure looks like SLC will remain Red Hat based. SLC developers have joined the CentOS Core SIG and are actively working on CentOS infrastructure. If you want to see more, follow the centos-devel list; come to your own conclusions by seeing the actions. Just so that the SL list has a specific inclusion of this information (in the event the CentOS lists somehow become unavailable), below is the last item in the above set. CentOS-devel] Welcoming CERN Linux Distro team *Karanbir Singh* kbsingh at centos.org mailto:centos-devel%40centos.org?Subject=Re:%20%5BCentOS-devel%5D%20Welcoming%20CERN%20Linux%20Distro%20teamIn-Reply-To=%3C53970C1B.9040305%40centos.org%3E /Tue Jun 10 13:46:03 UTC 2014/ * Previous message: [CentOS-devel] CentOS 7 Artwork http://lists.centos.org/pipermail/centos-devel/2014-June/010519.html * Next message: [CentOS-devel] Welcoming CERN Linux Distro team http://lists.centos.org/pipermail/centos-devel/2014-June/010518.html * *Messages sorted by:* [ date ] http://lists.centos.org/pipermail/centos-devel/2014-June/date.html#10517 [ thread ] http://lists.centos.org/pipermail/centos-devel/2014-June/thread.html#10517 [ subject ] http://lists.centos.org/pipermail/centos-devel/2014-June/subject.html#10517 [ author ] http://lists.centos.org/pipermail/centos-devel/2014-June/author.html#10517 Hi Everyone, We would like to welcome onboard the CERN Linux Distro team ( http://cern.ch/linux ) to the CentOS Core SIG. Thomas Oulevey and Jaroslaw 'Jarek' Polok are going to be bootstrapping the CentOS Community Buildsystem around Koji and helping run it going forward. The community buildsystem is going to be the central place for all source to binary builds used by all efforts other than CentOS Core ( for now ). The initial target is to get a test instance running in the coming weeks, and then work on the git.centos.org integration, with the aim of having the 'production' buildsys online soon. This is the build service that all SIG's and Core SIG builds will consume going forward ( with the exception of CentOS Linux, we have quite a bit of work to do before we can migrate that ). Communications on this effort will be on the centos-devel mailing list ( http://lists.centos.org/mailman/listinfo/centos-devel ) and on the #centos-devel irc channel on irc.freenode.net. Hardware resources for the effort have been identified, setup and access is being setup so things can start rolling fairly quickly. Mike McLean and Fabian Arrotin are going to be working with them. You can keep up with Jarek on his google+ page at https://plus.google.com/+JaroslawPolok/ and Thomas tweets at https://twitter.com/thomasnomas ; They both also contribute to the http://linux.web.cern.ch/linux/ blog. Please join me in welcoming Thomas and Jarek to the CentOS Project. - KB End quote. Several questions: 1. Is CERN linux the same as SL? 1.1 Are any of the Fermilab team doing the same as in the posting from Singh? 2. Evidently, Singh and other core CentOS team members actually are Red Hat employees, just as the core SL team have been Fermilab or CERN employees (presumably in some cases actually paid by the research collaborations funded by various government agencies through various universities -- e.g., in the USA, NSF or DOE with each PI typically holding a tenure-stream faculty position at a university). Will the core SL team or the core CERN linux team likewise become Red Hat employees? 2,1 As Red Hat employees, one assumes their primary loyalty are to and directions come from their corporate employer. Is this consistent with a SL-type distribution in which the user community (such as the CERN LHC collaborations) have ultimate needs, not those of a for-profit corporation? 3. Will SL just be a SIG of CentOS? Yasha Karant
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 20:43, Lamar Owen wrote: On 06/27/2014 03:28 PM, Mark Rousell wrote: 1) Can anyone confirm or deny that Red Hat places contractual limitations on what a subscriber (who has access to the RHEL7 SRPMs) can do with the source code so obtained? Please read http://lwn.net/Articles/432012/ and http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html (especially the 12th paragraph). Yup, I've read those and whilst they address the issue they only answer it by inference and reference, not quite as explicitly as I'd ideally like. I think this the paragraph in the latter article you meant (it certainly covers the key point you responded to): I do have strong, negative opinions about the RHEL business model; I have long called it the if you like copyleft, your money is no good here business model. It's a GPL-compliant business model merely because the GPL is silent on whether or not you must keep someone as your customer. Red Hat tells RHEL customers that if they chose to engage in their rights under GPL, then their support contract will be canceled. Indeed, I am aware of this. I was in fact going to write Can anyone confirm or deny that Red Hat places contractual limitations (where the contract is freely entered into) in my earlier message but it was too much of a mental mouthful. Whilst Red Hat can certainly create whatever contractual terms it wants and customers can freely agree to them, this does not in general automatically or necessarily mean that Red Hat itself is not in breach of a licence (GPL in this case) by creating certain limiting contractual terms with its customers. It does surprise that limiting a customer's rights with respect to GPL (even if it just while the customer freely chooses to remain a customer of Red Hat) is not a GPL-violating action for Red Hat itself. Clearly, however, Red Hat's lawyers (and the FSF it seems) think such a limitation is not a violation of GPL. For what it's worth, such limiting contractual terms (even if freely entered into) do seem on the face of it to be a violation of clause 6 of GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway, as above, it seems that FSF disagrees with me so I need to read GPL2 and 3 much more thoroughly! For legal advice, you should consult with your lawyer. We non-lawyer types aren't qualified to give legal advice; the lawyers on this list won't likely give you legal advice in public, either. Well, that's the usual advice but of course this does seem to be a relevant issue. Anyway, I accept that the question over Red Hat's legal right to effectively restrict GPL can't go much further on this list.
Re: Clarity on current status of Scientific Linux build
On Fri, Jun 27, 2014 at 4:49 PM, Yasha Karant ykar...@csusb.edu wrote: 1. Is CERN linux the same as SL? http://linux.web.cern.ch/linux/scientific.shtml
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 22:16, Mark Rousell wrote: On 27/06/2014 20:43, John Lauro wrote: One reason to remove public sources is to keep the load off of their servers. Yes, that's one reasons. There are other reasons too, of course. My might will infer that other reasons are the overridingly significant ones in this case. ;-) Oops, a typo. I meant to write: Yes, that's one reason. There are other reasons too, of course. One might well infer that the other reasons are the overridingly significant ones in this case. ;-)
Re: Clarity on current status of Scientific Linux build
On Fri, Jun 27, 2014 at 08:28:49PM +0100, Mark Rousell wrote: 1) Can anyone confirm or deny that ... For you, I can confirm or deny anything and everything. The moon is made out of Swiss cheese. 100% confirmed. Yes. (but is it helpful?) 2) This is a legal question but ... For this you need legal advice. Free legal advice is not legal advice. A couple more questions in the search for clarity:- You will not find clarity on the net of a million lies. Do your own research and hire your own lawyer. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Ask Red Hat for clarification about differentiating between RH source and CentOS on git.centos.org?
Apologies for starting a new thread but this seems to warrant one. On another mail list where the issue of Scientific Linux versus RHEL7 has been mentioned in passing, an employee of Red Hat has offered to seek clarification about the RHEL/CentOS source code identification/verification/tracing issue with git.centos.org. Here is the passage (written by me) that the Red Hat employee intends to pass on for clarification if I take up his offer: The problem with the source available via Git is that, whilst no one doubts it is all there, it is apparently not currently clear to anyone outside of Red Hat or CentOS what is the unadulterated Red Hat source and what is source altered by CentOS for its own build. It is not for nothing that the source is now only being made publicly available via git.centos.org and not directly from Red Hat. Third parties such as Scientific Linux (and of course Oracle...) need to know what is the unadulterated Red Hat source to be able to build properly. I understand that discussions are continuing to which I am not privy but if you can shed light on how to unmistakeably extract guaranteed Red Hat (rather than possibly altered-for-CentOS- distribution) source code from git.centos.org then I am sure the Scientific Linux community would love to hear about it. He says: I am very happy to seek clarification. May I quote or paraphrase the above? Should I ask him to go ahead and seek clarification or should I tell him to drop it? Is it worth taking up his offer, given the email from CentOS-Devel written by Karanbir Singh and posted here by Yasha Karant at 13:49:12 -0700, which seems to me to possibly address these source code identification issues if I understand it correctly? Would anyone like to craft a better phrased question than my own one above (which is just a quote from an earlier message in the thread with him)?
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 05:07 PM, Mark Rousell wrote: Clearly, however, Red Hat's lawyers (and the FSF it seems) think such a limitation is not a violation of GPL. For what it's worth, such limiting contractual terms (even if freely entered into) do seem on the face of it to be a violation of clause 6 of GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway, as above, it seems that FSF disagrees with me so I need to read GPL2 and 3 much more thoroughly! For what it's worth, Bradley Kuhn has spent a great deal of time and effort in dealing with GPL violations. The fact that even he concedes it is likely not a GPL violation speaks volumes; the fact that he, the FSF, etc, have not initiated a lawsuit against Red Hat for a GPL violation speaks even louder. I was taught as a child that actions speak louder than words; and inaction speaks louder yet, especially as he finds Red Hat's practice to be distasteful. If there were a case to be made I would think Mr. Kuhn or another similarly-opinioned individual would have made it by now; this issue has been around for a decade, it's not a new thing. But my favorite line from his other post is simply this: I do find myself wishing that the people debating whether the exact right number of angels are dancing on the head of this particular GPL pin would instead spend some time helping to end the flagrant, constant, and obvious GPL violations with which I spent much time dealing time each week.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 04:49 PM, Yasha Karant wrote: ... 1. Is CERN linux the same as SL? Scientific Linux CERN is what is being talked about here. 1.1 Are any of the Fermilab team doing the same as in the posting from Singh? ... You should read the archives of the centos-devel list and note the number of accepted patches to the buildsystem and to packages that are being made by persons with fnal.gov affiliation. 2,1 As Red Hat employees, one assumes their primary loyalty are to and directions come from their corporate employer. Is this consistent with a SL-type distribution in which the user community (such as the CERN LHC collaborations) have ultimate needs, not those of a for-profit corporation? You know, I have to chuckle at this. SL is already driven by the needs of Red Hat, counting by number of lines of source code (and the source doesn't just drop out of the sky fully formed, after all; Red Hat invests a large amount of development time building the source to begin with, including funding developers for the upstream projects that all Linux distributions utilize (yes, the Linux kernel itself, to which Red Hat has done a massive amount of work)). Nothing says Red Hat's needs and the communities' needs are not or cannot be in alignment; on the contrary, the fact of the SL rebuild even existing shows how well Red Hat's needs and the communities' needs are aligned. The other fact of the matter is that both fnal and CERN have and use RHEL licenses for other areas. The fact that Red Hat is able to turn a profit and still so closely match the communities' needs is quite remarkable. 3. Will SL just be a SIG of CentOS? The SL team will have to answer that one, in their own time. IOW, be patient. In reality, there are far more things in common between SL and CentOS than are different, as they are after all built from almost entirely the same source code base. It's great to see open collaboration going on in the rebuild effort; a breath of fresh air, really.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 05:26 PM, Mark Rousell wrote: The cessation of SRPM distribution in general to non-customers, which is the specific issue at hand here, is a new issue that has new considerations to take into account. Whilst it has similarities to the kernel issue in 2011 it also goes further. The SRPM issue is not a new one, either. Try to find the EUS sources, for instance. Or, to go to another, different, distribution, let's find the SuSE Enterprise Linux Server SRPMS, the updates of which have been only available to subscribers for, to the best of my knowledge, at least ten years. You certainly won't find SRPMS in a quick skim of ftp.suse.com. (The latest SLES download is SLES 11 SP3, from July of 2013, nearly a year ago. I know that there are security updates since then, but where are they for non-subscribers? Where is the source for the updates for non-subscribers? I'd love to find it so I could add another supportable OS for my SGI Altix IA64 boxen). This is not a new issue. See Dag's take on it from 2007 at http://dag.wiee.rs/blog/why-is-there-no-open-source-sles
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 23:00, Lamar Owen wrote: On 06/27/2014 05:07 PM, Mark Rousell wrote: Clearly, however, Red Hat's lawyers (and the FSF it seems) think such a limitation is not a violation of GPL. For what it's worth, such limiting contractual terms (even if freely entered into) do seem on the face of it to be a violation of clause 6 of GPL2 and possibly clause 12 of GPL3 (amongst others possibly). Anyway, as above, it seems that FSF disagrees with me so I need to read GPL2 and 3 much more thoroughly! For what it's worth, Bradley Kuhn has spent a great deal of time and effort in dealing with GPL violations. The fact that even he concedes it is likely not a GPL violation speaks volumes As I observed in another message (posted at 22:26:52 +0100), I am not aware of any comment by Bradley Kuhn (or anyone similarly knowledgeable) about the specific issue at hand here and now. As I said in that message, all of the comments by Bradley Kuhn and others date from 2011 and relate to RH's kernel distribution changes at that time; they do *not* relate directly to the new issue about limitations surrounding SRPMs in general which limit things significantly further as far as I can see. Whilst there are certainly significant similarities between the kernel issue from 2011 and this new issue, they are not the same. the fact that he, the FSF, etc, have not initiated a lawsuit against Red Hat for a GPL violation speaks even louder. As above, this seems to be a substantively new issue. If it wasn't a substantive new issue then these threads on the subject would not exist at all and SL7 would be based on RHEL7 SRPMs. I can fully understand why the changes in 2011 did not breach GPL: Everything that was required was still available. However, limiting all SRPM source code usability, the issue at hand now, is a different kettle of fish. It is no longer an issue about preferred form or prominent notice of changes or support for potentially arbitrary code changes that so concerned people in 2011. This is different and substantively extended although, as I mentioned above, it does share some similarities to the 2011 issue. I also expect to be shown at some stage how RH's new, extended, behaviour on this matter still complies with GPL but I can nevertheless say that my own reading of GPL2 (as in my other message I referred to) indicates to me that limiting what a customer can do with source code (regardless of the fact that they freely entered into a contract with RH) puts RH and/or the customer in breach of GPL2. Of course, I should note that I can only infer what RH's new, extended, behaviour is because I haven't seen a contract that really describes any limitation/restrictions/limits on what a RH customer can do in this context. I was taught as a child that actions speak louder than words; and inaction speaks louder yet, especially as he finds Red Hat's practice to be distasteful. I agree but bear in mind that a) The practice about which he commented in 2011 has been significantly extended in such a way that it seems to me to bring new licence clauses into play, and b) lack of action does not in and of itself necessarily imply lack of intent or lack of breach (as things stand now). As I mentioned above and despite all my comment, I still won't be surprised if nothing happens even now. If there were a case to be made I would think Mr. Kuhn or another similarly-opinioned individual would have made it by now; this issue has been around for a decade, it's not a new thing. And yet it most certainly *has* taken on a new form. That changes things. The threads about it on this mail list would not exist if there had not been such a substantive, real world, change. I do find myself wishing that the people debating whether the exact right number of angels are dancing on the head of this particular GPL pin would instead spend some time helping to end the flagrant, constant, and obvious GPL violations with which I spent much time dealing time each week. Aren't discussion of relevant issues such as this pretty much what he seeks? :-) Contractually limiting what a customer does with SRPMs (note, an extended issue compared to kernel source code limitations and incomplete documentation back in 2011) seems like an obvious breach of clause 6 of GPL2 to me.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 06:16 PM, Lamar Owen wrote: ... I'd love to find it so I could add another supportable OS for my SGI Altix IA64 boxen. After writing that, I thought that perhaps someone has missed the note of sarcasm there. I know full well where the sources are, and I also know that you seem to have to have a login to get the update packages source (and that the source for the particuler SP level is available under the same conditions as the year-old installer ISO is available). But in this case I would really love to be proven wrong.
Re: Clarity on current status of Scientific Linux build
On 06/27/2014 06:29 PM, Mark Rousell wrote: And yet it most certainly *has* taken on a new form. That changes things. The threads about it on this mail list would not exist if there had not been such a substantive, real world, change. On February 29, 2012, CentOS and SL both stopped support for version 4 of their respective distributions. However, Red Hat still has Extended Lifecycle Support for RHEL4 until February 28, 2015. Where are those SRPMS? Subscribers to the Extended Support can get them, but they're not publicly available, and never have been to the best of my knowledge. RHEL3 was supported by the EUS mechanism until January of 2014, yet CentOS 3 went out of support October 31, 2010 (can't rebuild if there's no public source from which to rebuild). That's a period of over three years where subscribers could get packages and SRPMS that were not available to the public. Again, this is not a new issue in general; it's just now impacting more people than before who are surprised by something that's been around for a long time. From the CentOS mailing list, back in May of 2012: On 05/18/2012 04:32 PM, Dennis Jacobfeuerborn wrote: Hi, I just learned that there exists a z-stream channel upstream that apparently carries some important bugfixes. Does anyone know what the policies are for this channel and how this relates to centos releases? Regards, Dennis The Z-Stream channels contain nothing important ... in fact they are not even released publicly. Z-Stream is security updates that you can apply to that stream and stay on an older point release. So, they would be the samba updates for the 5.6.z channel and be able to stay on 5.6 instead of moving to 5.7/5.8. However, like I said before, it is moot point because Red hat does not release the Z-Stream Source code publicly ... just like they do not release the EUS code publicly. If you want those kinds of services, you will need to get them from Red Hat on as a paid service. BUT, and I want to make sure everyone understands this, the Z-Stream items are not things that you do not get in the main (regular) tree ... they are just some security updates that are already rolled into the main tree that are also back ported an older, paid for, stabilized tree. Here is a link to read about the Z-Stream offerings: https://access.redhat.com/support/policy/updates/errata/#vii Again, these z-streams are not allowed to be rebuilt and not offered to the public, but they are also not anything that is required to be up to date security wise. They are just a slower moving subscription service offered as an add on service with additional cost to RHEL customers by Red Hat. If you need what this service offers (a slower update cycle for a specific point release version) that still has updates backported, then it might be worth the RHEL subscription and the added zstream subscription ... but since it is not released publicly, it is not a service CentOS can offer.
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 23:45, Lamar Owen wrote: On 06/27/2014 06:29 PM, Mark Rousell wrote: And yet it most certainly *has* taken on a new form. That changes things. The threads about it on this mail list would not exist if there had not been such a substantive, real world, change. On February 29, 2012, CentOS and SL both stopped support for version 4 of their respective distributions. However, Red Hat still has Extended Lifecycle Support for RHEL4 until February 28, 2015. Where are those SRPMS? Subscribers to the Extended Support can get them, but they're not publicly available, and never have been to the best of my knowledge. RHEL3 was supported by the EUS mechanism until January of 2014, yet CentOS 3 went out of support October 31, 2010 (can't rebuild if there's no public source from which to rebuild). That's a period of over three years where subscribers could get packages and SRPMS that were not available to the public. Again, this is not a new issue in general; it's just now impacting more people than before who are surprised by something that's been around for a long time. Yup, I do take your point. Nevertheless, I still cannot help but observe that: a) It's a new issue in the specific context in which it matters here (as I said, if it wasn't a new issue in this context then there would not be the problem that is at hand), b) the comments by Bradley Kuhn and others back in 2011 do not fully apply to the situation at hand now (even though it is a longstanding issue in general), and c) as I said in my message posted at 23:41:46 +0100, just because it is a longstanding issue that is increasingly common practice does not mean that it is acceptable or that it will necessarily stand if well challenged. It is all too easy for people to become inured to issues like these and think that they are an inevitability or fully legal just because there has been no real challenge to them, just because they are there. Historical lack of action does not necessarily legitimise, justify or explain current or future lack of action. Opinions can and do change.
Re: Clarity on current status of Scientific Linux build
On 27/06/2014 23:41, Mark Rousell wrote: And then, finally, the banking industry lost a court case and the government regular got round to doing something about it. What had been totally accepted, barely questioned, common practice was outlawed and improperly taken fees had to be paid back. s/government regular/government regulator/
