For some years now, Bradley Kuhn has been the face of GPL enforcement. At LibrePlanet 2017, he gave a talk about that enforcement and, more generally, whether copyleft is succeeding. Enforcing the GPL is somewhat fraught with perils of various sorts, and there are those who are trying to thwart that work, he said. His talk was partly to clear the air and to alert the free-software community to some backroom politics he sees happening in the enforcement realm.
Most of the work that Kuhn's employer, the Software Freedom Conservancy (SFC), does is not dealing with licensing issues. But people love hearing about copyleft, he said. In addition, free-software developers like those at LibrePlanet have a right to know what's going on politically. There is a lot of politics going on behind the scenes.
Kuhn works for a charity, not a traditional company or a trade association. That means he has the freedom and, in some sense, the obligation to give attendees the whole story from his point of view, he said. He is lucky to be able to work in that fashion. Kuhn then took a bit of a spin through his history with copyleft and why he decided to step up for it.
The Free Software Foundation's John Sullivan was one of the first to criticise the article, pointing out on Twitter, "There are many sites where I'd expect to see this article but not the Linux Foundation."
In reference to a claim in the article, he wrote, "Copyleft is not 'riskier'. Permissive licenses allow proprietary reuse, and *proprietary* licensing is far more complicated and risky."
And he added, "Copyleft is also not 'restrictive'. See above. Proprietary licensing is restrictive. Copyleft guarantees absence of restrictions."
GitHub's updated terms caused a great deal of concern, but while they are confusing, they do not appear to be incompatible with copyleft. The Free Software Foundation (FSF), though, still recommends using other code hosting sites.
GitHub recently updated their terms of service (ToS). Users of the site are raising many concerns over the new terms, fearing that the ToS could be incompatible with the copyleft licenses on works uploaded to GitHub. In particular, section D of the new terms, which handles rights granted to GitHub and GitHub users, makes many hackers very uncomfortable.
Section D.4 states, "You grant us and our legal successors the right to store and display your Content and make incidental copies as necessary to render the Website and provide the Service. " At first glance that might appear to grant permissions on your work without the concomitant protective guarantees found in copyleft licenses like the GNU General Public License (GPL). Users who care about ensuring that their software never becomes proprietary would not want to give such unconditional permission. And those uploading works that incorporate third-party copylefted code may not even be able to grant such permissions.
But licenses like the GNU GPL already give the necessary permissions to make, use, and modify local copies of a work. Are the new GitHub ToS asking for more than that? It's not fully clear. While the grant language could fit within the scope of the GPL, other words used in the section like "share" or "distribute" could be understood to mean something that wouldn't line up with the GPL's terms.
We recently took one of our test systems and tried an experiment: could we boot FreeBSD 11 from a NVMe SSD using ZFS root file system using AMD Ryzen. At STH we have many FreeBSD users and developers so when there is a new hardware class out, we tend to try it in FreeBSD and sometimes popular FreeBSD appliance OSes such as pfSense and FreeNAS. You can see an example with our Knights Landing Xeon Phi x200 system booting FreeBSD OSes. In our recent testing with AMD Ryzen we found major installers with the latest CentOS 7.3 and also had issues with Ubuntu crashing using current LTS image kernels. We wanted to see how FreeBSD would fare given it normally lags in terms of hardware support.
As we can read in recent news, VMware has become a gold member of the Linux foundation. That causes - to say the least - very mixed feelings to me.
One thing to keep in mind: The Linux Foundation is an industry association, it exists to act in the joint interest of it's paying members. It is not a charity, and it does not act for the public good. I know and respect that, while some people sometimes appear to be confused about its function.
However, allowing an entity like VMware to join, despite their many years long disrespect for the most basic principles of the FOSS Community (such as: Following the GPL and its copyleft principle), really is hard to understand and accept.
I wouldn't have any issue if VMware would (prior to joining LF) have said: Ok, we had some bad policies in the past, but now we fully comply with the license of the Linux kernel, and we release all derivative/collective works in source code. This would be a positive spin: Acknowledge past issues, resolve the issues, become clean and then publicly underlining your support of Linux by (among other things) joining the Linux Foundation. I'm not one to hold grudges against people who accept their past mistakes, fix the presence and then move on. But no, they haven't fixed any issues.
They are having one of the worst track records in terms of intentional GPL compliance issues for many years, showing outright disrespect for Linux, the GPL and ultimately the rights of the Linux developers, not resolving those issues and at the same time joining the Linux Foundation? What kind of message sends that?
This question has generated many pixels’ worth of traffic on the OSI License discuss email list. This post is just a brief summary of a little of the discussion, which has been going on for some weeks and shows no sign of slowing down.
There are currently 80 Open Sourse Initiative-approved open source licenses. It’s nice that the Army (I’m a veteran) wants to not only write software licensed as open source, but OSI-approved open source software. (Go Army!)
But does the Army really need its own special OS license? Should the Air Force have a different one? Will the Navy want a Coastal Combat Open Source License, along with a separate Blue Water Open Source License? That might sound far-fetched, but Mozilla has three separate open source licenses, Microsoft has two, and Canada’s province of Québec also has three. So why shouldn’t the U.S. Department of Defense have a whole slew of open source licenses?
There are five different GPL licenses alone, and I assure you that even the Coast Guard dwarfs the Free Software Foundation in both personnel and resources.
Microsoft integrates Black Duck open-source tools with Visual Studio [Ed: Microsoft again pays its proxy Black Duck which helps attack the GPL]
This week we returned to clearing the backlog of approved entries. During the meeting we were joined by a developer looking to discuss the licensing of their software developed under contract with an institution of higher learning. The issue of license compatibility came up and we talked about how GPLv2 or later can upgrade to GPLv3. All the while we plugged away at the backlog getting it to drop somewhat over the course of the meeting.
VMware, the company known for changing the datacenter landscape with virtualization, has joined the Linux Foundation as a Gold member. This is the second highest membership tier at The Linux Foundation.
I woke this morning to Thorsten claiming the new GitHub Terms of Service could require the removal of Free software projects from it. This was followed by joeyh removing everything from github. I hadn’t actually been paying attention, so I went looking for some sort of summary of whether I should be worried and ended up reading the actual ToS instead. TL;DR version: No, I’m not worried and I don’t think you should be either.
First, a disclaimer. I’m not a lawyer. I have some legal training, but none of what I’m about to say is legal advice. If you’re really worried about the changes then you should engage the services of a professional.
The Internet saw Github's new TOS yesterday and collectively shrugged.
I don't have any lawyers, but the way Github's new TOS is written, I feel I'd need to consult with lawyers to understand how it might affect the license of my software if I hosted it on Github.
And the license of my software is important to me, because it is the legal framework within which my software lives or dies. If I didn't care about my software, I'd be able to shrug this off, but since I do it seems very important indeed, and not worth taking risks with.
If I were looking over the TOS with my lawyers, I'd ask these questions...
The new Terms of Service of GitHub became effective today, which is quite problematic — there was a review phase, but my reviews pointing out the problems were not answered, and, while the language is somewhat changed from the draft, they became effective immediately.
Now, the new ToS are not so bad that one immediately must stop using their service for disagreement, but it’s important that certain content may no longer legally be pushed to GitHub. I’ll try to explain which is affected, and why.
I’m mostly working my way backwards through section D, as that’s where the problems I identified lie, and because this is from easier to harder.
Github recently drafted an update to their Terms Of Service. The new TOS is potentially very bad for copylefted Free Software. It potentially neuters it entirely, so GPL licensed software hosted on Github has an implicit BSD-like license. I'll leave the full analysis to the lawyers, but see Thorsten's analysis.
I contacted Github about this weeks ago, and received only an anodyne response. The Free Software Foundation was also talking with them about it. It seems that Github doesn't care or has some reason to want to effectively neuter copyleft software licenses.
Communication is one of the seven essential elements to ensure the success of open source license compliance activities. And it’s not enough to communicate compliance policies and processes with executive leadership, managers, engineers, and other employees. Companies must also develop external messaging for the developer communities of the open source projects they use in their products.
I’m currently over at FOSDEM, and have been asked by a couple of people about the state of ZFS and Debian. So, I thought I’d give a quick post to explain what Debian’s current plan is (which has come together with a lot of discussion with the FTP Masters and others around what we should do).
Debian has always prided itself in providing the unequivocally correct solution to our users and downstream distributions. This also includes licenses – we make sure that Debian will contain 100% free software. This means that if you install Debian, you are guaranteed freedoms offered under the DFSG and our social contract.
When I was at Mozilla and WMF, I frequently got asked how to give proper credit when using Creative Commons-licensed images in slideshows. I got the question again last week, and am working on slides right now, so here’s a quick guide.
Non-profits that provide project support have proven themselves to be necessary for the success and advancement of individual projects and Free Software as a whole. The Free Software Foundation (founded in 1985) serves as a home to GNU projects and a canonical list of Free Software licenses. The Open Source Initiative came about in 1998, maintaining the Open Source Definition, based on the Debian Free Software Guidelines, with affiliate members including Debian, Mozilla, and the Wikimedia Foundation. Software in the Public Interest (SPI) was created in the late 90s largely to act as a fiscal sponsor for projects like Debian, enabling it to do things like accept donations and handle other financial transactions.
Software Freedom Conservancy is pleased to announce the addition of Clojars as its newest member project. Clojars is a community-maintained repository for free and open source libraries written in the Clojure programming language. Clojars emphasizes ease of use, publishing library packages that are simple to use with build automation tools.