Code Sprints, Contractors, and Commits: PyPy in 2016

by Molly deBlanc on December 1, 2016

This series covers new developments and exciting projects taken on by Conservancy member projects. To learn more about Conservancy member projects, or the non-profit infrastructure support and services offered by the Conservancy, check out Conservancy’s Projects page!

Thanks to the generous support of donors and contributors, PyPy contracted Ronan Lamy at the beginning of June to help move forward work on Py3k. Lamy has been a Pypy core developer since 2012, and his work in refactoring old code has been invaluable to the project.

PyPy is an implementation of Python, one of the most popular programming languages in the world. It’s fast and light without sacrificing features available in CPython and other systems used to execute programs written in Python.

The Py3k project is important for the future of PyPy. Since the publication of Python 3, coders, developers, and organizations have been tackling the technical and social challenges of updating from Python 2. For PyPy, supporting Python 3 means supporting the Python community—those wanting to use PyPy will be able to work with projects using Python 2 and Python 3. In addition to donations received through the Conservancy’s fiscal sponsorship, a $200,000 award from the Mozilla Foundation to Baroque Software is helping to make a Python 3.5 PyPy a reality.

Over June, Lamy made hundreds of commits to PyPy—creating clean code, fixing translations, increasing testing capabilities, and expanding Windows functionality. Rather relentless, he combed through commits and contributions, chasing down everything from unnecessarily hacky code to serious problems. Without the financial support of donors, this work would likely remain unfinished. Lamy spoke at PyCon UK this September, where he talked about the current state of PyPy.

Currently, PyPy is a “good and… usable drop-in replacement for CPython” for 2.7, and during 2017 that usability should extend to Python 3.3 and 3.5. In order to achieve this goal, Python 3.5 will continue to be a major priority for PyPy in the months ahead, as well as JIT code generation. Additionally, there are a number of “side projects,” like RevDB.

Interested in getting involved with PyPy? There are lots of ways to contribute to the project—check out the documentation for details! You can also help them along by donating to the project.

[permalink]

Tags: pypy, Year In Review 2016, Member Projects

ContractPatch, Step 3: It's never too late

by Tony Sebro on November 30, 2016

We understand that we may lose a little credibility with the other side when we look backwards. We're reluctant to break the psychological bond we formed when we reached agreement — even if that agreement was communicated by little more than silent assent. We worry that we look sloppy and unprepared, since we had a chance to bring up whatever concerns we had the first time we discussed that point, and we didn't.

Employees in particular can feel that way about the agreements they signed with their employer.

As Karen stated in our last entry, people likely will never have as much power over their employer as they do the moment just before they sign their employment agreement. I certainly agree, and we would all be wise to use that leverage as best we can while we have it. But what about the rest of us, who have already signed that agreement? All is not lost. Despite what our psychology tells us, it's never too late to go back to the negotiation table with your employer.

The stakes and the power dynamic are different, to be sure. From the employer's perspective, a recruit with a job offer in hand is potential personified; whereas an employee has an actual performance record and history of relationships — and, of course, a demonstrated willingness to work for the employer at the terms they already agreed to.

So, perhaps you're in a situation where you have some regrets about the employment agreement you signed. Or, perhaps you're up for a promotion, or a transfer, or some other change in job duties. Or, perhaps your priorities have changed, and you'd like to adjust where you're willing to give and to get accordingly. You should consider at least two factors when deciding how best to proceed.

Factor #1: is the juice worth the squeeze?

While it's certainly possible to renegotiate an employment agreement, every employee should recognize that the subtle cost of doing so is real. Your employer is presumably fine with the status quo, and you'll be asking them to spend time and/or resources considering your requests. As a threshold matter, you should be candid with yourself about the stability of that status quo: the cost of attempting to renegotiate might be much higher if your position with your employer is shaky than if you're a rising star. In addition, changes in responsibilities and/or title may afford you a unique opportunity to reconsider the terms of your employment.

You should also do your best to determine what others in comparable positions receive from their respective employers. Market data will give you a better sense of what your employer might be willing to concede in a renegotiation. Obtaining this data isn't always an easy task: salary benchmarking for various industries is generally available on the web, but information about industry practices regarding other terms of employment is harder to come by. One of our long-term goals with ContractPatch is to gather and present information that enables both employees and employers in the tech sector to efficiently negotiate better employment agreements.

Lastly, you should compare the value you place on each of your requests to their cost to your employer. Employers usually manage their employees' salaries closely, so a straight-forward request for a raise is usually a zero-sum game: more money for you, less remaining in the employer's budget for something else. But it might be harder to quantify the employer's cost for other requests — particularly if they relate to more non-monetary requests like ownership of copyrights in your work, flexibility to pursue and contribute to extra-curricular activities, etc. You'll likely need to rely on your understanding of your employer's culture and business model to estimate the cost (if any) your employer would incur to grant those non-monetary requests.

Obviously, the easiest renegotiations are the ones where you're confident in your standing with your employer, you value your requests a great deal, your requests are in-line with industry practices, and you think your employer will incur minimal costs in granting them. And, of course, context matters: an employer who has given you a promotion but who doesn't have the budget to give you a commensurate salary bump is likely to treat non-monetary requests differently than an employer who has just backed up the Brinks truck for you. Your risk/reward calculus will depend on your assessment — and will go a long way in determining when and how to reopen discussions with your employer.

Factor #2: what does your existing employment agreement say about it?

I know this should go without saying. But many an employee has signed their employment agreement without fully understanding all of the terms they've agreed to. So, as you consider whether to renegotiate your agreement, make sure you're familiar with the existing agreement. If you don't have a copy handy, you should request a copy from your employer to have on file.

Once you've reviewed your existing agreement, compare the current language with your wish list of requests. In particular, you should know whether your requests would require actual amendments, or if you're merely looking to clarify vague or even seemingly contradictory language.

So, if you have a firm grasp on your current employment agreement and how you'd like to see it changed — and if you're comfortable that obtaining some or all of those changes is worth the risk — you're ready to start renegotiating. If your assessments are accurate, you might be surprised as to what your employer is willing to concede the second time around.

Over the course of this series, we'll start to drill down into specific subject areas commonly covered (sometimes expertly, other times poorly) in employment agreements for employees in the tech sector. If there are particular topics you'd like us to cover, you can sign up for our mailing list and offer suggestions. We look forward to continuing the conversation.

[permalink]

Tags: conservancy, ContractPatch

Recap: GPL Compliance BoF at Linux Plumbers’ Conference

by Brett Smith on November 16, 2016

At the Linux Plumbers Conference a couple of weeks ago, Karen and I ran a Birds of a Feather session about our GPL Compliance Project for Linux Developers. It was a success by every measure. Approximately seventy people attended, and about twenty of them participated in the discussion, covering a wide variety of issues around compliance. The interactive and inclusive format was ideal for us to provide additional information and get feedback from a lot of interested people. Many thanks to the Linux Plumbers Organizing Committee for scheduling a slot for us to run this session.

We opened the discussion with a basic overview of the program: its history and mission, the structure of how we coordinate with Linux developers on our coalition, the typical flow of how we respond to a violation and work to help the distributor comply. We published the project agreement templates beforehand to facilitate the discussion. In the past, we heard people express concern that these agreements were private. We were happy to tackle that issue head-on, and I was glad to see several attendees download the template and review it during the session.

We also talked about how our work differs from some inappropriately aggressive enforcement efforts going on today—including Patrick McHardy's unfortunate enforcement lawsuits. One person rightly pointed out that less savvy distributors will often assume all GPL compliance is handled the same way. We discussed how Conservancy could emphasize the distinctions up front. We agree that's important; it's why we published our Principles of Community-Oriented GPL Enforcement, and why we were the first organization to publicly criticize McHardy's actions. Still, a new Linux distributor might not know about our principles, or understand that they specifically call on lawsuits only as a last resort. Based on this feedback, we plan to mention the Principles in our first correspondence about GPL compliance problems.

Our transparency in our methods and goals distinguishes Conservancy's compliance work from others'. There were several suggestions that we could take this further by publishing different numbers about how many cases we're handling, and different ways they've been resolved. To this end, Karen echoed the same point Bradley made at ELC EU that we only have the resources to pursue a relatively small percentage of the violation reports we receive. Because of this, publishing these numbers could de-anonymize active cases, which would contravene our compliance principles. Nonetheless, we will reexamine this issue to see if we could publish some numbers safely.

That discussion led to suggestions that volunteers could help us with technical compliance work, confirming violations and the completeness of source code. We've discussed that idea internally for many years. Even more than publishing numbers, engaging volunteers risks leaking information about violators to the public. Furthermore, we would need to vet and train volunteers, which we lack the resources to do now. If we received funding for this work, we could use that to plan and provide volunteer training, but there has been limited interest in funding community-oriented compliance initiatives.

Finally, we discussed different ways to make compliance work less necessary. We'd love to see more of this: as more distributors proactively come into compliance, we have more time to spend supporting our member projects and other initiatives. That's a big reason we helped write the Copyleft Guide, which helps distributors better understand the conditions and requirements of the GPL. The pristine source example, in particular, is designed to show step-by-step the process of verifying a complete, corresponding source release. There's certainly lots of great ideas for more work like this, and I think naming them in the BoF helped make some good connections between them.

Our thanks to everyone who attended and provided feedback. If you couldn't attend this BoF, don't worry. We'll be running similar sessions at other conferences over the next few months, and you can also provide feedback on our principles-discuss mailing list. We want to hear from as much of the community as possible, so if you have questions or comments about our Linux compliance work, we hope we'll hear from you soon.

[permalink]

Tags: conservancy, GPL

Conservancy's First GPL Enforcement Feedback Session

by Bradley M. Kuhn on October 27, 2016

As I mentioned in an earlier blog post, I had the privilege of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit in Berlin, Germany earlier this month. I gave a talk (for which the video is available below) at the OpenWrt Summit. I also had the opportunity to host the first of many conference sessions seeking feedback and input from the Linux developer community about Conservancy's GPL Compliance Project for Linux Developers.

ELC EU has no “BoF Board” where you can post informal sessions. So, we scheduled the session by word of mouth over a lunch hour. We nevertheless got an good turnout (given that our session's main competition was eating food :) of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer and leader of gpl-violations.org, was able to attend. Harald talked about his work with gpl-violations.org enforcing his own copyrights in Linux, and explained why this was important work for users of the violating devices. He also pointed out that some of the companies that were sued during his most active period of gpl-violations.org are now regular upstream contributors.

Two people who work in the for-profit license compliance industry attended as well. Some of the discussion focused on usual debates that charities involved in compliance commonly have with the for-profit compliance industry. Specifically, one of them asked how much compliance is enough, by percentage? I responded to his question on two axes. First, I addressed the axis of how many enforcement matters does the GPL Compliance Program for Linux Developers do, by percentage of products violating the GPL? There are, at any given time, hundreds of documented GPL violating products, and our coalition works on only a tiny percentage of those per year. It's a sad fact that only that tiny percentage of the products that violate Linux are actually pursued to compliance.

On the other axis, I discussed the percentage on a per-product basis. From that point of view, the question is really: Is there a ‘close enough to compliance’ that we can as a community accept and forget about the remainder? From my point of view, we frequently compromise anyway, since the GPL doesn't require someone to prepare code properly for upstream contribution. Thus, we all often accept compliance once someone completes the bare minimum of obligations literally written in the GPL, but give us a source release that cannot easily be converted to an upstream contribution. So, from that point of view, we're often accepting a less-than-optimal outcome. The GPL by itself does not inspire upstreaming; the other collaboration techniques that are enabled in our community because of the GPL work to finish that job, and adherence to the Principles assures that process can work. Having many people who work with companies in different ways assures that as a larger community, we try all the different strategies to encourage participation, and inspire today's violators to become tomorrow upstream contributors — as Harald mention has already often happened.

That same axis does include on rare but important compliance problem: when a violator is particularly savvy, and refuses to release very specific parts of their Linux code (as VMware did), even though the license requires it. In those cases, we certainly cannot and should not accept anything less than required compliance — lest companies begin holding back all the most interesting parts of the code that GPL requires them to produce. If that happened, the GPL would cease to function correctly for Linux.

After that part of the discussion, we turned to considerations of corporate contributors, and how they responded to enforcement. Wolfram Sang, one of the developers in Conservancy's coalition, spoke up on this point. He expressed that the focus on for-profit company contributions, and the achievements of those companies, seemed unduly prioritized by some in the community. As an independent contractor and individual developer, Wolfram believes that contributions from people like him are essential to a diverse developer base, that their opinions should be taken into account, and their achievements respected.

I found Wolfram's points particularly salient. My view is that Free Software development, including for Linux, succeeds because both powerful and wealthy entities and individuals contribute and collaborate together on equal footing. While companies have typically only enforce the GPL on their own copyrights for business reasons (e.g., there is at least one example of a major Linux-contributing company using GPL enforcement merely as a counter-punch in a patent lawsuit), individual developers who join Conservancy's coalition follow community principles and enforce to defend the rights of their users.

At the end of the session, I asked two developers who hadn't spoken during the session, and who aren't members of Conservancy's coalition, their opinion on how enforcement was historically carried out by gpl-violations.org, and how it is currently carried out by Conservancy's GPL Compliance Program for Linux Developers. Both responded with a simple response (paraphrased): it seems like a good thing to do; keep doing it!

I finished up the session by inviting everyone to the join the principles-discuss list, where public discussion about GPL enforcement under the Principles has already begun. (Note: discussion about this specific feedback session can be found on the thread on the list that starts hereI also invited everyone to attend my talk, that took place an hour later at the OpenWrt Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL enforcement. As explained on the OpenWrt history page, OpenWrt was initially made possible thanks to GPL enforcement done by BusyBox and Linux contributors in a coalition together. (Those who want to hear more about the connection between GPL enforcement and OpenWrt can view my talk.)

Since there weren't opportunities to promote impromptu sessions on-site, this event was a low-key (but still quite nice) start to Conservancy's planned year-long effort seeking feedback about GPL compliance and enforcement. Our next session is an official BoF session at Linux Plumbers Conference, scheduled for next Thursday 3 November at 18:00. It will be led by my colleagues Karen Sandler and Brett Smith.

[permalink]

Tags: conservancy, GPL, conferences