LWN: Comments on "Toward healthy paranoia"

Toward healthy paranoia

khim — Thu, 26 Sep 2013 17:50:11 +0000

GnuTLS has gone back to (L)GPLv2+, not GPLv2.

Well, yeah, that's true, but it's not that important. The important fact is that is stopped participating in the FSF's jihad and instead have chosen to stay relevant.

Only time will tell if they'll succeed or if it's case of “too little too late”.

The license change is because a number of projects couldn't use newer versions of GnuTLS because they were using GPLv2 only. i.e., this is allowing for those annoying projects, not becoming one of them.

The important fact is not that it can be used in conjunction with GPLv2 programs, the important fact is that now it can be used by various vendors and linked with GPLv2, Apache, or even proprietary programs.

Toward healthy paranoia

nix — Thu, 26 Sep 2013 17:34:03 +0000

GnuTLS has gone back to (L)GPLv2+, not GPLv2. The license change is because a number of projects couldn't use newer versions of GnuTLS because they were using GPLv2 only. i.e., this is allowing for those annoying projects, not becoming one of them.

A few ideas

cesarb — Sat, 21 Sep 2013 20:00:38 +0000

On the first point, I just found https://securityblog.redhat.com/2013/09/18/reproducible-b...

Toward healthy paranoia

khim — Fri, 20 Sep 2013 21:05:08 +0000

The FSF obviously felt the proposed Creative Commons license was "similar in spirit" to the GFDL, while resolving a number of issues which arose because what it was being applied to was not, in fact, documentation.

Few questions:
1. How could FSF know if CC-BY-SA 10.0 will have any resemblance to GFDL at all? They allowed relicensing from GFDL 1.2 to CC-BY-SA 10.0, after all.
2. Their promise quite explicitly said any later version published by the Free Software Foundation - is it fair to abuse this permission to switch to some other license not published by Free Software Foundation?
2. If CC-BY-SA is “similar in spirit” and actually resembles GFDL then why FSF says (quite explicitly) that we do not want to grant people this permission for any and all works released under the FDL?

They weren't breaking any promises, just using their position as the authoritative publisher of new versions of the GFDL to resolve real problems and concerns relating the GFDL in the context of WikiMedia.

No. They were abusing their position as the authoritative publisher of new versions of the GFDL to loan certain GFDL-licensed works to other fiefdom. They most definitely don't feel that CC-BY-SA is “similar in spirit” enough to give free pass to all GFDL users, they only exchanged parts of their congregation, not all of them.

There are no "vassels" here, only free individuals choosing licenses for their contributions without thinking through all the possible consequences.

It's idle talk. We can agree that individuals have chosen licenses without thinking too much about consequences, but there are also the fact that FSF treated these “free individuals” as serfs who have no power over their own creations because they once signed them away by choosing to license their work under “GNU Free Documentation License, Version 1.[012] or any later version”. Their wishes were irrelevant, their intents were ignored, new license was created to fulfill the Wikimedia Foundation's request, not to satisfy unanimous resolution of Wikipedia authors. Indeed with unanimous resolution they could have switched to any license of their choosing without FSF's involvement.

Note that CC-BY-SA is even more devious then GFDL: it embeds ability to use “a later version of this License” in the text of license itself. Even if you distribute something under CC-BY-SA 2.5 or CC-BY-SA 3.0 one may use text of CC-BY-SA 10.0 (which can include anything Creative Commons Corporation will want to include in it) and you can not disagree with that hijacking by omitting “or later” text from the license grant.

Toward healthy paranoia

nybble41 — Fri, 20 Sep 2013 18:06:40 +0000

> If I decide to participate in some project then I should accept the license they are using. “Or later” clauses, CLAs and all that. Doing anything else is sheer insanity.

Obviously. The project can't accept contributions without "or later" from just one contributor; it's all or nothing. The question was whether or not to participate in the first place given a project which has adopted an "or later" clause. If enough people choose not to participate in projects with such a clause, the projects will most likely drop it in order to regain contributors.

Toward healthy paranoia

nybble41 — Fri, 20 Sep 2013 18:00:15 +0000

> Well, sure. They accepted that the Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. And they were promised that such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Good, we're in agreement then. The FSF obviously felt the proposed Creative Commons license was "similar in spirit" to the GFDL, while resolving a number of issues which arose because what it was being applied to was not, in fact, documentation. They weren't breaking any promises, just using their position as the authoritative publisher of new versions of the GFDL to resolve real problems and concerns relating the GFDL in the context of WikiMedia.

> That's fundamental violation of principle The vassal of my vassal is not my vassal.

There are no "vassels" here, only free individuals choosing licenses for their contributions without thinking through all the possible consequences.

Toward healthy paranoia

khim — Fri, 20 Sep 2013 16:42:40 +0000

Of course, there is no requirement for the project to include contributions without such a clause, and doing so may seriously complicate project management down the road. If no compromise can be reached they may simply have to do without your contribution.

If I decide to participate in some project then I should accept the license they are using. “Or later” clauses, CLAs and all that. Doing anything else is sheer insanity. If my contribution is large enough I may decide to create separate project (which may or may not be pulled as third-party component into other one), if it's not large enough then I should accept the offer I was given, but I should not submit pieces under different license. Heck, even FSF explicitly says We recommend you use this license for any Perl 4 or Perl 5 package you write, to promote coherence and uniformity in Perl programming even when they say We urge you to avoid using it about it's first half (Artistic 1.0 license).

Toward healthy paranoia

khim — Fri, 20 Sep 2013 16:31:37 +0000

You can't claim that the contributors didn't have a say in the license.

They didn't.

They agreed to any changes the FSF might make when they agreed to the "or later" clause in the original license.

Well, sure. They accepted that the Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. And they were promised that such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

In the same way, if you choose to license your work with an "or later" clause you give up control over how the work may be licensed in the future to whichever organization publishes the license.

Sure. But this is not what transpired here. Instead of receiving new similar in spirit version of license they were transferred en-masse from one Suzerain to another. That's fundamental violation of principle The vassal of my vassal is not my vassal. This may or may not be legal, but I know that it's not something I would like.

If that isn't what you want, don't license the work under an "or later" clause in the first place.

That's what I try to do lately, yes. I was significantly more forgiving to these clauses in the past, but after GPLv3 and GFDLv1.3 abuses of power by FSF it becomes more and more clear to me that the ability “to bugfix the license” is not good enough reason to give this much power to third party. Instead it's more honest to use BSD (or maybe Apache) license and give equal powers to everyone. Situation is not all that dissimilar to problem of Canonical's copyright assignment.

Toward healthy paranoia

nybble41 — Fri, 20 Sep 2013 15:15:40 +0000

> They convinced FSF to apply it's power and bam: opinion of over thousand people about how their work can be used went to the wolves. ... I'm saying that it was made against of express wishes of sizable chunk of copyright holders. ... With copyright you are not supposed to vote. ... Yet FSF or CC can do such changes relicensing twice per day ... and nobody can say anything at all.

You can't claim that the contributors didn't have a say in the license. They agreed to any changes the FSF might make when they agreed to the "or later" clause in the original license. This is a bit like complaining that the code you published under the GPL is being used to guide nuclear missiles; it was licensed for use by anyone, for any purpose, and you can't take that back later. In the same way, if you choose to license your work with an "or later" clause you give up control over how the work may be licensed in the future to whichever organization publishes the license. If that isn't what you want, don't license the work under an "or later" clause in the first place.

Of course, there is no requirement for the project to include contributions without such a clause, and doing so may seriously complicate project management down the road. If no compromise can be reached they may simply have to do without your contribution.

Toward healthy paranoia

khim — Fri, 20 Sep 2013 01:29:12 +0000

As stated in your link 17.000 Wikimedia/Wikipedia authors voted on it with 75 % being in favour of the license change.

Right. Small percentage of Wikipedia copyright holders held a vote and even among them about 10% (that's over thousand copyright-holders, remember?) voted against said change. Without FSF's power to unilaterally change the license they faced lengthy (probably multi-year) process with uncertain outcome. They convinced FSF to apply it's power and bam: opinion of over thousand people about how their work can be used went to the wolves.

The FSF was just an accomplice in that plot originating in the Wikimedia communities as it had the power to allow licensing changes through the 'or later' clause.

Indeed. Note that votes, opinions and all other stuff was only needed to convince FSF, FSF had no need for any votes to change the license. It could have made it even if votes showed that two guys are for the change and 1698 are against.

P.S. Note that I'm not saying that this change was bad. I'm saying that it was made against of express wishes of sizable chunk of copyright holders. Recall how long it took for the Dell to overcome Icahn's opposition - and this is in case where deeds are supposed to be done by vote while Icahn only had 6% of voting power. With copyright you are not supposed to vote. Indeed, when nine lines were included in Android against Sun (and Oracle) wishes they raised racked to the sky, won the argument and only failed to convince court that incorrectly appropriated nine lines are worth billions. Yet FSF or CC can do such changes relicensing twice per day (if that'll be their wish) and nobody can say anything at all.

Toward healthy paranoia

lsl — Thu, 19 Sep 2013 23:44:36 +0000

> Remember how FSF unilaterally shifted the whole Wikipedia without asking it's authors about anything to CC-BY-SA 3.0?

The FSF? Unilaterally? Is it even possibly to make a more biased account of that story? As stated in your link 17.000 Wikimedia/Wikipedia authors voted on it with 75 % being in favour of the license change. The FSF was just an accomplice in that plot originating in the Wikimedia communities as it had the power to allow licensing changes through the 'or later' clause.

Toward healthy paranoia

khim — Thu, 19 Sep 2013 20:22:40 +0000

Actually, the GPL (v2 or otherwise) ITSELF discusses NONE of this.

Sorry, but it does:

9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

Discussion about “later versions” is very much part of GPLv2—but Linus was apparently first who studied it enough to understand what it may mean in the future, found that GPLv2 is not like MPL (which explicitly says that You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape) or CC-BY-SA (which says You may distribute, publicly display, publicly perform, or publicly digitally perform a Derivative Work only under the terms of this License, a later version of this License with the same License Elements as this License, or a Creative Commons iCommons license that contains the same License Elements as this License (e.g. Attribution-ShareAlike 2.0 Japan)). and consciously decided to reject this possibility.

P.S. It'll be interesting to hear outcry from Creative Commons users when these licenses will alter it's bargain enough—this should be even bigger fiasco then GPLv2-to-GPLv3 transition because with GPLv2 you at least have Linus's option of rejecting said transition. No such luck with Creative Commons.

There is a LOT of rubbish in the comments on this article, and it's pretty much all down to the fact that far too many people don't actually understand how copyright works.

Well, sure. The fact that people actually distribute anything under Creative Commons and never even discuss the fact that by doing so they give complete power over their creations to some random guys over there but discuss GPLv2-to-GPLv3 transition to the death is large enough clue. Remember how FSF unilaterally shifted the whole Wikipedia without asking it's authors about anything to CC-BY-SA 3.0? Well, folks behind Creative Commons can easily do similar trick to the whole corpus of the Creative Commons-licensed art.

Toward healthy paranoia

khim — Thu, 19 Sep 2013 20:02:39 +0000

But to anyone who bothers to understand RMS, it's pretty clear the FSF is not altering the bargain. GPLv3 is pretty much ALL BUGFIXES.

You are preaching to a choir here. Yes, that's what I said seven years ago. Sure, for RMS it's just a bugfix since he clearly considers GPLv2 weapon in the fight for the software freedom and clearly stated: Change is unlikely to cease once GPLv3 is released. If new threats to users' freedom develop, we will have to develop GPL version 4..

But I also said back then that it's dangerous ground to play with—exactly because others perceived (and still perceive!) GPLv2 differently. In effect switch from GPLv2 to GPLv3 folks highlighted difference between “Free Software” and “Open Source” folks. For “Free Software” camp it was just a bunch of bugfixes but for “Open Source” folks it was fundamental change of the status quo. As Linus put it: To me, the GPL really boils down to “I give out code, I want you to do the same.” The thing that makes me not want to use the GPLv3 in its current form is that it really tries to move more toward the “software freedom” goals.

Stallman expected to see that people will embrace “Free Software” and go with GPLv3 but most embraced “Open Source” and rejected it. Linus rejected it outright, some others guys did that later (for example GnuTLS parted way with FSF and went back to GPLv2).

In effect FSF showed us that RMS is right once again and that most “Open Source” folks are not ready to join Church of Emacs—Saint IGNUcius.

Okay, we may disagree, but the anti-Tivoisation clause simply prevents the manufacturer reserving to themself the right to update the software.

Sure, but FOSS is increasingly used in places where such lock-down is expected and sometimes needed (==mandated by law). Mobile phones are locked because carriers want to sell simple thing like tethering support for $$, car software is locked because there are fear that someone will alter it and car manufacturers will be declared responsible for death of people despite all these NO WARRANTY claims and so on. Apple just wants to control both software and hardware on the devices it sells. For all of them new, altered bargain is totally unacceptable.

Another bugfix for a bug I didn't even realise existed - if you put a GPLv2'd BINARY on your website, then even if you put the source right next to it you trigger the "make the source available for three years" clause. You have to FORCE people to download the source.

Why? GPLv2 clearly gives you another choice: Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. In today's world web is a medium customarily used for software interchange and it's pretty clear that if source and binary are near each other on the same server one accompanies the other. It's the same as when you offer Debian DVD with binaries and Debian DVD with sources—it's clearly up to recipient do decide if s/he wants to grab second DVD as well, you are not required to see if s/he'll actually take it with him or her.

GPLv3 clarifies things like use of torrents for the software distribution, and makes it clear that you are not losing your right if you fix accidental violations fast enough, that's true, but these minor improvements are overshadowed by much, much larger of changes in other places.

Toward healthy paranoia

Wol — Thu, 19 Sep 2013 17:26:17 +0000

The idea that you can just omit “or any later version” and thus make sure new ideas of GPLv3 will not affect you was Linus' inventions, not FSF's one—and others were not so enlightened.

Actually, the GPL (v2 or otherwise) ITSELF discusses NONE of this. There is a load of blurb - which is not part of the GPL itself - which discusses this.

There is a LOT of rubbish in the comments on this article, and it's pretty much all down to the fact that far too many people don't actually understand how copyright works.

Cheers,
Wol

Toward healthy paranoia

Wol — Thu, 19 Sep 2013 17:18:21 +0000

because said change felt as “I am altering the bargain, pray I don't alter it any further”-style change.

But to anyone who bothers to understand RMS, it's pretty clear the FSF is not altering the bargain. GPLv3 is pretty much ALL BUGFIXES.

Okay, we may disagree, but the anti-Tivoisation clause simply prevents the manufacturer reserving to themself the right to update the software. If it's in ROM (or PROM) and can't be updated, that's fine.

Another bugfix for a bug I didn't even realise existed - if you put a GPLv2'd BINARY on your website, then even if you put the source right next to it you trigger the "make the source available for three years" clause. You have to FORCE people to download the source. v3 now means if they don't get the source at the same time, they have no right to come back later

The rest of it is in the same vein.

Cheers,
Wol

Toward healthy paranoia

glaesera — Wed, 18 Sep 2013 13:08:54 +0000

Security by obscurity will obviously not work.
A bug is a bug, I want to agree to this, but any open-source hobby programmer would not say 'I put that bug there deliberately', when it has been found, like the NSA did.
If they really spend million-Dollar amounts of money to weaken cryptography technologies, which I don't believe, then the whole organisation should be completely abolished, because then they would be producing insecurity instead of security.
For everyone who has a healthy sense of paranoia already, I recommend this:
https://www.eff.org/https-everywhere
https://www.eff.org/https-everywhere/faq

Toward healthy paranoia

hummassa — Wed, 18 Sep 2013 00:14:39 +0000

recent-model tivos with modified kernels?

Toward healthy paranoia

khim — Tue, 17 Sep 2013 23:59:06 +0000

Mea culpa. Indeed, it looks like GnuTLS dropped it's FSF ties and, indeed, went to LGPLv2.1 (although that particular change was not advertised at all and is not even mentioned in NEWS file and thus I missed it).

Makes it even more strange that it's not mentioned in this article when half-dead Selene is mentioned.

Toward healthy paranoia

dlang — Tue, 17 Sep 2013 19:13:25 +0000

hmm, I've been running modified tivos for over a decade now

NSA inserting weaknesses into standards

giraffedata — Tue, 17 Sep 2013 15:57:09 +0000

When you make standard 256 times weaker then it could be otherwise it's not “inserting weaknesses”?

That would be, but NSA did not make the standard anything.

"Make" or "insert" is highly misleading terminology when you're talking about influence this small. My government makes me pay taxes; my insurance agent doesn't make me buy life insurance. I insert a post in my blog; I don't insert a story about me in LWN by sending a press release.

IBM never agreed and never claimed 56 bits are better than 64

Yes, IBM did. You're taking too narrow a view of "better" that just means harder to crack. There are costs associated with longer keys, and IBM had to consider them all. IBM found that the added security did not justify the cost of the extra 8 bits. My understanding of the story is that what NSA convinced IBM of between IBM's initial and final proposal was how hard 56 bits was to crack, and that changed the balance in IBM's opinion.

Toward healthy paranoia

hummassa — Tue, 17 Sep 2013 12:39:13 +0000

I am a strong defender of many things Torvalds, but, yes, he is harshly anti-RMS, albeit one of the most rational ones.

For instance, Linus says that the GPL and the LGPL are more or less the same, because linking does not make a derivative work, and AFAICT he is absolutely right.

OTOH, the "tivoization" stance was a pragmatic one -- Tivo was one of the first all-out many-consumers device and the use of locking bootloaders killed the possibly thriving modifications market. So, while Linus was right (because Tivo could, at any moment, choose to go with some BSD or even with XNU) he was also anti-RMS and anti-software-freedom.

One can be "I don't like RMS" for pragmatic reasons. It does not make it good for software freedom. Apple does not like RMS because Apple likes to maintain control, and RMS/FSF/GNU/GPL is all about relinquishing control downstream AND guaranteeing that control would stay downstream.

Toward healthy paranoia

renox — Tue, 17 Sep 2013 09:26:07 +0000

>Every single anti-GPL (v3, v2 or whatever) argument I have seen (here or outside) is possible to be distilled to "I don't like RMS". It was so twenty years ago, ten years ago, and it still is nowadays.

Apparently, you didn't look very thoroughly.. The 'anti-tivoization' clause of the GPLv3 is quite controversial, for example Linus Torvalds doesn't like it, would you claim that he "doesn't like RMS"?

Toward healthy paranoia

hummassa — Mon, 16 Sep 2013 17:15:07 +0000

Every single anti-GPL (v3, v2 or whatever) argument I have seen (here or outside) is possible to be distilled to "I don't like RMS". It was so twenty years ago, ten years ago, and it still is nowadays.

I suspect (and I have probably mentioned this before) that we'll see a real GPL comeback (v3 and all or even v4, if needed) some years from now, once the NSA-like surveillance take an unbearable toll on the economy or on the social structures. We'll see.

Toward healthy paranoia

nix — Mon, 16 Sep 2013 15:53:11 +0000

But this will need to be different, non-FSF-driven copyleft.

Ah, I love the smell of argument-by-assertion in the morning.

Toward healthy paranoia

nix — Mon, 16 Sep 2013 15:50:01 +0000

libgnutls has been back under LGPLv2.1 since v3.1.10, released Mar 22 2013. Please pay attention before criticizing.

NSA inserting weaknesses into standards

khim — Mon, 16 Sep 2013 00:07:50 +0000

If the NSA activity we're talking about is anything like what is described in the Wikipedia article on DES, then "has inserted weaknesses" is entirely inappropriate wording.

Really? When you make standard 256 times weaker then it could be otherwise it's not “inserting weaknesses”? How do you call said process?

Note that in story with DES quite visible change made standard weaker and opaque change didn't but it does not change the principal position: standard was changed at the NSA request and nobody outside NSA had any idea for why said request was made in the first place.

The other was to reduce the key length from 64 bits to 48. IBM rejected that.

Right. 48 bits instead of 64 means it's 65536 times easier to crack.

NSA then proposed 54 bits and IBM found that to be better than 64 and accepted it.

NSA, of course, proposed 56 bits, not 54 and, more importantly, IBM never agreed and never claimed 56 bits are better than 64—that's an absurd claim. Of course 56 bits cypher are weaker then 64 bits. 256 times (if there are no other substantial differences). But IBM decided that it's better to accept 56bit compromise rather then try to insist on 64bits and see their proposal thrown out.

The article doesn't tell the process by which ANSI and ISO adopted it, but I see no evidence that NSA was involved.

Why would NSA involved? The deed was done much earlier—when 64bits were replaced with “good enough” 56bits and S-boxes were altered. It does not look like S-boxes changes were nefarious (we still don't really know), but problem with change from 64bits to 56bits is self-evident to anyone who knows how cryptography works.

NSA inserting weaknesses into standards

giraffedata — Sun, 15 Sep 2013 19:20:55 +0000

There is, for example, some evidence that the NSA has inserted weaknesses into some random-number generation standards, ...
No, I meant how does the NSA insert something into a standard?
The same way it always did. [Wikipedia article on DES]

If the NSA activity we're talking about is anything like what is described in the Wikipedia article on DES, then "has inserted weaknesses" is entirely inappropriate wording. The NSA's involvement in DES, according to the article was:

The US government wanted to establish a standard for encrypting US government data. It sought proposals, via the National Bureau of Standards, from the public and consulted with NSA to evaluate them. IBM submitted a proposal and consulted with the NSA in developing it. NSA suggested two changes to IBM's initial proposal. One was a reworking of the "s-tables," which IBM's encryption experts analyzed and found to be good and accepted. The other was to reduce the key length from 64 bits to 48. IBM rejected that. NSA then proposed 54 bits and IBM found that to be better than 64 and accepted it. IBM made the resulting proposal to NBS and NBS accepted the proposal as a standard for encrypting US government data. Some time later, public standards bodies including ANSI and ISO adopted the same standard. The article doesn't tell the process by which ANSI and ISO adopted it, but I see no evidence that NSA was involved.

Toward healthy paranoia

mpr22 — Sun, 15 Sep 2013 11:05:23 +0000

"Hit by a bus" is not a problem. Either they're still legally competent afterwards, in which case they can reinstate the license; they're dead, in which case their heirs are legally competent to reinstate the license; or they're alive but no longer legally competent, in which case whoever the law has authorized to act on their behalf is legally competent to reinstate the license.

More awkward is where they've divested themselves of their electronic devices and moved to, say, Mongolia or Nunavut.

NSA inserting weaknesses into standards

khim — Sat, 14 Sep 2013 17:15:39 +0000

No, I meant how does the NSA insert something into a standard?

The same way it always did.

Are we talking about ordinary public standards?

Yup. Note that more then quater-century ago NSA involvement made DES stronger, not weaker (although with shorter key size which, as you can guess, is a weakness, but it can hardly be named “hidden weakness”).

NSA inserting weaknesses into standards

giraffedata — Sat, 14 Sep 2013 16:35:15 +0000

No, I meant how does the NSA insert something into a standard?

Are we talking about ordinary public standards?

Toward healthy paranoia

dd9jn — Sat, 14 Sep 2013 12:49:19 +0000

Actually the GPLV3 makes the legal situation for companies safer. An (accidental) license violation won't anymore permanently terminate their right to distribute the work. Instead the self-healing clause from section 8 helps them to get back in compliance. Imaging one of the copyright older of a GPLv2 licensed work was hit by a bus and thus not anymore able to re-instate their rights to distribute the work after they have fixed the compliance problem. I feel much safer with the GPLv3 for that reason - those who plan to trick their users out obviously disagree.

Toward healthy paranoia

juliank — Fri, 13 Sep 2013 19:20:29 +0000

My biggest issue with GPL3 is that it allows relicensing to AGPL-3. So, people can just take my code and decide to give it to others (or back to me) under more restrictive terms. I don't like that.

A reason for choosing GPL2 was that if I license stuff under GPL, everybody else must distribute it under that license, and cannot add further restrictions and thus prevent me from incorporating their changes.

Toward healthy paranoia

hummassa — Fri, 13 Sep 2013 18:36:37 +0000

> Huh? The GPLv2 actually only discusses two possibilities:

Actually, the section 9 of the GPLv2 is discussing two alternatives to the (obvious, IMNSHO) option where you are accepting the terms of the license you are reading in the moment you make copies of a GPLd work. Section 14 of the GPLv3 discusses the same two alternatives.

The forementioned sections are in the line of:

* these are the terms of this license; but if someone licenses the work as "GPLvX or later", it means that you have the option (not the obligation) of taking it under the term of later GPL's; and if someone licenses some work as "GPL", it means that you have the option (again, not any obligation) of taking it under the term of any version of the GPL that you care for.

Toward healthy paranoia

khim — Fri, 13 Sep 2013 15:46:15 +0000

Nobody makes people use GPLvX _or later_, which is required for your argument to make any sense.

Huh? The GPLv2 actually only discusses two possibilities:
1. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.
2. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

The idea that you can just omit “or any later version” and thus make sure new ideas of GPLv3 will not affect you was Linus' inventions, not FSF's one—and others were not so enlightened.

Anti-GPLv3 started at the end of distribution tree: vendors revolted and only after that happened developers decided that they will forget about it since GPL is no longer acceptable. But by now a lot of developers see the writing on the wall: if you want to create code which will be used by real people to solve real problems - you should not pick the GPLv3. Some old projects get away with relicensing because they are important enough (think Samba), but how many popular GPLv3-licensed projects can you name which gained popularity as GPLv3 project and not as project which first gained popularity as GPLv2 project and then changed the bargain.

Of course first case of "altered bargain" was AGPL, not GPLv3 but there situation was different: some projects adopted it, most ignored it, but there was no bargain alteration, few projects (if any) went from GPLv2 to AGPLv1.

If you are happy with GPLv2 then use that, if you are OK with GPLv3 then use that.

What if you relied on “no further restrictions” clause and hoped to receive similar terms for newer versions of software which is now only available under GPLv3 license (this is what happened with GCC and Samba)? Should you wait till GLibC will be relicensed under GPLv3 and then start to suddenly look for a replacement or should you just abandon it and go with something like Bionic?

You are quite right that big corps don't like GPLv3, but in my experience that's almost entirely due to patent-paranoia, rather than anything to do with potential changes in new licences.

Well, may be, but it's the same case in the end: bargain was altered and both people who don't like new bargain and people who don't want to deal with next unexpected change in the bargain are revolting.

Trusting Trust

Baylink — Fri, 13 Sep 2013 15:32:11 +0000

I see no one's mentioned Ken Thompson's paper "Reflections on Trusting Trust", which seems on-point here to me. I will link to a Schneier piece which mentions a way to attack the attack Thompson posits -- an attack which he confirmed to me in email many years ago *was* implemented, but never got outside BTL, as far as anyone knows:

https://www.schneier.com/blog/archives/2006/01/countering...

Toward healthy paranoia

wookey — Fri, 13 Sep 2013 15:08:39 +0000

Nobody makes people use GPLvX _or later_, which is required for your argument to make any sense. If you are happy with GPLv2 then use that, if you are OK with GPLv3 then use that. If you are happy with 'whatever the FSF says this decade' then choose 'or later'.

You are quite right that big corps don't like GPLv3, but in my experience that's almost entirely due to patent-paranoia, rather than anything to do with potential changes in new licences. Because GPLv3 is a lot clearer about the fact that they really do have to agree not to assert patent claims on 'anything derived from this' than v2 was. So this problem is actually a side-effect of the whole software-patent disaster rather than much do with changes trying to retain practical user freedoms.

The growing realisation that you can't trust _any_ code you (or someone) can't examine, rebuild and replace, especially if it came from the US, could make a real difference, and shift things back towards copyleft. We shall see. I'd like to think so, but then I already thought copyleft mattered.

Toward healthy paranoia

khim — Fri, 13 Sep 2013 15:02:19 +0000

The solution is GPLv3/LGPLv3 to give right to users to fix the software running on their hardware.

That's solution of totally different problem. People who know or care about GPLv3/LGPLv3 are such a tiny minority that they can be easily ignored. And they don't need any protection anyway (since they agree to lose the protection offered by vendor right from the start). The other 97% of users must be protected somehow and GPLv3 does not help there, in fact it makes situation worse.

Think about it: there are many errors in FOSS and elsewhere but the most security problematic part of the computer is still usually resides between chair and keyboard - and GPLv3/LGPLv3 makes this problem more acute, not less.

Or how we (as citizen, a nation, etc.) ensure that vendor, OEM, ODM, manufacturers must meet security criteria throughout the life cycle of a device: it's political matters, some pressure has to be put on the providers to keep devices safe.

This should (and probably would) be done by making sure vendor, OEM, ODM, manufacturers are not shirking liability. Note that all licenses try to disclaim liability but they still are limited by law: if law says vendor must do something it must do something even if license says something different.

Of course this will mean that vendors will want to lockdown the device to reduce attack surface and GPLv3/LGPLv3 is incompatible with that.

What matter is how one can address the current shortcomings / vulnerabilities, how one can fixed them, how one can deploy a fixed version.

OTA updates were invented long ago. Windows Update was launched 18 years ago and Linux distributions have offered the same service for about the same time.

GPLv3 / LGPLv3 GnuTLS would allow users to do this, while BSD OpenSSL don't.

Yup. GPLv3/LGPLv3 make life better for 2-3% of geeks and worse for everyone else. Why do you think vendors should pick this nonsolution for nonproblem?

A few ideas

cesarb — Fri, 13 Sep 2013 14:40:51 +0000

A few ideas on things that can be done to help the situation:

1. More emphasis on repeatable builds (https://lwn.net/Articles/555761/, https://lwn.net/Articles/564263/).

If building a package from its source code is repeatable, several independent services located in separate countries and with different owners could recompile each package from the source code, and publish a signed list of with the checksum of the resulting packages.

When installing a package, the package manager could then download the list of the checksums of all the distribution's packages from several of these services. Any mismatch with the checksum of the downloaded package would be cause for suspicion, and the downloaded package would be quarantined for later examination by security researchers.

This would give a strong assurance that the package has been compiled from the published source code, and has not been tampered after being compiled. The end user would not have the overhead of recompiling everything just to check if it has not been tampered. And since anyone could be running one of these services in private, even if all public services are compromised at the same time, it could be detected.

The same would also need to be done with the installation media; its build should also be repeatable and also be verified by that kind of service.

2. More static checking.

The ideal would be to be able to use automated provers (see for instance http://www.dwheeler.com/formal_methods/) to prove the absence of whole classes of defects in the source code. This is a hard problem; however, even weaker tools could help.

For instance, imagine how useful would it be to be able to add a notation (even if it is in a separate tool-specific file) saying "this field of this struct must be protected by this spinlock in the same struct, unless the struct has just been allocated and thus there are no other references to the struct" (or even more complicated conditions), and have the tool automatically verify it for you, after every change you make. Even if the tool did nothing else, it would still be useful.

That is only one example; there are many other possibilities. There can be several tools focusing on different classes of defect. And even small things like -Werror can help.

This is one area where free software can shine. Since the source code is available for everyone to study, anyone can develop static checking approaches for it, without waiting for the original maintainers (especially if the tool allows any annotations it needs to be placed in separate files).

Toward healthy paranoia

danieldk — Fri, 13 Sep 2013 14:13:43 +0000

> XNU was "open source" until OSX 10.3? 10.4?

Not that it matters much to the discussion, XNU is still open source:

http://www.opensource.apple.com/release/mac-os-x-1084/

> individuals who choose "liberal licensing" are helping big companies to plot the end of privacy

The world is not black and white. There are plenty of companies (big and small) who produce proprietary software, like liberal licensing for that reason, but are not plotting 'the end of privacy'.

And personally, I don't care if someone uses my code in a proprietary product, as long as credit is given where credit is due. I do mind if they'd use it for sharks with lasers, but it's pretty hard (and non-FLOSS) to craft a license to prevent uses that I consider immoral.

Toward healthy paranoia

anselm — Fri, 13 Sep 2013 13:17:05 +0000

Say what you will about the intentions for fixing vulnerabilities in the proprietary world. I find it to be the same for the Linux kernel really.

I agree that the Linux kernel development community could do a lot to improve their handling of security issues. That does not detract from the observation that most FOSS projects are much more open about security than most proprietary vendors. The Apache web server project, for example, seems to do a decent job of dealing with security issues and their fixes.

What's undeniable though is the dramatic change Microsoft has made in their development processes […]

Microsoft may be better than they used to be but they often still need extensive prodding before acknowledging, let alone fixing, security issues. In many cases it requires an active exploit out in the wild to get most vendors to do anything, mostly because the act of having to publish patches at all means bad PR (for having been vulnerable in the first place). It is also difficult to get customers to install the patches, and there is a chance of introducing new bugs when patching existing ones, which is why after-market upgrades are often viewed as a bad idea, and are restricted to the most egregious problems. For a vendor it often pays to sit on problems that are not being actively exploited, where in the FOSS community (with the possible exception of some projects like the Linux kernel) proactive fixing of even theoretical security issues is generally welcomed.