4 ms·

No, the new libraries aren't closed source. Google recreated the libraries under a properly liberal open source license without a software-and-hardware patent g

No, the new libraries aren't closed source. Google recreated the libraries under a properly liberal open source license without a software-and-hardware patent grab (or a ban on tivoization for security purposes) that other can use, and have used. Another massive chunk of GPL enters history, except as legacy cruft. Waste, but we finally end up with a non-perverse open source license. Your argument seems to be that anything that makes phones more expensive is wonderful, so go economic waste! Because something as unholy as a corporation is involved. A passive version of The Unabomber's creed, I suppose.

flukus 10y ago
> No, the new libraries aren't closed source. Not yet, but they're permissive enough that google can close source them any time they wish. And when that happens there will be a lot of crying about google doing something they are specifically allowed to do.
- Nomentatus 10y ago
  No, they can't take them back. BSD and MIT aren't revokable. Anyone can fork them, but the BSD code remains available.
  - flukus 10y ago
    And because android is tied to google a fork would work and the current android would fall farther behind, it's already a fork of linux, just an OSS one.
  - dragonwriter 10y ago
    As I understand it, in US law any gratuitous license is revocable at will; terms of a written license that purport otherwise may (or may not), depending on the specific circumstances of use after revocation, impact the effect of revocation under the doctrine of promissory estoppel, but that's not the same as the license actually being irrevocable. Of course, while there are conflicting theories about whether the GPL is gratuitous or not (and this may actually vary from case to case—if you buy software that comes with GPL terms, it is clearly not gratuitous), this potentially affects the GPL as much as any permissive license.
    - Nomentatus 10y ago
      You may be assuming that no consideration is given (consideration being necessary to create a legal contract) - but in general charities and public goods are the exception to this; the public good done is assumed to be consideration according to law. Therefore, for example, pledges to charities are regarded as valid contracts that can be enforced.
  - X86BSD 10y ago
    This is a common fallacy GPL enthusiasts often spew. You can't make BSDL code disappear all you can do is fork it and add or modify to your copy of it. The original is still there.
pksadiq 10y ago
> ...(or a ban on tivoization for security purposes)... It is okay for some vendor to lock a hardware by default with GNU GPLv3 software in it. The rule is that it shouldn't be a permanent lock. The user should be allowed to break the lock if he/she wishes (of course the vendor can say that it will void warranty). This is what it happens when a user roots his/her android phone. So not using GNU GPL by Google has not much to do with tivoization if rooting of a phone is allowed, and if the user is allowed to change the software inside. Note: For things like bombs, nuclear reactors, medical equipments, voting machines, etc. It is allowed to have a permanent lock even if the software inside is licensed under the terms of GNU GPLv3+.
- deleted 10y ago
  [deleted]
- dragonwriter 10y ago
  > Note: For things like bombs, nuclear reactors, medical equipments, voting machines, etc. It is allowed to have a permanent lock even if the software inside is licensed under the terms of GNU GPLv3+. Not quite; e.g., Medical equipment designed to be installed in a home cannot be permanently locked under the GPLv3.
- Nomentatus 10y ago
  The Android phone doesn't have the GPL 3 tivoization clause to worry about - that's no doubt at least part of the reason why Google chose the immense expense of rewriting and replacing the whole GNU 'Nix libraries. The Linux kernel is GPL 2, no tivoization clause.
- Nomentatus 10y ago
  The point re tivoizing for security (as opposed to protecting copyprotection schemes, say) that I have in mind is as a measure to ensure that the operating system isn't replaced or modified by a user who isn't the owner (particularly, without the owner's knowledge - the owner may be a corporation that wants to prevent one planted employee from pwning all their servers, for example); or modified by apps authorized by the user inadvertently or without full knowledge. The GPL 3 license isn't designed to allow such fine distinctions; and there's probably no practical way for it to do so - sometimes you want to employee-and-visitor-proof things. Maybe tivoization with a password (which the corporation could deep six to truly prevent pwnage?) Their explanations "The usual motive for tivoization is that the software has features the manufacturer knows people will want to change, and aims to stop people from changing them." suggest they wouldn't welcome this solution either, but I'd be interested to know otherwise. The more I look at the license https://www.gnu.org/licenses/gpl-3.0.txt https://www.gnu.org/licenses/gpl-3.0.txt the more discouraged I get - it covers user products (consumer, household use) and as part of a building (???) and that's it! Never gets near making room for the security cases that worry me most. In fact this language: "For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product." pretty much rules out allowing tivoization for my security cases. The only obvious way to read "regardless of the status of the particular user" would mean that employees would have to have the ability to modify the product without the company's knowledge, which is precisely what I'd like to be able to prevent of course.

flukus 10y ago

> No, the new libraries aren't closed source. Not yet, but they're permissive enough that google can close source them any time they wish. And when that happens there will be a lot of crying about google doing something they are specifically allowed to do.

Nomentatus 10y ago
No, they can't take them back. BSD and MIT aren't revokable. Anyone can fork them, but the BSD code remains available.
- flukus 10y ago
  And because android is tied to google a fork would work and the current android would fall farther behind, it's already a fork of linux, just an OSS one.
- dragonwriter 10y ago
  As I understand it, in US law any gratuitous license is revocable at will; terms of a written license that purport otherwise may (or may not), depending on the specific circumstances of use after revocation, impact the effect of revocation under the doctrine of promissory estoppel, but that's not the same as the license actually being irrevocable. Of course, while there are conflicting theories about whether the GPL is gratuitous or not (and this may actually vary from case to case—if you buy software that comes with GPL terms, it is clearly not gratuitous), this potentially affects the GPL as much as any permissive license.
  - Nomentatus 10y ago
    You may be assuming that no consideration is given (consideration being necessary to create a legal contract) - but in general charities and public goods are the exception to this; the public good done is assumed to be consideration according to law. Therefore, for example, pledges to charities are regarded as valid contracts that can be enforced.
- X86BSD 10y ago
  This is a common fallacy GPL enthusiasts often spew. You can't make BSDL code disappear all you can do is fork it and add or modify to your copy of it. The original is still there.

pksadiq 10y ago

> ...(or a ban on tivoization for security purposes)... It is okay for some vendor to lock a hardware by default with GNU GPLv3 software in it. The rule is that it shouldn't be a permanent lock. The user should be allowed to break the lock if he/she wishes (of course the vendor can say that it will void warranty). This is what it happens when a user roots his/her android phone. So not using GNU GPL by Google has not much to do with tivoization if rooting of a phone is allowed, and if the user is allowed to change the software inside. Note: For things like bombs, nuclear reactors, medical equipments, voting machines, etc. It is allowed to have a permanent lock even if the software inside is licensed under the terms of GNU GPLv3+.

deleted 10y ago
[deleted]
dragonwriter 10y ago
> Note: For things like bombs, nuclear reactors, medical equipments, voting machines, etc. It is allowed to have a permanent lock even if the software inside is licensed under the terms of GNU GPLv3+. Not quite; e.g., Medical equipment designed to be installed in a home cannot be permanently locked under the GPLv3.
Nomentatus 10y ago
The Android phone doesn't have the GPL 3 tivoization clause to worry about - that's no doubt at least part of the reason why Google chose the immense expense of rewriting and replacing the whole GNU 'Nix libraries. The Linux kernel is GPL 2, no tivoization clause.
Nomentatus 10y ago
The point re tivoizing for security (as opposed to protecting copyprotection schemes, say) that I have in mind is as a measure to ensure that the operating system isn't replaced or modified by a user who isn't the owner (particularly, without the owner's knowledge - the owner may be a corporation that wants to prevent one planted employee from pwning all their servers, for example); or modified by apps authorized by the user inadvertently or without full knowledge. The GPL 3 license isn't designed to allow such fine distinctions; and there's probably no practical way for it to do so - sometimes you want to employee-and-visitor-proof things. Maybe tivoization with a password (which the corporation could deep six to truly prevent pwnage?) Their explanations "The usual motive for tivoization is that the software has features the manufacturer knows people will want to change, and aims to stop people from changing them." suggest they wouldn't welcome this solution either, but I'd be interested to know otherwise. The more I look at the license https://www.gnu.org/licenses/gpl-3.0.txt https://www.gnu.org/licenses/gpl-3.0.txt the more discouraged I get - it covers user products (consumer, household use) and as part of a building (???) and that's it! Never gets near making room for the security cases that worry me most. In fact this language: "For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product." pretty much rules out allowing tivoization for my security cases. The only obvious way to read "regardless of the status of the particular user" would mean that employees would have to have the ability to modify the product without the company's knowledge, which is precisely what I'd like to be able to prevent of course.