Jure Repinc (JLP) jrepin@identi.ca

URL: https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/

February 25, 2016 by Bradley M. Kuhn and Karen M. Sandler

GPL Violations Related to Combining ZFS and Linux

This post discusses an atypical GPL violation. Unlike most GPL violations Conservancy faces, in this case, a third-party entity holds a magic wand that can instantly resolve the situation. Oracle is the primary copyright holder of ZFS, and, despite nearly eight years (going back to the days of Sun's control of the code) of the anti-license-proliferation community's urging, Oracle continues to license their code under their own, GPL-incompatible license. While this violation has many facets, and Oracle did not themselves violate GPL in this specific case, they hold the keys to this particular kingdom and they forbid the Linux community to enter. While there are complexities that we must address, in this context, Oracle could make everyone's life easier by waving their magic relicensing wand. Nevertheless, until they do, since GPL-incompatible licenses are the root of all GPL violations, combinations of GPL'd code with Oracle's GPL-incompatible code yield GPL violations, such as the ongoing violation by Canonical, Ltd.

The Basic Facts

Sun released the Z File System (ZFS) code under the Common Development and Distribution License, version 1 (CDDLv1) as part of OpenSolaris. Sun was ultimately acquired by Oracle. Community members, mostly acting non-commercially, have improved ZFS and adapted it to function with Linux, but unfortunately, CDDLv1 is incompatible with GPLv2, so distribution of binaries is not permitted (see below for details). Many community members have been frustrated for years that Oracle didn't simply relicense the code under a GPLv2-compatible license.

The situation escalated last week because Canonical, Ltd. announced their plans to commercially distribute, in Ubuntu 16.04, a binary distribution of ZFS as a Linux kernel module, which adapts ZFS natively for Linux. Conservancy contacted Canonical to inform them of their GPL violation, and Canonical encouraged us to speak publicly. We're glad to do so to clarify the differing views on this issue. As you'll read below, Conservancy disagrees with Canonical's decision, and Conservancy hopes to continue dialogue with Canonical regarding their violation. We do not give up on friendly resolution of a GPL violation easily and are glad Canonical seeks to transparently discuss both sides of this issue in public.

Summary of our Conclusion

We are sympathetic to Canonical's frustration in this desire to easily support more features for their users. However, as set out below, we have concluded that their distribution of zfs.ko violates the GPL. We have written this statement to answer, from the point of view of many key Linux copyright holders, the community questions that we've seen on this matter.

Specifically, we provide our detailed analysis of the incompatibility between CDDLv1 and GPLv2 — and its potential impact on the trajectory of free software development — below. However, our conclusion is simple: Conservancy and the Linux copyright holders in the GPL Compliance Project for Linux Developers believe that distribution of ZFS binaries is a GPL violation and infringes Linux's copyright. We are also concerned that it may infringe Oracle's copyrights in ZFS. As such, we again ask Oracle to respect community norms against license proliferation and simply relicense its copyrights in ZFS under a GPLv2-compatible license.

GPL Incompatibility

The license of Linux, the GNU General Public License, version 2 (GPLv2), is conceptually known as a strong copyleft license. A strong copyleft license extends software freedom policies as far as copyright law allows. As such, GPLv2 requires that, when combinations and/or derivatives are made under copyright law with GPLv2'd works, the license of the resulting combination and/or derivative is also GPLv2.

The Free Software Foundation (FSF) has long discussed the question of licenses incompatible with the GPL, pointing out that:

In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.

License compatibility is not merely a question for Free Software licenses. We can analyze any two copyright licenses and consider whether they are compatible.

In the proprietary software world, rarely are two licenses ever compatible. You can't, by default, license a copy of Oracle's database, and then make a combination with Apple's iOS. To do so, you would need to negotiate (and pay for) a special license from both Apple and Oracle to make that combination.

Furthermore, with proprietary software, there is a practical problem somewhat unrelated to the legal permission: you must procure (again, likely for a rather expensive fee) a copy of the source code for Apple's and Oracle's proprietary software to have the practical ability to make the combination.

Since the GPL, and all copyleft licenses, are fundamentally copyright licenses, the analysis is similar. However, GPL requires that all software distributions include complete corresponding source code to any binaries, so the practical problem never presents itself. Nevertheless, when you wish to combine GPL'd software with some other software and distribute the resulting combination, both the copyright holders of the GPL'd software and the copyright holders of the other software must provide a license that allows distribution of the combination.

Most prefer to discuss the issue of combining truly proprietary, no-source-available copyrighted material with GPL'd software, as it creates the most stark practical contrast, and is the most offensive fact pattern. Proprietary software gives the users no freedom to even examine, let alone modify, rebuild, and reinstall the software. The proprietary license doesn't allow nor even give the practical ability to redistribute source code, and the GPL mandates source distribution when binary distribution occurs. The incompatibility is intuitively obvious. Few consider the fact that proprietary software licensing is just one (rather egregious) example of a GPL-incompatible license.

In that context, we can imagine licenses that are GPL-incompatible, but do give some interesting permissions to users. An example is source-code-available systems that prohibit commercial distribution and forbid modification to the source code. The GPL has terms that permit modification and allow commercial distribution of GPL'd software, and as such, even though source code is available for non-commercial, non-modifiable software, the license is nonetheless GPL-incompatible.

Finally, we can consider the most subtle class of GPL-incompatibility, in which we find ZFS's license, the Common Development and Distribution License, version 1 (CDDLv1). The CDDLv1 is considered both a Free Software and an Open Source license, and is a weak copyleft license. Nevertheless, neither CDDLv1 nor GPLv2 permits combination of copyrighted material under the other license.

To understand this non-intuitive incompatibility, we can analyze in detail the requirements of both licenses. First, GPLv2 requires:

[§2](b) You must cause any work that you distribute … that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole … under the terms of this License.…

[§]3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also…

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above…

[§]6. …You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

According to these provisions of GPLv2, if you create a binary work that incorporates components from the GPLv2'd program, you must provide the complete corresponding source for that entire work with the binary, and the terms of the GPLv2 apply to that source. If the sources as a whole cannot be outbound-licensed under GPLv2, you have no permission under copyright law to distribute the binary work, since GPLv2 didn't grant you that permission.

GPLv2-compatible licenses do not contradict the requirements of GPLv2, which is what makes them compatible. For example, highly permissive licenses like the ISC license allow imposition of additional licensing requirements (even proprietary ones), and so combining ISC-licensed source and GPLv2'd source into a binary work is permitted; compliance with GPLv2 is possible when distributing binaries based on the combined sources.

CDDLv1, however, contains various provisions that are incompatible with that outcome. Specifically, CDDLv1 requires (emphasis ours):

[§]3.1 … Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. …

[§] 3.4 … You may not offer or impose any terms on any Covered Software in Source Code form that alters or restricts the applicable version of this License

CDDLv1 is a weak copyleft license in that it allows you create a binary work with components under different terms (see CDDLv1§3.6). However, as seen in the text above, with regard to the specific copyrighted material already under CDDLv1, that material must remain only licensed under the terms of the CDDLv1. Furthermore, when redistributing the source code, you cannot alter the terms of the license on that copyrighted material.

GPLv2, as shown above, requires that you alter those terms for the source code — namely, as a strong copyleft, the terms of GPLv2 apply to the entire complete corresponding source for any binary work. Furthermore, downstream users must have to permission make GPLv2'd modifications to that source. This creates a contradiction; you cannot simultaneously satisfy that obligation of GPLv2 and also avoid alter[ing] the terms of CDDLv1-licensed source. Thus, the licenses are incompatible, and redistributing a binary work incorporating CDDLv1'd and GPLv2'd copyrighted portions constitutes copyright infringement in both directions. (In addition to this big incompatibility, there are also other smaller incompatibilities throughout CDDLv1.)

We believe Sun was aware when drafting CDDLv1 of the incompatibilities; in fact, our research into its history indicates the GPLv2-incompatibility was Sun's design choice. At the time, Sun's apparent goal was to draw developers away from GNU and Linux development into Solaris. Not only did Sun not want code from GNU and Linux in Solaris, more importantly, Sun did not want technological advantages from Solaris' kernel to appear in Linux.

Much has changed in the seven and a half years since CDDLv1's publication and promulgation. OpenSolaris has been discontinued; CDDLv1 codebases never became an active area of Free Software development like GNU and Linux. Oracle could now easily indicate that combination of ZFS with Linux into binary works is permitted, (e.g., as the overwhelming majority copyright holder0, Oracle could make a decree like the one University of California did to fix a similar incompatibility). Until Oracle takes an action like that, it remains a license violation of both CDDLv1 and GPLv2 to distribute binary works that combine together and/or derive from both GPLv2 and CDDLv1 sources.

What Constitutes a Combined/Derivative Work?

Once license incompatibility is established, the remaining question is solely whether or not combining ZFS with Linux creates a combined and/or derivative work under copyright law (which then would, in turn, trigger the GPLv2 obligations on the ZFS code).

Conservancy has helped put similar questions (still pending) before a Court, in Hellwig's VMware case that Conservancy currently funds. In fact, the same questions come up with all sorts of GPL-incompatible Linux modules and reuses of Linux code.

Courts have not spoken specifically on this question; precedents that exist are not perfectly on-topic. Citing an opinion of a lawyer is often not helpful in this context, because lawyers advise clients, and argue zealously for their clients' views. When Courts are unclear on a matter, it generates disputes, and only Courts (or possibly new legislation) can ultimately resolve those disputes.

Nevertheless, our lawyers have analyzed these situations with the assistance of our license compliance and software forensics staff for many years, and we have yet to encounter a Linux module that — when distributed in binary form — did not, in our view, yield combined work with Linux. The FSF, stewards of the GPL, have stated many times over the past decades that they believe there is no legal distinction between dynamic and static linking of a C program and we agree. Accordingly, the analysis is quite obvious to us1: if ZFS were statically linked with Linux and shipped as a single work, few would argue it was not a “work based on the Program” under GPLv2. And, if we believe there is no legal difference when we change that linking from static to dynamic, we conclude easily that binary distribution of ZFS plus Linux — even with ZFS in a .ko file — constitutes distribution of a combined work, which we name Linux+ZFS.

Canonical has found some lawyers who disagree — a minority position, from our understanding of community norms. But Canonical's public position on the matter contributes to license uncertainty, and opponents of Free Software may use this as an opportunity to marginalize copyleft enforcement generally. Canonical can resolve the situation by ceasing the infringing distribution, but Oracle can also unilaterally resolve this trivially with a simple relicense of ZFS to a GPL-compatible license.

Thus, all parties currently stand at an impasse. Conservancy (as a Linux copyright holder ourselves), along with the members of our coalition in the GPL Compliance Project for Linux Developers, all agree that Canonical and others infringe Linux copyrights when they distribute zfs.ko. Canonical's lawyers disagree. Oracle refuses to relicense their ZFS copyrights under a GPL-compatible license.

Ultimately, various Courts in the world will have to rule on the more general question of Linux combinations. Conservancy is committed to working towards achieving clarity on these questions in the long term. That work began in earnest last year with the VMware lawsuit, and our work in this area will continue indefinitely, as resources permit. We must do so, because, too often, companies are complacent about compliance. While we and other community-driven organizations have historically avoided lawsuits at any cost in the past, the absence of litigation on these questions caused many companies to treat the GPL as a weaker copyleft than it actually is.

Why Conservancy Does Not Use Litigation Immediately

As discussed in our principles, Conservancy, while willing to litigate, uses litigation only as a last resort. Compliance actions are primarily education and assistance processes to aid those who are not following the license. We completely exhaust every other diplomatic option for compliance before seeking resolution from the Courts.

“Almost There” is More Painful Than Proprietary

Conservancy and our GPL Compliance Project for Linux Developers are quite sympathetic to the feeling of “almost there” that exists with ZFS for Linux. CDDL is a Free Software license, but sadly a GPL-incompatible one. Like a partial fix for a problematic bug, a GPL-incompatible Free Software license feels like a solution that's “oh-so-close”. Everyone wants to try to tweak that incomplete solution into a full one. We hope this explanation helps bring clarity that the seemingly “almost there” of combining CDDL'd and GPL'd code is a mirage. The community must seek together a better solution.

Oracle holds the better solution in their hands; like waving a magic wand, they can take any of a myriad of actions to communicate permission to relicense ZFS under GPL. Conservancy encourages Free Software enthusiasts and for-profit companies alike to lobby Oracle to relicense their ZFS copyrights. While this change by Oracle cannot resolve Canonical's violation, Oracle's relicensing would create a path for Canonical that might ultimately yield a compliant binary distribution of Linux+ZFS. As such, we've asked Canonical to commit to lobbying Oracle for this change.

Is The Analysis Different With Source-Only Distribution?

We cannot close discussion without considering one final unique aspect to this situation. CDDLv1 does allow for free redistribution of ZFS source code. We can also therefore consider the requirements when distributing Linux and ZFS in source code form only.

Pure distribution of source with no binaries is undeniably different. When distributing source code and no binaries, requirements in those sections of GPLv2 and CDDLv1 that cover modification and/or binary (or “Executable”, as CDDLv1 calls it) distribution do not activate. Therefore, the analysis is simpler, and we find no specific clause in either license that prohibits source-only redistribution of Linux and ZFS, even on the same distribution media.

Nevertheless, there may be arguments for contributory and/or indirect copyright infringement in many jurisdictions. We present no specific analysis ourselves on the efficacy of a contributory infringement claim regarding source-only distributions of ZFS and Linux. However, in our GPL litigation experience, we have noticed that judges are savvy at sniffing out attempts to circumvent legal requirements, and they are skeptical about attempts to exploit loopholes. Furthermore, we cannot predict Oracle's view — given its past willingness to enforce copyleft licenses, and Oracle's recent attempts to adjudicate the limits of copyright in Court. Downstream users should consider carefully before engaging in even source-only distribution.

We note that Debian's decision to place source-only ZFS in a relegated area of their archive called contrib, is an innovative solution. Debian fortunately had a long-standing policy that contrib was specifically designed for source code that, while licensed under an acceptable license for Debian's Free Software Guidelines, also has a default use that can cause licensing problems for downstream Debian users. Therefore, Debian communicates clearly to their users that this code is problematic by keeping it out of their main archive. Furthermore, Debian does not distribute any binary form of zfs.ko.

(Full disclosure: Conservancy has a services agreement with Debian in which Conservancy occasionally gives its opinions, in a non-legal capacity, to Debian on topics of Free Software licensing, and gave Debian advice on this matter under that agreement. Conservancy is not Debian's legal counsel.)

Do Not Rely On This Document As Legal Advice

You cannot and should not rely on this document as legal advice. Our lawyers, in conjunction with our GPL compliance and software forensics experts, have analyzed the Linux+ZFS that Canonical includes in their Ubuntu 16.04 prereleases. Conservancy has determined, with the advice of both inside and outside law firm legal counsel, that the binary distribution constitutes a derivative and/or combined work of ZFS and Linux together, and therefore violates the GPL, as explained above. We also know from Canonical's blog post that they have found other lawyers to give them contradictory advice. Such situations are common on groundbreaking legal issues, and, after all, copyleft is perhaps the most novel legal construction for copyright in its history. Lawyers and their clients who oppose copyleft will attempt to limit copyleft's scope (with litigation, FUD, and moxie), and those of us who use copyleft as a tool for software freedom will diametrically seek to uphold its scope to achieve the license drafter's and licensors' intended broad impact for software freedom.

Indeed, Conservancy believes this situation is one battle in a larger proxy war by those who seek to limit the scope of strong copyleft generally. Yet, the GPL not only benefits charitable community organizations like Conservancy, but also for-profit companies, since GPL ensures your competitors cannot circumvent the license and gain an unfair advantage. We therefore urge charities, trade associations and companies who care about Linux to stand with us in opposition of GPL violations like this one.

0 More work might be required to relicense all modern ZFS code, since others have contributed, but we expect that those contributors would gladly relicense in the same manner if Oracle does first.

1 More discussion on these issues can be found in this section of Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide, which is part of copyleft.org, a project co-sponsored by the FSF and Software Freedom Conservancy.

Posted by Bradley M. Kuhn and Karen M. Sandler on February 25, 2016. Please email any comments on this entry to info@sfconservancy.org.

URL: https://sfconservancy.org/blog/2015/nov/09/gpl-tpp/

A Blog post by Bradley M. Kuhn and Karen M. Sandler

GPL Enforcement and the Trans-Pacific Partnership

Many people have criticized the proposed Trans-Pacific Partnership (TPP) treaty since the text was released. In particular, some of the terms in the agreement are bad for software freedom and other social justice causes. Despite the TPP's stated intention to bring "social benefits" in addition to economic growth, the terms of TPP work against social benefits and awards too much power and control to large multinational corporations, including proprietary software companies.

The agreement text is lengthy and complex, filed with bad provisions. A few days ago, the Free Software community uncovered the following text from the TPP:

1. No Party shall require the transfer of, or access to, source code of software owned by a person of another Party, as a condition for the import, distribution, sale or use of such software, or of products containing such software, in its territory.

2. For the purposes of this Article, software subject to paragraph 1 is limited to mass-market software or products containing such software and does not include software used for critical infrastructure.

3. Nothing in this Article shall preclude:

(a) the inclusion or implementation of terms and conditions related to the provision of source code in commercially negotiated contracts; or

(b) a Party from requiring the modification of source code of software necessary for that software to comply with laws or regulations which are not inconsistent with this Agreement.

4. This Article shall not be construed to affect requirements that relate to patent applications or granted patents, including any orders made by a judicial authority in relation to patent disputes, subject to safeguards against unauthorised disclosure under the law or practice of a Party.

The revelation of this clause has confused our community, as it appears as if this provision, once adopted, might impact or restrict the international operation of copyleft licenses. Below we explain that, while everyone should reject and oppose this provision — and the rest of TPP — this provision has no dramatic impact on copyleft licensing.

First, as others have pointed out, Party is a defined term that refers specifically to government entities that sign the treaty. As such, the provision would only constrain the behavior of governments themselves. There are some obviously bad outcomes of this provision when those governmental entities interfere with public safety and ethical distribution of software, but we believe this provision will not interfere with international enforcement of copyleft.

Copyleft licenses use copyright as a mechanism to keep software free. The central GPL mechanism that copyright holders exercise to ensure software freedom is termination of permission to copy, modify and distribute the software (per GPLv2§4 and GPLv3§8). Under GPL's termination provisions, non-compliance results in an automatic termination of all copyright permissions. In practice, distributors can chose — either they can provide the source code or cease distribution. Once permissions terminate, any distribution of the GPL'd software infringes copyrights. Accordingly, in an enforcement action, there is no need to specifically compel a government to ask for disclosure of source code.

For example, imagine if a non-US entity ships a GPL-violating, Linux-based product into the USA, and after many friendly attempts to achieve compliance, the violating company refuses to comply. Conservancy can sue the company in US federal court, and seek injunction for distribution of the foreign product in the USA, since the product infringes copyright by violating the license. The detailed reasons for that infringement (i.e., failure to disclose source code) is somewhat irrelevant to the central issue; the Court can grant injunction (i.e., an order to prevent the company from distributing the infringing product) based simply on the violator's lost permissions under the existing copyright license. The Court could even order the cease of import of the infringing products.

In our view, the violator would be unaffected under the above TPP provision, since the Court did not specifically compel release of the source code, but rather simply ruled that the product generally infringed copyrights, and their distribution rights had fully terminated upon infringement. In other words, the fact that the violator lost copyright permissions and can seek to restore them via source code disclosure is not dispositive to the underlying infringement claim.

While TPP thus does not impact copyright holders' ability to enforce the GPL, there are nevertheless plenty of reasons to oppose TPP. Conservancy therefore joins the FSF, EFF, and other organizations in encouraging everyone to oppose TPP.

Help support Conservancy and its efforts to defend the GPL by becoming a Supporter today.

Posted by Bradley M. Kuhn and Karen M. Sandler on November 9, 2015. Please email any comments on this entry to info@sfconservancy.org.

FSFEs role in the Bacula project

Support FSFE, join the Fellowship: https://fellowship.fsfe.org/login/join.php Make a one time donation: http://fsfe.org/donate/donate.html

on HN and reddit

A response to last night's OSCON talk.

URL: https://sfconservancy.org/news/2015/jul/15/ubuntu-ip-policy/

Conservancy & the FSF Achieve GPL Compliance for Canonical, Ltd. “Intellectual Property” Policy

Canonical, Ltd.'s Policy Complies With GPL But Fails To Address Other Important Software Freedom Issues

Today, Canonical, Ltd. announced an updated “Intellectual Property” policy. Conservancy has analyzed this policy and confirms that the policy complies with the terms of the GNU General Public License (GPL), but Conservancy and the FSF believe that the policy still creates confusion and possible risk for users who wish to exercise their rights under GPL.

Background

Conservancy, on behalf of its GPL Compliance Project for Linux Developers, and its other GPL'd projects such as Samba, first received a GPL violation report in April 2013 regarding the earlier Canonical, Ltd. “Intellectual Property” policy. After a few months working on this matter, Conservancy discovered that the FSF was also working on the issue. The FSF and Conservancy agreed that it was best for the GPL enforcement community to speak with one voice in negotiation with Canonical, Ltd. to resolve the matter amicably. Conservancy has since then coordinated with the FSF as they took the lead in seeking resolution for the matter. In recent weeks, both FSF and Conservancy have negotiated directly with Canonical, Ltd. to resolve the GPL violation.

Why The Original Policy Violated

The GPLv2§6 and GPLv3§10¶3 explicitly forbid restrictions on the rights already granted in the GPL. As such, any extra requirement imposed on distribution of GPL'd software violates GPL. Copyleft advocates have historically described such requirements this way: no further agreement can “trump” the rights granted by GPL.

For example, Canonical, Ltd.'s original policy required that redistributors needed to recompile the source code to create [their] own binaries. GPL never requires recompilation of binaries; rather, the GPL simply requires that you pass along source code that successfully can be recompiled into binaries (and installed) by someone skilled in software development. Requirement of such action as a condition of distribution is an extra requirement, and the GPL forbids its imposition.

Today's Change

Today, as an outcome of these careful negotiations between Canonical, Ltd., Conservancy and the FSF, Canonical, Ltd. published an updated policy that includes this revision:

Ubuntu is an aggregate work of many works, each covered by their own license(s). For the purposes of determining what you can do with specific works in Ubuntu, this policy should be read together with the license(s) of the relevant packages. For the avoidance of doubt, where any other license grants rights, this policy does not modify or reduce those rights under those licenses.

This change is sufficient for compliance with the GPL. This “trump clause” effectively reverses the default situation of the policy, and mandates that when Canonical, Ltd.'s policy contradicts something that the GPL requires, or prohibits something that the GPL allows, the rights granted in the GPL shall prevail.

While a trump clause is a reasonable way to comply with the GPL in a secondary licensing document, the solution is far from ideal. Redistributors of Ubuntu have little choice but to become expert analysts of Canonical, Ltd.'s policy. They must identify on their own every place where the policy contradicts the GPL. If a dispute arises on a subtle issue, Canonical, Ltd. could take legal action, arguing that the redistributor's interpretation of GPL was incorrect. Even if the redistributor was correct that the GPL trumped some specific clause in Canonical, Ltd.'s policy, it may be costly to adjudicate the issue.

Recommendations

Therefore, Conservancy encourages Canonical, Ltd. to make the many changes and improvements to their policy recommended during the FSF-led negotiations with them. Good community actors should embody the spirit of software freedom as well as meeting the exact letter of the rules.

Even more importantly, since non-copyleft licenses do not necessarily forbid imposition of further restrictions, the community of Ubuntu redistributors should respond with concern. While Conservancy believes the key software freedoms and rights to copy, modify and redistribute Ubuntu are fully assured by this change with regard to copylefted software, a trump clause does not help with regard to non-copyleft licenses. Since Ubuntu is an aggregation of many copylefted and non-copylefted programs, full permission to redistribute of Ubuntu as a whole remains in question.

Finally, Conservancy recommends reading the FSF's statement on Canonical, Ltd.'s policy as well.

Pump.io accounts can have an associated e-mail address, for notifications and password recovery, even if that's not requested when creating the account.

The web interface doesn't yet provide a way to add them later either, but identi.ca users have had e-mail addresses set since the migration from StatusNet to Pump.io, because those addresses were already configured in the StatusNet interface.

So basically the problem is that users of other servers can't set an e-mail, and users of identi.ca can't change their e-mail to a new one. Until now =)

Now the development version of Dianara supports setting your e-mail from the profile editor.

E-mail activity notificacions are not the greatest thing in the world at the moment (they're more useful if people use titles in posts, actually!), but they can be useful, plus having the possibility of password recovery is always nice ;)

This feature has not been very widely tested yet, but I've personally changed this account's e-mail, and set a new one in my other test account @microca.st, without any issues.

Thanks to @Laura Arjona for encouraging me to look into this again! I hope it helps!

Cheers! o/

Hi there! o/

Some highlights of what will be new in the upcoming version of my Pump.io client, Dianara 1.3.1, can be seen in the attached image:

• Option to browse a user's posts.
• Privacy category in the settings.
• Option to change the e-mail address associated with your account.
• Nick autocompleter shows user ID.
• Pasting plaintext with links will create proper links anywhere.

The "browse messages" option will appear in the drop-down menu that's available in any avatar, that is, in the Meanwhile activities, in all the posts and in all the comments. There's, sadly, a big catch: due to limitations in the information provided by the Pump API, you can only use this option with people in your same server. If you're jessie@microca.st, you can only browse posts by people @microca.st, etc. The feature loses a lot of usefulness at the moment due to this limitation, but still, it can be very useful when available.

The new Privacy category in the settings (if you've never visited this dialog, you really should) has two options, to avoid sending follow/unfollow activities to your followers, and to avoid sending add/remove (from list) activities.

This basically means that if you enable these options, only the person being followed, unfollowed, added, or removed will know about it, and nobody else. Keep in mind, however, that letting your followers receive this information helps the network grow!

Besides privacy, enabling these options helps if you are about to start following or stop following a lot of people. This way you don't flood your followers feeds with a lot of "Jessie followed JohnDoe", and the like ;)

The third item is explained in the link.

Not much to tell about the fourth one... since v1.3.0, when typing @ you get a list of users to mention. Now, if you have, say, 3 contacts named "Albert" (and nothing else), you can know who's who by their ID's. As a bonus, the new popup is better positioned and sized =)

As for the fifth one, up until now, if you pasted a url-looking text, like http://something, a proper HTML link was created, and all was fine. But if you pasted, say, from a text file, something like "check out this cool link: http://cool-link", nothing happened and the link was not really a link, and not clickable. Now, something like the latter case will work, as long as what you're pasting is plain text.

If what you're pasting is rich text (say, from a web browser or a rich text editor), links should already be links, so that works as always ;)

This post has turned out a lot longer than expected... here's the current changelog, in case you want a more complete list.

You can find the development version of Dianara at https://gitlab.com/dianara/dianara-dev.

Cheers! o/

A restriction on technological restrictions

Support FSFE, join the Fellowship: https://fellowship.fsfe.org/login/join.php Make a one time donation: http://fsfe.org/donate/donate.html

Thank you very much for your excellent work!!

Hi there, pumpers!

As planned, here's the latest in Dianara-land, v1.3.0.

The main change since v1.2.5 has been the refactoring of the way the timelines are handled, which makes updates much faster and the interface a lot smoother. The number of unread posts is not reset on each update anymore. If you get more new posts than what you have configured to show in one page, you’ll be notified of how many more posts are pending to be received in the next update. The posts opened from the Meanwhile feed via the “+” button will now be able to load the comments much more often.

Other smaller enhancements are a few new options in the Configuration dialog, such as the options to highlight comments made by you, or comments made by the author of a post and to choose the size of avatars, or more obvious “frames” for shared posts.

There’s also an option to hide duplicated posts; that is, posts which were already visible in the timeline will not be shown again when someone shares them.

One new feature that is not visible is nickname completion, a.k.a. “mentioning”. If you type ‘@‘ while composing a post, you’ll get a list of the people you follow. You can then type the first characters of a name and use the arrows and enter keys to select the contact you wish to mention. When creating a note, this will add that contact to the “To” list, which means they’ll get your post in their “direct messages” inbox. This was possible before, using the “To” and “Cc” menus, but now it’s simpler.

Check the CHANGELOG for a more detailed list of changes.

More at the blog: https://jancoding.wordpress.com/2015/05/01/dianara-v1-3-0-is-out/ 

Cheers! ;)

Thank you! We Met our Anonymous Donor Match Goal!

Thanks to everybody who donated to our campaign in this past month! We're thrilled to tell you that we exceeded the goal of our match target, raising a combined total of $100,440 in 1,123 donations. With so many donors it's clear that people care about copyleft and its enforcement. We are so excited about the success of the campaign and are reinvigorated from the show of support.

The fundraising drive also doubled the number of Conservancy Supporters. The Supporter program was launched in December to help the organization's financial stability through individual giving. If you haven't already, consider signing up today!

Joint statement : Maximising inclusiveness and engagement through the use of Open Standards in the European Commission

Today is Document Freedom Day, the international day to celebrate and raise awareness of Open Standards. On this occasion, we would like to reflect on the importance for public institutions in general, and for the European Commission in particular, considering its leadership role, of using Open Standards in all their digital communication and services. Support FSFE, join the Fellowship: https://fellowship.fsfe.org/login/join.php Make a one time donation: http://fsfe.org/donate/donate.html