Slashdot Mirror

Not only that, but we've already had the debate on interfaces/APIs and GPL.

http://clisp.cvs.sourceforge.n...

And FSF had specifically supported Google in this case.

https://www.fsf.org/blogs/lice...

Oracle is just continuing their long-standing trend of treating both customers and developers as idiots. The only appropriate response is to flip the bird.

They blog post they made references http://piwik.fsf.org/piwik.js which is minified

A comment at the top of the minified file links to the source file:

@source https://piwik.fsf.org/js/piwik.js

The problem they're complaining about is

When minified, the code can hide all sorts of nasty items, like spyware and other security risks

They blog post they made references http://piwik.fsf.org/piwik.js which is minified. Just because it's got a BSD license clause in the file doesn't mean it's not hiding "all sorts of nasty items".

JavaScript is not the problem; proprietary JavaScript is. The JavaScript fragment in the cited document is distributed under GPLv3, a free software license. It loads Piwik, which is distributed under a 3-clause BSD license, which is also a free software license.

Unrelated to the topic at hand, but they say it's "A laptop that respects your rights" then turn around and have an Intel CPU.
I notice the CPU is missing from the picture shown below "Every hardware chip individually selected", and no mention if they've somehow disabled AMT or whatever the replacement is.

Get with the times and use oauth2 services (google/facebook/twitter/whatever).

This leads to one of three problems.

The below is from me originally from 2001: http://www.pdfernhout.net/on-f...

Although see also this idea from a couple of weeks ago: http://www.pdfernhout.net/pled...
====
Consider again the self-driving cars mentioned earlier which now cruise some streets in small numbers. The software "intelligence" doing the driving was primarily developed by public money given to universities, which generally own the copyrights and patents as the contractors. Obviously there are related scientific publications, but in practice these fail to do justice to the complexity of such systems. The truest physical representation of the knowledge learned by such work is the codebase plus email discussions of it (plus what developers carry in their heads).

We are about to see the emergence of companies licensing that publicly funded software and selling modified versions of such software as proprietary products. There will eventually be hundreds or thousands of paid automotive software engineers working on such software no matter how it is funded, because there will be great value in having such self-driving vehicles given the result of America's horrendous urban planning policies leaving the car as generally the most efficient means of transport in the suburb. The question is, will the results of the work be open for inspection and contribution by the public? Essentially, will those engineers and their employers be "owners" of the software, or will they instead be "stewards" of a larger free and open community development process?

Open source software is typically eventually of much higher quality ( http://www.fsf.org/software/re... ) and reliability because more eyes look over the code for problems and more voices contribute to adding innovative solutions. About 35,000 Americans are killed every year in driving fatalities, and hundreds of thousands more are seriously injured. Should the software that keeps people safe on roads, and which has already been created primarily with public funds, not also be kept under continuous public scrutiny?

Without concerted action, such software will likely be kept proprietary because that will be more profitable sooner to the people who get in early, and will fit into conventional expectations of business as usual. It will likely end up being available for inspection and testing at best to a few government employees under non-disclosure agreements. We are talking about an entire publicly funded infrastructure about to disappear from the public radar screen. There is something deeply wrong here.

And while it is true many planes like the 757 can fly themselves already for most of their journey, and their software is probably mostly proprietary, the software involved in driving is potentially far more complex as it requires visual recognition of cues in a more complex environment full of many more unpredictable agents operating on much faster timescales. Also, automotive intelligence will touch all of our lives on a daily basis, where as aircraft intelligence can be generally avoided in daily life.

Decisions on how this public intellectual property related to automotive intelligence will be handled will affect the health and safety of every American and later everyone in any developed country. Either way, the automotive software engineers and their employers will do well financially (for example, one might still buy a Volvo because their software engineers are better and they do more thorough testing of configurations). But which way will the public be better off:
* totally dependent on proprietary intelligences under the hoods of their cars which they have no way of understanding, or instead
* with ways to verify what those intelligences do, understand how they operate, and make

It's here, linked from the footer of the page.

I'm not sure there's any method to guarantee that the source they linked is the same as the source they're running, but given that it's AGPL (and thus doing otherwise would be illegal), it seems highly likely that the FSF is in compliance; they seem like one of the least likely organizations to commit a GPL violation.

Google gplv3 "user product" brought me the article "GPLv3, User Products Clause" by Allison Randal, which links to the GPLv3 rationale document (PDF). However, the explanation to which Randal's article refers is in rationale for draft 3 (PDF), not rationale for draft 4 (PDF), to which the link to the rationale currently redirects. For convenience, I quote the relevant excerpt from the rationale for draft 3 here:

In our discussions with companies and governments that use specialized
or enterprise-level computer facilities, we found that sometimes these or-
ganizations actually want their systems not to be under their own control.
Rather than agreeing to this as a concession, or bowing to pressure, they
ask for this as a preference. It is not clear that we need to interfere, and the
main problem lies elsewhere.

While imposing technical barriers to modification is wrong regardless of
circumstances, the areas where restricted devices are of the greatest practical
concern today fall within the User Product definition. Most, if not all,
technically-restricted devices running GPL-covered programs are consumer
electronics devices, and we expect that to remain true in the near future.
Moreover, the disparity in clout between the manufacturers and these users
makes it difficult for the users to reject technical restrictions through their
weak and unorganized market power. Even if limited to User Products, as
defined in Draft 3, the provision still does the job that needs to be done.
Therefore we have decided to limit the technical restrictions provisions to
User Products in this draft.

And it's not a restriction on a particular field of use; it's a requirement for distribution in a particular form, namely preinstallation in a device. It's not much different from the requirement in GPLv2 to provide "scripts used to control compilation and installation" (my emphasis).

Twitter doesn't have a real name policy, just a policy not to mislead. Twitter has one-way following, as opposed to mutual friendship. And somehow the FSF feels a lot more comfortable with Twitter than with Facebook.

Twitter doesn't have a real name policy, just a policy not to mislead. Twitter has one-way following, as opposed to mutual friendship. And somehow the FSF feels a lot more comfortable with Twitter than with Facebook.

It seems there is not even one ARM or Intel single-board computer that respects your freedom.

https://www.fsf.org/resources/...

Please prove this wrong.

I think the idea is to put your microblog on Pump or GNU Social and mirror that to Twitter. It's what @fsf does.

For some reason I get very nervous with an out of band remote proprietary management system baked into recent Intel chips, which operates below the OS, and has not been independently audited and reviewed by trusted 3rd parties (such as those not associated with mass surveillance).
https://en.wikipedia.org/wiki/...

Note that AMT is also in all Intel chips with vPro:
https://en.wikipedia.org/wiki/...

This posting from the FSF (Free Software Foundation) has a decent writeup about it:
https://fsf.org/blogs/communit...

It seems that we are now in the age of hardware backdoors.

Maybe AMD which cannot seem to compete with Intel on performance and low-power, can make a niche for itself as a secure (backdoorless) alternative.

These days, I would value my privacy over performance.

virtually ALL mobile devices using UEFI-SecureBoot WITH NO option to support legacy BIOS

Secure Boot is a UEFI feature that requires bootloaders to be digitally signed with a certificate stored in the PC's firmware. But there are two ways to implement it: normal or forced. With normal Secure Boot, the owner of a PC can replace the certificate or turn off the feature entirely. Forced Secure Boot, sometimes called Restricted Boot, cannot be disabled, much as in iOS devices and major video game consoles. In the Windows 8 (x86 and x86-64) era, Microsoft required normal Secure Boot for logo certification; it forbade Restricted Boot. As of Windows 10 (x86 and x86-64), Microsoft has changed the policy to allow either normal or forced Secure Boot. In theory, PC buyers could just avoid PCs with Restricted Boot, so long as they don't greatly outnumber PCs with normal Secure Boot. Have x86-64 PC manufacturers actually started to implement Restricted Boot widely?

This is the greatest thing to happen to the libre firmware movement.

Maybe now, people will be more wary of the ever more complex, proprietary software being run without their knowledge by the low-level systems in their devices. Go read about the Intel Management Engine and the associated Active Management Technology for starters! It will make your skin crawl...

The governments of the world are making a lot of futile noise about the dangers of encryption, but only to distract from the fact that the real backdoors have already been designed and are becoming widely deployed.

CAPTCHA: alarmist

Transceivers are often hooked directly into sensors such as microphones, and run very complex proprietary firmware that is given undue privileged access to the rest of the system's resources.

Furthermore, for nearly 15 years, Intel as been quietly introducing an entire, higher-priority computing system within your consumer laptops and desktops and probably now your tablets and smartphones: This is known as the Intel Management Engine, specifically the Intel Active Management Technology. If your computer's Intel sticker lists "vPro", then you've probably got it!

It's frightening stuff.

These systems involve their own little processors, memory, storage, network interfaces, and proprietary operating systems; as long as the machine is plugged into a power source and wired network—even if the user thinks that it's switched "off"—that little computer within "your" computer can be contacted and used to access the rest of the machine, including your storage drives (hard disks, SSDs, etc.), RAM, main CPU, GPU, etc. It has higher priority than "your" system, can take control of the display and keyboard/mouse/touchpad input so that Intel's AMT can provide VNC access from the moment the main system's boot process begins. It can do all of this while your system is running, including reading your private encryption keys from your RAM or twiddling bits on your hard disk.

Any attempt to remove or alter the proprietary software and hardware that composes the AMT can be made to and likely will be made to brick your system or make it otherwise unusable.

i recommend contacting http://thinkpenguin.com/ for several reasons. firstly, yes they install GNU/Linux by default (so they've done all the hard work, and the research, in advance. is that worth paying for? yes!) secondly, they actually go to the trouble of replacing the BIOS with Coreboot. is _that_ worth it, and worth paying for? yes!

and thirdly, they make sure that the hardware that they've selected is FSF-Hardware-Endorseable, which needs some explanation as to why this is important - and it's not *actually* to do with some sort of stupid or idealistic or neo-fascist or brain-washed or self-righteous or [insert suitable continuation of series of derogatory sentences towards the FSF, Dr Stallman in general and their goals, here, which may be in your mind as to why you feel that you should completely ignore anything and everything associated with the FSF, which we're about to show you are completely moot] reason.

no, the clear benefit from buying FSF-Endorsed hardware such as printers, WIFI and 3G dongles etc. is that they JUST WORK. peripherals these days usually have built-in firmware. because the firmware is pre-loaded in FSF-Endorseable products onto NAND Flash or EEPROM, they're pretty much guaranteed to be more expensive than the devices that require the proprietary firmware to be uploaded to the device, from the main OS, before the device can actually function.... BUT...

what that means in practice is that if you don't *have* that proprietary firmware, or if it happens not to be compatible with the OS, or if you lose it, or if the file system becomes corrupted, or if you perform an upgrade of the OS, and many many other reasons all of which amount to a great deal of hassle, you cannot use that device, period.

the most ridiculous instance of this is that ethernet is becoming less common, CD/DVD drives are becoming less common, creating USB-sticks to boot-install systems has always been a pain, EFI-boot (only) is becoming more common.... how the hell is anyone supposed to install an OS when the only network access is WIFI, and the WIFI requires bloody proprietary firmware that has a license that prevents and prohibits that firmware from being installed on the bloody installation media?? how stupidly ridiculous a situation can you possibly get into! and don't get me started about usb-ethernet devices, which, due to them being USB, are often *excluded* from selection as a "main internet connection" during the install process, because, by nature of them being removable, the OS can't guarantee that the device will be there on the next boot.

avoiding all this hassle is what you pay for when you buy pre-vetted products from http://thinkpenguin.com/ and other companies that are listed on the FSF's page http://www.fsf.org/resources/h... . you can also go to http://h-node.org/ and take a look there to see if what you want is listed.

so when you buy a product from http://thinkpenguin.com/ you know that it's "just going to work". if you genuinely want to replace the OS, you can... and it will be a very straightforward job, unlike, i can guarantee, absolutely every other recommendation at the time of writing of this comment with a category "5" score here on slashdot.

ironically, and not surprisingly, thinkpenguin get less support calls (hardware "just works"). their customers are happier.... and so are more loyal. is that worth paying a bit extra for? yeah i'd say so.

Perhaps we could start a new trend to counteract the decline, something like a "Certified Repair Friendly" logo that could be put on appliances

Would it be analogous to the FSF's Respects Your Freedom certification?

truly free (that is, non-GPL) licenses.

Let me help you understand Stallman's mind:

Under the BSD license, you can take free code and use it as part of a proprietary operating system.

Under the GNU license, derivative code must also be distributed under the GNU license.

So it is not about your freedom. It's about the code's freedom.

Stallman's view is that proprietary software is an evil by itself; it represents a refusal to cooperate with your fellow men. His work, his cause, is to make sure that good code is always freely available to all, and anything else is a treason against mankind. If that sounds too extreme, just read the first chapter of Free As In Freedom. Even if you disagree, there is no way not to feel sympathy for his stance.

You can dig deep into your about:config settings and fix it there ((sorry - setting so obscure can't remember it! You might find it to turn it off but Grandmama won't)) and you are right!!! Firefox only pays lip service to privacy. And like their tieup with Adobe DRM https://www.fsf.org/news/fsf-c..., their advertising page for "partners" http://adexchanger.com/ad-exch..., targeting you for advertising based on your browsing http://www.pcworld.com/article..., and now Disconnect.me, they're doing favors for businesses. Google was paying Firefox $300M a year http://www.webmonkey.com/2011/... before they pulled the plug and Firefox reached a deal with Yahoo, and they switched searches to Yahoo -- not because it was the better search engine, but because Yahoo was giving them cash http://tech.slashdot.org/story...

Firefox has become a megacorporation. They are not for profit http://www.pbs.org/newshour/bb... so that money doesn't to shareholders but it goes SOMEWHERE like executive salaries and just like a megacorporation they care more about cutting deals with other businesses than they do the public because we are not their customers. They are!

First of all, thanks for all of your amazing contributions to free software and free culture movements in general.

I would like to hear your opinion about projects to create free hardware, in particular CPUs like the OpenRISC and RISC-V, or projects striving to create full systems respecting the GPL and without binary blobs like Rhombus Tech's EOMA or lowrisc, or any other that you might know that goes beyond refurbishing existing computers.

In the case that you hold a favourable opinion, I also would like to know if the FSF is in touch (even informally) with any of the teams behind these projects and plan to support them in any way (other than accepting changes to GNU software so it can run in these systems), e.g. by working with them from early on to ensure that they can later be endorsed by Respects Your Freedom.

I've noticed that many of your claims regarding Apple and DRM in the various posts are simply false and I suspect this applies to other vendors. For example

https://www.fsf.org/news/ibad_...

blocking installation of software that comes from anywhere except the official Application Store -- false there are multiple ways to install software used routinely: developer's installation capabilities, enterprise and academic servers, 3rd party app stores included with cloud MDM agreements...

regulating every use of movies downloaded from iTunes -- I'm not sure if they mean the iTunes application or the iTunes cloud services. If they mean the application that's not true, there is nothing to prevent you from uploading your own movie to the application and downloading to a device. If they mean the cloud service they are distributor and have some responsibility but you can grant Apple permission for unlimited free distribution.

Do you think you should be fact checking your claims so that these don't get repeated and then refuted? How is it helpful for the FSF to word things in ways that lack nuance to the extent that they are just provably false?

In fact I suggest you read all of chapter 1 http://static.fsf.org/nosvn/fa...
and then you will be ready to talk about freedom.

You're unlikely to get the answer you seek because you've framed your question in terms of a movement Stallman is (rightly) opposed to, and in ways that he's already explained many times (even the /. summary points to one of the essays on this) -- why Stallman objects to the open source movement (older essay, newer essay also pointed to in the /. summary). He recommends against using Facebook (and has started every talk in the past year or so with an explanation of why posting pictures of people in Facebook/Instagram is a bad idea). I hope he will point out to you that you don't need these things to avoid "losing connection with the rest of the world" and you should value things the open source movement was designed to never talk about, and privacy these services are designed to deny every user of the web. One can hardly "benefit the users" while advocating against copyleft (as the open source movement does), never talking about software freedom (as the open source movement was designed to do), and maintaining a monstrous search engine (as is at the heart of Facebook). You could have done the slightest bit of research and found any of these things I pointed to.

The FSF and RMS in particular never advocated for freedom for hardware.

Other than the "Respects Your Freedom" certification program, which lets computer hardware makers designate their products as compatible with free software.

If you want your software to be used by as many people/corporations as possible, use BSD.

That seems to be the general public consensus.

Personally, if I'm in that situation I use CC0 instead. Its effectively Public Domain, with a completely permissive fallback license for areas where Public Domain isn't possible (eg: arguably the USA). The BSD is a lot of legalese in an attempt to accomplish the same thing. Even after all that effort, some versions of it actually fail and render the code GPL incompatible. Seeing the BSD is a huge drag, because I have to scan the entire text of the damn license looking for common gotchas like advertising clauses. Why?

If total freedom is what you want to give, there's no sense in half-assing it with BSD. Use CC0.

Whatever you do, please please please use a well-known license. I'm am completely sick of having to read and grok screens full of leagalese and then go to The FSF list of licenses to see if there's something important I missed. I'm sure every license has some nuance that makes it better for some purpose or other, but I don't care.

While I understand the attraction of BSD (and its zillion variants), I've found that I can cover all use-cases for my own work with one of three licenses (in order of stringency)

1. GPL - For full-blown applications that I don't want some schmuck trying to swipe and close off to make themselves a profit off my work. This is the most well-known license in existence, so your users should know exactly what they are getting.
2. GPL with linking and inclusion exceptions - For reusable libraries. This allows a client to use my library in a non-GPL program of their own with whatever license they want. (But keeps the library itself GPL). Yes, this is supposedly what the LGPL is for, but it has issues with modern languages like C++ and Ada that use language features that amount to textual inclusion of library code in the client's program. The simple boilerplate exception verbiage in ECos fixes this problem, and otherwise leaves the license the well-known GPL.
3. CC0 - For stuff I want used as much as humanly possible, including incorporated into other people's programs if they like. CC0 is as close to "Public Domain" as it is legally possible to get in this day and age.

4. Now in the poster's case, you'd need to be very careful around the GPL. Check here to make sure all the licenses on all that other stuff is GPL compatible. If not, you can't use GPL. But even if you can, there's no guarantee those other licenses are all compatible with each other. This is why, again, developers should do their users a favor and stick to well-known GPL compatible licenses.

Whatever you do, please please please use a well-known license. I'm am completely sick of having to read and grok screens full of leagalese and then go to The FSF list of licenses to see if there's something important I missed. I'm sure every license has some nuance that makes it better for some purpose or other, but I don't care.

While I understand the attraction of BSD (and its zillion variants), I've found that I can cover all use-cases for my own work with one of three licenses (in order of stringency)

1. GPL - For full-blown applications that I don't want some schmuck trying to swipe and close off to make themselves a profit off my work. This is the most well-known license in existence, so your users should know exactly what they are getting.
2. GPL with linking and inclusion exceptions - For reusable libraries. This allows a client to use my library in a non-GPL program of their own with whatever license they want. (But keeps the library itself GPL). Yes, this is supposedly what the LGPL is for, but it has issues with modern languages like C++ and Ada that use language features that amount to textual inclusion of library code in the client's program. The simple boilerplate exception verbiage in ECos fixes this problem, and otherwise leaves the license the well-known GPL.
3. CC0 - For stuff I want used as much as humanly possible, including incorporated into other people's programs if they like. CC0 is as close to "Public Domain" as it is legally possible to get in this day and age.

4. Now in the poster's case, you'd need to be very careful around the GPL. Check here to make sure all the licenses on all that other stuff is GPL compatible. If not, you can't use GPL. But even if you can, there's no guarantee those other licenses are all compatible with each other. This is why, again, developers should do their users a favor and stick to well-known GPL compatible licenses.

It's a lot simpler than that. Apple wants (a certain amount of) control over what they distribute in the App store. The GPL doesn't let them have it.

I haven't read up on exactly what beef they have with the app store's terms

Don't worry, An AC on this thread already provided a useful link.

You can release _your_ code under whatever license you choose, as long as the license doesn't conflict with the GPL as applied to the derivative work as a whole.

Right, what he should have said was "GPL-compatible" license.

There's nothing "viral" about the GPL which distinguishes it from any other form of licensing. The BSD license is "viral" in that any derived works still have to obey the copyright notice requirements. Closed source licenses are "viral" in the sense that if your work uses closed-source software, your derivative work is subject to the restrictions and limitations of the closed-source license.

There is a degree of difference there though. Yes the BSD license is equally "viral" but the implications and restrictions imposed are significantly less of an imposition than those of the GPL. The same applies to closed source software which is why closed source and BSD software can be sold in the Apple App Store but GPL software cannot.

The only real issue here is the GPLv3's patent license requirements.

Well that depends on if he wants to distribute this iOS program in the App Store.

There is no "depends on how he's using it." If it doesn't have an LGPL interface header, you MUST release the code under GPL terms to use it.

(Sorry for the Clinton-esque answer) It depends on what you mean by "use". The problem with the original question is that there's not enough information to give a useful answer.. it's just fodder to get people talking with no real goal.

You can use GPL's software all you want, modify and recompile to your hearts content, and you don't have to release jack shit - unless you then distribute that stuff, and then only if you distribute it together (you can distribute your patches on their own with any license you choose).

That said, it sounds likely that the choices that NicknamesAreStupid made regarding various sources to include may not be very good choices, and they may be incompatible with his goals. Since he specifically mentioned the GPL (and especially since he didn't say LGPL instead), these compatibility pages should help:
http://www.gnu.org/licenses/li...
http://www.gnu.org/licenses/gp...
http://www.gnu.org/licenses/gp...

The FSF (Free Software Foundation) comments on GPL works within the Apple App store is also quite relevant:
http://www.fsf.org/news/2010-0...
http://www.fsf.org/blogs/licen...
http://apple.stackexchange.com... (see 2nd answer)

Essentially, if you do not hold the copyright for the GPL'd work you are including in your iPhone App that you want to put on the Apple App Store, then you're SOL.... the App Store agreements are incompatible with that (GPL says, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein", but the the Mac App Store Terms of Service explicitly add other restrictions, such as "you may only install the software on five approved devices"). You might be able to get permission from the works authors, but that permission would be to distribute said code under a non-GPL license (possibly 3 clause BSD?)

There is no "depends on how he's using it." If it doesn't have an LGPL interface header, you MUST release the code under GPL terms to use it.

(Sorry for the Clinton-esque answer) It depends on what you mean by "use". The problem with the original question is that there's not enough information to give a useful answer.. it's just fodder to get people talking with no real goal.

You can use GPL's software all you want, modify and recompile to your hearts content, and you don't have to release jack shit - unless you then distribute that stuff, and then only if you distribute it together (you can distribute your patches on their own with any license you choose).

That said, it sounds likely that the choices that NicknamesAreStupid made regarding various sources to include may not be very good choices, and they may be incompatible with his goals. Since he specifically mentioned the GPL (and especially since he didn't say LGPL instead), these compatibility pages should help:
http://www.gnu.org/licenses/li...
http://www.gnu.org/licenses/gp...
http://www.gnu.org/licenses/gp...

The FSF (Free Software Foundation) comments on GPL works within the Apple App store is also quite relevant:
http://www.fsf.org/news/2010-0...
http://www.fsf.org/blogs/licen...
http://apple.stackexchange.com... (see 2nd answer)

Essentially, if you do not hold the copyright for the GPL'd work you are including in your iPhone App that you want to put on the Apple App Store, then you're SOL.... the App Store agreements are incompatible with that (GPL says, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein", but the the Mac App Store Terms of Service explicitly add other restrictions, such as "you may only install the software on five approved devices"). You might be able to get permission from the works authors, but that permission would be to distribute said code under a non-GPL license (possibly 3 clause BSD?)

It's not allowed to distribute GPL software on Apple's App store, because Apple will not comply with the GPL. Read http://www.fsf.org/news/2010-05-app-store-compliance for more details.

just go here http://www.fsf.org/search?Sear... hope this helps.

Since it's Slashdot:

Free Software Foundation http://fsf.org/

Electronic Freedom Foundation http://eff.org/

American Civil Liberties Union http://aclu.org/

Make sure they are registered as a 501(c)(3) so your donations are tax-deducible.

I'd skip sending money to ISIS or the Taliban. It's probably not tax-deductible and may result in unpleasant imprisonment.

If the Mac app store is anything like the iOS app store, it would be a GPL violation to put LibreOffice in there:

https://www.fsf.org/blogs/lice...

Well there was this http://www.fsf.org/news/endors...

But i was being facetious, so ...

because the Ethernet support wasn't completely GPL, Debian did not distribute the code in the default installation package to actually put Debian on this server.

A free software purist would use that as an excuse to replace the server hardware with a different machine that is fully compatible with free software. Are there any Respects Your Freedom certified servers yet?

Actually, Sun Microsystems made a VM and, in 2006, released it under the GPL. So the only real question at this point is whether there is anything in Dalvic that was not released by Sun in 2006-7. Oracle can hope for control over a few small crumbs, but most of the cookies in the Java jar have been free and open source for over 9 years.

EndSoftPatents.org makes multiple relevant points very clear in their warning against relying on Microsoft's "promise" for .NET core listing the limits and foreseeable risks in Microsoft's offer. It seems to me there's enough there to make anyone wary of relying on .NET and instead heed what the Free Software Foundation said in 2009 warning against developing in C#.

You asked:

Burz, I wonder if you'd say the same about all OSS software that's licensed under MIT or BSD but which lacks a patent promise? Because such software would be in an even weaker state from your perspective than Microsoft's OSS .NET.

I don't speak for Burz and I don't argue for anything "OSS", in fact this issue is one reason why looking at this from the perspective of the open source movement is so dangerous. But it seems to me that the FSF has explained this well as they point out in their aforementioned article, Microsoft is "the only major software company that has declared itself the enemy of GNU/Linux and stated its intention to attack our community with patents" which makes Microsoft more of a threat. Also, there's more than one BSD license and it's better to be clear about what you're referring to.

EndSoftPatents.org and the FSF both manage to make their points referring to specifics, linking to their sources, and without using the word "Chinese" to denote confusion or incomprehensibility. So it seems to me that EndSoftPatents.org's conclusion, "This patent licence looks fine for users of the code published by Microsoft, but its protections disappear very quickly for those who wish to modify or re-use the code." is entirely sensible and hardly worthy of your offensive dismissal.

With recent Intel chips containing AMT (Active Management Technology) and vPro, which contain integrated 3G radio support plus hidden processing core running separate hidden "management" instructions from the main core, what I really want to know is which Intel chips have a potential backdoor and which do not.

https://fsf.org/blogs/communit...

Otherwise any smart competitor which can prove that their don't have any backdoors, would have a significant marketing advantage. (Are you listening AMD?)

This page seems to work fine for most users.

This is precisely why I donate to FSF every year. Everybody here should. https://my.fsf.org/donate/

simple tasks like video acceleration that Windows has been doing since 2005

This has obvious causes: Video manufactuers that did not work with open source developers to get their hardware working, when they *did* work with microsoft to get their hardware working on windows. Even RMS almost got arrested trying to fix this problem. This is a political problem, not a technical one.

Mono developer Miguel de Icaza has pledged to continue to add Microsoft's code to Mono saying "Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products".

But is that wise? To your point, the Free Software Foundation's reaction to Microsoft's similar 2009 action point to exactly how changing ownership of patents render Microsoft's Patent Promise not to sue useless. This very promise could become the basis for a patent trap. In 2009 Microsoft's promise not to sue was called a "Community Promise" but today's .NET promise not to sue is risky in the same way—it's not (as the FSF rightly puts it) "an irrevocable patent license for all of its patents that Mono actually exercises" and neither is the MIT license Microsoft chose to release their code under.

Looking back at that essay from 2009, we see the FSF warn us (emphasis mine):

The Community Promise does not give you any rights to exercise the patented claims. It only says that Microsoft will not sue you over claims in patents that it owns or controls. If Microsoft sells one of those patents, there's nothing stopping the buyer from suing everyone who uses the software.

Falling into this trap will directly adversely affect your ability to run, share, and modify covered software. The FSF points to a practical way out as well:

The Solution: A Comprehensive Patent License

If Microsoft genuinely wants to reassure free software users that it does not intend to sue them for using Mono, it should grant the public an irrevocable patent license for all of its patents that Mono actually exercises. That would neatly avoid all of the existing problems with the Community Promise: it's broad enough in scope that we don't have to figure out what's covered by the specification or strictly necessary to implement it. And it would still be in force even if Microsoft sold the patents.

This isn't an unreasonable request, either. GPLv3 requires distributors to provide a similar license when they convey modified versions of covered software, and plenty of companies large and small have had no problem doing that. Certainly one with Microsoft's resources should be able to manage this, too. If they're unsure how to go about it, they should get in touch with us; we'd be happy to work with them to make sure it's satisfactory.

Until that happens, free software developers still should not write software that depends on Mono. C# implementations can still be attacked by Microsoft's patents: the Community Promise is designed to give the company several outs if it wants them. We don't want to see developers' hard work lost to the community if we lose the ability to use Mono, and until we eliminate software patents altogether, using another language is the best way to prevent that from happening.

I find it no accident that the built-to-be-business-friendly "open source" language is all over this announcement including the aforementioned blog post from a prominent endorser, while the wise warnings of falling into a patent trap come from the FSF who consistently looks out for all computer user's software freedoms—software freedom being the very thing that "open source" was designed never to bring to mind (see source 1, source 2 for the history and rationale on this point).

I was half-right; the problem is with the licensing of the DWG library. See
http://www.fsf.org/campaigns/p...

FreeCAD requires installation of Teigha for DWG export:
http://www.freecadweb.org/wiki...

Teigha isn't freely-licensed. There isn't any license info on their webpage, but after installation, it states: "Copyright© 2003-2014, Open Design Alliance All Rights Reserved. This software may not be licensed, sold, distributed or included with other software products without the written consent of Open Design Alliance. "

They aren't trying to sell tools, they are trying to rent tools.

They are selling you a license to use it, just as they (and all other software vendors) have always done. You have never "bought" software, you have only ever "licensed" it. In fact even with free software you are only licensing it, you dont own it and are not free to do what you wish with it.

I've had issues with the last several routers, so I recently bought the very first, 100% OSS router. My thinking is that if it's open source, it's probably high quality code, and it's more likely to get updated than proprietary firmware, where they are cash incentivized to just have you buy the new router rather than fix old bugs.

As far as hardware goes, it's mid-range router hardware, N300 Wifi with respectable antennas and a ho hum 100 Mbit hardware switch. The UI was a little odd, more complex and far more options than your typical Wifi router interface.

However, in the month or so that I've had it, it's been the least problematic Wifi I've had in a few years. I live in a densely populated area with quite a few other hotspots in sight, and I haven't noticed any issues where restarting the router made a difference.

I haven't had the chance yet to hack it, but even as just a router, this is a winner. Also, support products that are consumer friendly like this one. It's not even more expensive! (Currently just $52)

Probably whatever GPU is in a Respects Your Freedom certified laptop such as the Gluglug X60.