Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Is

Making philosophy about the why behind technical things.

  • GPL Isn’t Protecting You

    GPL Isn’t Protecting You

    Some days I know my plugin reviews are going to wreck me. January has had a lot of complaints from people about aspects of the GPL. Specifically they wanted to know how to protect themselves with the GPL.

    The truth is the GPL is not protecting anything except the right of the next guy to take your code and do stuff with it. And that terrifies people.

    I’m not entertaining a discourse on the merits or legality of the GPL here. Those comments will be deleted. Simply put, a requirement of the WordPress.org repositories is that to be hosted there you must be GPLv2 (or later). At that point, every other argument is moot. Your code has to be GPLv2 to be in the repositories. End of story.

    Okay. So what’s there left to discuss about protecting yourself and your code? Three things: Trademarks, copyright, and theft. Here we go.

    Trademarks

    GPLv2 doesn’t protect your trademark, but that doesn’t mean your trademark isn’t protected. While any image you put in your WordPress theme or plugin has to be given as GPLv2 compatible, that doesn’t void your trademark. A freely offered image that is trademarked (say, the WordPress logo) can be used in your plugin, but it comes with restrictions after all. The inclusion of the SVG of the logo in GPL code doesn’t change that.

    One of the things that changed in GPLv2 and GPLv3 was related to this. Remember, GPLv2 allows all code that does not include any restrictions that were not already in GPLv2. As long as license was as free (or freer) than GPLv2, it was deemed to be GPL-compatible (see the WTFPL). The issue with that is some licenses were very easy to comply with but had clauses like you couldn’t use certain trademarks. This caused confusion, as it was read as a restriction. The thing was that it wasn’t! Regardless of what the license said, you never had permission to use the trademark.

    This is good for companies. You can trademark your logo and, if someone takes it redistributes a fork with the logos still in it, they’ve violated trademark law. And you can protect yourself there. I suggest you read Joomla’s post on the matter of Trademark protection to get a better idea of how it all works.

    Copyright

    Copyrights are another thing that the GPL doesn’t protect. Except it does.

    GPLv2 and GPLv3 are both copyleft:

    To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program’s code or any program derived from it but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.

    What does that mean? Your copyright is yours. By the act of writing code, you own the copyright (with some exceptions, like if you’re hired to write the code). When you contribute code to an open source project like WordPress, you STILL retain the copyright unless you give it away, but the license is whatever the project’s license is. Most of the time this is fine, but as I recently saw with Hugo, this can be problematic when a project wants to change their license. Hugo had to get permission from every single person who had contributed.

    This is, by the way, why WordPress will probably always be GPLv2.

    One way around this is to require everyone to waive their copyrights in order to contribute. I believe DotNuke did this. Whomever owns the copyright, if the code is still licensed in a way that allows for free distribution then nothing’s really changed. The code is still open.

    Of course, then there’s the jQuery Foundation does with their Individual Contributor License Agreement – In order to contribute to jQuery’s code or website, you have to sign that and provide a valid email. This gives them a way to contact everyone and also makes sure you understand what you signed up for. WordPress just has a checkbox when you submit your code to remind you that you’ve given it up.

    If you’ve ever looked at the jQuery Foundation License, you may have noticed this line:

    You are free to use any jQuery Foundation project in any other project (even commercial projects) as long as the copyright header is left intact.

    This is not imposing a restriction more than GPLv2. See the bit in trademarks. Legally you had to do that anyway, they’re just reminding you not to be a tool and leave this simple line in:

    • Copyright jQuery Foundation and other contributors

    I bark at developers a lot for removing the license headers from javascript files. Don’t do it. You’re violating copyright and, if the original devs complain, you’ll lose your code until you fix it. Which is the point here. Copyright exists beyond GPL, so the fact that it doesn’t actively protect it doesn’t make it not enforceable.

    Theft

    I don’t mean legal here.

    A lot (a lot) of people argue that their plugin should be able to be encrypted or obfuscated to make it ‘harder to steal.’ I hear that about once a week, if not more. And my answer to all of them is “Not if you want to be hosted on WordPress.org.” WordPress.org has an ‘above and beyond’ understanding of the idea of distribution and allowing people to edit. It’s felt that the spirit of GPL means your code should be easy for someone to read and fork.

    I said a dirty thing there, I know. The ‘spirit’ of the GPL is probably causing some of my friends to roll their eyes so hard they’ve got migraines. Sorry about that. But it really is the one time I use it. When I say the ‘spirit’ I mean the intention of the license and it’s application to WordPress.org’s repositories only. Right or wrong, agree or disagree, it’s straightforward. If you want to have your code in the .org repos, it’s gotta be human readable.

    There’s a simple reason for this. The GPL Copyleft is all about freedom and keeping that freedom alive. The Copyleft says that anyone who redistributes the software, with or without changes, must pass along the same freedom to further copy and change it. In order to allow people to change the code, we want it to be human-readable. We want people to be able to look at your code and say “Oh I understand how this works. I will improve it!” When you take away, or overly complicate their ability to do that, we feel you’re intentionally impinging on that freedom. You’re trying to find a way around it, basically.

    About the only time I’ve heard someone not claim they were smushing the code up to protect it from being stolen is when someone has smashed their javascript into a p,a,c,k,e,d() type compression file. I actually hate those files. Javascript is hard enough as is! Stop making it harder. Plus I need to tell you something really important.

    While minifying your javascript will improve a website’s performing by decreasing the load time, it doesn’t make it run any faster for the majority of code out there. Of course there are situations (large libraries or limited devices) where this is not the case, but trust me here. Your 7 line javascript is not going to be significantly faster just because you compressed it. I advocate using the .min version of common libraries, but unless your code is huge, leave it alone and let other people see how to edit it.

    Bonus: Distribution

    GPL comes into play when your code is distributed. If I put my code on my server and never give it to anyone, it’s not been distributed so licenses don’t really matter. As the GPL FAQ explains:

    But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.

    It’s the big if there. What constitutes distribution? Is your browser downloading a javascript file in order to run my site distribution? Is handing you a zip file distribution?

    I always recommend people play it safe.

  • Circular Arguments Need Research

    Circular Arguments Need Research

    There’s something I hate about the fact that they charge for tampons and pads in bathrooms. I understand the financial outlay of providing a ‘service’ but at the same time, the collection method means that most of us never use them. After all, on those occasions when a woman needs a tampon or pad from those machines right bloody now, we probably don’t have our purses with us. Most women I know keep at least one in there for just such a moment, after all. If we don’t have our purses, guess what else we don’t have? A dime! In my experience, any time any woman has stared at that machine with a look of hopelessness and despair over their lack of a dime, another woman has brandished her personal emergency tampon and handed it over without a second thought.

    So why do they charge? Well if they didn’t charge, then people would just take them and that would be a financial loss. I get that. Except, as my friend Mark Jaquith put it:

    Financial outlay is an imprecise way of validating the intensity of a need.

    The day I had my great-tampon-rant was the same day I’d argued with some folks about marketing. Someone who is a ‘known’ person in the WordPress community got a bog standard email from a hosting company. It was one of those emails that looked like it was meant to feel personal, but was really just a sales pitch about what the company was and how they worked.

    The thing about that is I’m pretty damn sure the person who got the email knew all of that already. He may have known it better than the ‘person’ who sent the email. I say ‘person’ in quotes because I’m sure it was an automated campaign set to hit up people who’d emailed or used a contact form and asked a question.

    And this bothered me.

    If the email hadn’t made an attempt to be personal, and instead just said “Hey, you used our form/emailed our service address recently. Did you get all the help you needed? Do you need to talk?” I would have been just fine with it. And if he’d checked a box to say “Please contact me about stuff!” I’d similarly say “Well you deserved that one, B.”

    The reality is that he filled in a form to get a ‘report’ that he wanted to read and got that personalized email within an hour. The company offered something for ‘free’ but the cost really was data collection. Furthermore, the penalization was immediate solicitation.

    It doesn’t matter who the company is. This could be mine (it’s not) or yours (it might be). Pretty much every company known to humanity has done this at least once. And every company uses the justifications that the marketing strategy converts people into sales, and thus it’s fine. We all accept that marketing automation is hard, that identifying people we should be reaching out to and separating them from the ones who will just be annoyed by our hard sells is extremely difficult.

    Remember what Mark said?

    Financial outlay is an imprecise way of validating the intensity of a need.

    Not enough women using the pay-for tampons and pads is (part of) why they’re never going to be free. Women don’t use them because they’re pay-for (and we rarely have the damned dime).

    The ‘need’ of tampons is not being correctly measured.

    With those marketing emails, I would say this:

    Financial boons are an imprecise way of validating the effects of a campaign.

    Yes, I’m aware I just said that “Making money doesn’t mean your campaign was successful.”

    Except that’s not what I’m saying. What I’m saying is that the effects of your marketing are more than just financial. If you send out 1000 emails and get 1 sale, that sounds like ‘free money.’ Very little output and work nets you money. Everyone wants this. The problem is how many people did you chase away? What net negative are you creating? We’re not tracking the information in a way that lets us know this. We’re just thinking that any news, any discussion, and any income means it was good and effective.

    Let me ask this differently. How many auto-play ads have you seen on a website that made you like a product less? How many websites have you quit visiting because you can’t stand their ad practices?

    Not all press is good press. Forbes recently had a snafu where they asked you to turn off adblocking only to serve up ads with malware. They had a rather immediate and vocal negative impact. I doubt that level of embarrassment and pain will hit this company, but at the same time, we should be looking towards other, better ways of attracting new customers.

    This Can Be Fixed

    Looking at the situation that led to this in the first place, requiring an email to download a report is an obvious ploy to gain a list of people to contact. There was no attempt to opt in and no information that the email would be used for marketing. Step one is to disclose that. Step two is to actually make that opt-in. Step three is to provide some additional reward. “Do you like reports? Click here and we’ll send you our next one right away!” Then when you send those next reports, you can put a little footer for sales. “Interested in our stuff?”

    Step four is the hardest. Curate the damned list. Remove all your customers. You already have their emails, you don’t need to email them about your services. Put them to the side. Next you want to remove people with emails like support or webmaster. In addition, you’ll want to check your list for people who already know about your product. WordPress is an incredibly small community. There are some people who just are not ever going to be your target audience, who aren’t going to need that sale, and you don’t need to bother them. They’re also the ones who will uncheck the marketing email, of course, but just in case…

    Step five is handling your existing customers (the ones you removed in step four). Put them on separate list to target with different emails. “Hey, you’re already our customer and we noticed you liked X. Would you be interested in Y and Z?” Of course if your customers have checked that box to say “Don’t email me with marketing stuff” then you damn well better respect it.

    For step six I want everyone to stop pretending these are personal emails. Shut up. Give up. We know, okay? We absolutely, 100%, without a doubt know that you automated this stuff. And that’s totally okay. But you cannot claim personal emails, from real people, while not vetting the people to whom you’re sending email in the first place. Okay? Good. Now go be quirky! “Hi Mika! I set up our robots to email people who downloaded X because I wanted to make sure they knew about Z and Y! Hate these emails? Click here and we’ll delete you from the database.”

    But Can It Be Automated?

    Not entirely. No. The real question is ‘Should it be automated?’

    This goes back to Forbes. They automated their ads. They set it and let it run without review. Obviously the answer there is ‘No, that should not have been automated.’ It’s easier to ignore them and trust the ad company. That said, regularly I go through the ads on my site and delete them when I find them annoying or offensive. Yes, I curate my ads. And if someone tells me “Hey there was an ad for porn” I go look for it!

    As much as we’d love to automate these things, we can’t. We just need a human taking a look now and then to go “Hang on…” Marketing cannot be set it and forget it. We have to look at the return on investment. We have to understand what impact, true impact, our campaigns have. We can’t just look at the net income, we have to be aware of the seemingly invisible loss.

    And as for those tampons? We need a better metric than just “Well some people pay for them, but not enough to make us think a lot of women will use them if we give them away for free….” Maybe they could just have a nice box of tampons and pads in every stall, where you can press a lever and one item falls out every X minutes. Or maybe that idea of a drop of menstrual blood works in place of a dime… At any rate. The point is assuming things as successful because of a lack of response does not actually mean they are.

    The circular arguments, that silence proves success, or at least an acceptable status quo, need to be thrown out on their ears.

  • Mailbag: Access and Security

    Mailbag: Access and Security

    In the midst of a longer set of forum posts about how to not have a plugin updated because you’ve made edits to the plugin, someone said that their issue was that the people on the site updated.

    Now please don’t say that we should give them minimum privileges …

    Actually. That’s precisely what I’m going to say.

    1) Do not make anyone an admin whom you do not explicitly trust.

    2) As the admin, test all plugins before updating.

    3) If a plugin is constantly releasing unstable updates, stop using the plugin and look for alternatives.

    3a) But make sure it’s not your theme or a conflict with another plugin first. It may be something else’s fault.

    4) Stop editing plugins directly.

    5) Treat every upgrade as a serious thing.

    Now. I know why the guy doesn’t want to hear “You’re doing it wrong.” But the truth is this. If you give people who are irresponsible enough to update things the ability to update things, they’re gonna update things!

    True story? On one of our company sites, one of the guys has access to update all the things. He did and broke the site. I jumped in, told him “Don’t do that, please, ask me next time.” and I fixed it. And then I went through everyone who had admin access and locked their accounts down to Editors. The exceptions were the people who legitimently needed that access.

    And yes, WordPress needs more granular user roles/controls. I want that user to have access to administer all posts and add new users. I don’t want him anywhere near the plugins and themes. But I evaluated the risk vs reward of his access, and since he’s educatable, I felt it was safe to leave him there. Plus he knows right away to call me if he breaks things.

    That goes back to the trust aspect, though. I trust him.

    Trusting people to have access to aspects of your site reflect your understanding of what that access means. Making everyone and their brother an admin is reckless, not to sugar coat the situation. Only people who must be admins should have admin access. It’s really that simple. And if you insist there’s no other way around it, then you’re not paying attention closely enough.

    Make a list of what your users need to do. Not what they want, what they need. And be serious here. Do they need to update plugins or do you do it for them in a reasonable timeframe? Do they really need to be able to add users? Remember though, we’re asking what they need, not you. Go to WordPress’ list of Roles and Capabilities and take note of what they actually can do.

    Now I said before, the roles and controls and capabilities of WordPress leave a lot to be desired. But thankfully WordPress has add_cap and you can adjust roles.

    Here’s how Isabel Castillo did it:

    function isa_editor_manage_users() {
     
        if ( get_option( 'isa_add_cap_editor_once' ) != 'done' ) {
         
            // let editor manage users
     
            $edit_editor = get_role('editor'); // Get the user role
            $edit_editor->add_cap('edit_users');
            $edit_editor->add_cap('list_users');
            $edit_editor->add_cap('promote_users');
            $edit_editor->add_cap('create_users');
            $edit_editor->add_cap('add_users');
            $edit_editor->add_cap('delete_users');
     
            update_option( 'isa_add_cap_editor_once', 'done' );
        }
     
    }
    add_action( 'init', 'isa_editor_manage_users' );
    

    You only need to do that once since the roles and caps are locked into the database (see above, the controls need to be better). Still. Now your editors can edit users. Brilliant.

    So yes. I will tell you you’re doing it wrong, especially when you’re doing it in a way that is dangerous and risky in the long run.

    Don’t let the toddlers try to drive the car.

  • The Fiscal Responsibility of 25%

    The Fiscal Responsibility of 25%

    “We’re going to deploy on December 20th.”

    I winced.

    I’m not Christian and December 25th is just another day when I binge watch Netflix. The 24th? Movie night! But I picked up a habit at the Bank and that was not deploying code for the last two weeks and first two weeks of the year unless the company was going to be fined if we didn’t.

    I was brutal about that to people. I was harsh and mean and demanded lengthy justifications. I made them speak to senior management, who were hard to find around that time of year because every one was on vacation.

    The reason for this was that the bank had a clear cut fiscal responsibility not to go down between Thanksgiving and a bit after New Years. That was when year end processing happened, and that was when many companies who used us were processing the most orders. For a lot of people, business booms right when everyone wants to take a break to be with their family.

    WordPress runs 25% of the Internet.

    We use it for blogging, for building Facebook-eqsue sites, for running ecommerce stores.

    That means and we the developers of WordPress now have a responsibility not to break when we upgrade people. A huge responsibility. And it’s one we can never give with 100% assurance because of one simple fact.

    We made WordPress open.

    Anyone can make a theme or plugin. And while we do our best to test with core WordPress, we cannot test all of the 45k plugins in the repository yet. The best is maybe we could write a script to check for fatal errors on activation. But even then, can we test all 45,000 against all possible permutations of combinations?

    That’s an incredibly massive number. All my factorial calculators, even Google, just said ‘Infinity.’ And we add about 9000 plugins a year. This is staggeringly huge and it gets bigger every year

    But with this increase in share and use comes an incredible responsibility to 25% of the web. We cannot break their sites.

    Of course I know that’s impossible. There will always be outliers. And even with the large user base that companies like Yoast have, the dearth of willing and capable Beta Testers for a free product is going to bite us. It’s part of what I asked what I did at the Town Hall at WCUS — Are we going too fast?

    Speed cannot exclude us from a responsibility to our users. And with the increasing provenance of online stories and websites for everyone, pushing a change when we know that the majority of the world is celebrating something between Nov 15th and January 15th is reckless. Look at how many people want time off in those months to be with family. Look at how many businesses are running sales. Look at the amount of data transfer that spikes.

    And then picture what happens when an update has a small bug that takes down one site in a thousand. 1/1000 of 1/4th of the entire Internet. If that didn’t make you shiver, do the math again. Imagine if Apple went down because they pushed an update right around Christmas?

    The answers change sometimes, though. What if it was a security fix? Would that change your mind? It would change mine. A major upgrade around Christmas worries me. A minor one, not so much.

    It may be time to call a year end moratorium on updates to our systems and apps. If they’re business and mission critical, test them as best you can, but consider if you have to update before that Christmas rush. Make people jump through hoops to prove they need the new shiny right now. If you know you’re understaffed or under heavy load, consider that as much as anything else.

  • Consenting to Collection

    Consenting to Collection

    Collecting information on users is something every program wants to do. Doing it is easier said than done. (more…)

  • Disclosure

    Disclosure

    One of the myriad reasons I push back on WordPress plugins is because someone didn’t disclose enough information about ‘phoning home.’ Phoning Home is simple concept that comes down to this “Don’t send data from the plugin users back to yourself (or anyone else), unless you’re a service. And if you are a service, make this clear in the readme.”

    Simple, right? It’s totally easy to understand that we want you to tell people “Hey, if you use this plugin, it will report back to my servers…” Much of the time, this is obvious. A Facebook connection plugin, logically, contacts Facebook. Embedding YouTube playlists contacts YouTube. Those sorts of things we don’t worry about, though if you have your plugin say “This will pull data from YouTube” then it’s better. Sometimes this is less obvious, like if you use geoplugin.net to determine locations. Your plugin probably has nothing to do with that domain, but you still have to tell people about it so they know.

    But why do they need to know?

    First of all, this is the basic email I’ll send you if I see you’re not explaining the phone-home in your plugin:

    Plugins that send data to other servers, call js from other servers, and/or require passwords and APIs to function are required to have a full and complete Readme so we can make sure you’re providing the users with all the information they need before they install your plugin. Our goal with this is to make sure everyone knows what they’re installing and what they need to do before they install it. No surprises.

    This is especially important if your plugin is making calls back to your own servers. For the most part, we do not permit offloading of images or code, however in the case where you are providing a service (like Disqus or Akismet or Twitter), we permit it. The catch is you have to actually explain this to the layman in your read me, so they know where data is going.

    Clearly there are some basic reasons, like we should know where our data is going for our own safety. There are also some surprising reasons to people who don’t think about these things, like legal ones. You’re calling out to other servers? What if my company legally can’t do business with them? Then we have the tin-foil hat reasons, like I don’t want to do business with Google so I don’t want to have Google JS in my plugin.

    All that sounds pretty basic. And some of it is super obvious. If you’re making an app to communicate with Facebook, then it’s logically going to send data to Facebook. None of that surprises anyone, nor should it. With a service, one simply has to be up front about what the product does, what services it connects to, and why.

    “This plugin pushes your comments from your Facebook page to your blog, matching users by email addresses with their Facebook accounts (if found).”

    I just made that up. But it’s upfront, it’s honest, it’s direct, and it’s clear what’s being sent and where and why.

    There’s another aspect to this, however, something that is far trickier and more complex. What happens when your existing tool adds a service?

    The obvious answer is that you need to disclose this change to our users. As long as the users know what they’re getting into, then you are golden. The complex answer, the one I can’t really tell you a one perfect answer for, is how you might do this.

    Why is this hard? It’s hard because there is no one right way to tell users about the change. There is no one perfect way to make sure users read the information. There is no one way to get all the data to all the people who need to know about the information.

    And there sure as hell isn’t one way to make sure no one will complain about any of that.

    When you make a change to the paradigm of what your tool does, taking a stand alone tool and adding in a service, you have to consider that a percentage of your users will rebel. This is simply because all those wonderful things you do about disclosing the service for new users have to be transitioned in a meaningful and logical way to existing users. And there is just no way to do that perfectly.

    This doesn’t mean you shouldn’t try. This means you have to be creative and innovation and a little ‘in your face’ about the change. You have to give users an option, before the service kicks in, to say if they want their data shared.