Slashdot Mirror

Why fix it then?

• CDDL is free
• use of GPL not always beneficial

• CDDL is free
• use of GPL not always beneficial

yes. http://www.fsf.org

"The real problem here is NOT the CDDL, Apache License, etc. The real problem is the GPL. There are many licenses classified as *free software* by the FSF that are incompatible. What makes SUN's any more evil than the other ones? If Richard's (RMS) criteria for what is free software isn't good enough to make all *free software* licenses compatible, then perhaps his criteria is wrong?"

The FSF does indeed classify the CDDL as a free license, and notes that it is incompatible with the GPL [1]. Debian takes issue with the choice of venue clause that forces legal disputes to be settled in a location specified by the original copyright holder.

The issue in cdrecord with the CDDL and the GPL is that parts are licensed under one and parts of the other; since the licenses are incompatible, no one can redistribute cdrecord. If it were all licensed under one of the two, there wouldn't be an issue (aside from the choice of venue clause).

[1] http://www.fsf.org/licensing/licenses/index_html#G PLIncompatibleLicenses

Debian actually quietly engaged the Apache Foundation about their license too and worked to resolve issues there as well.

But if they are thinking GPL way, ... outcomes are presented for public use but you are not allowed use it, even though they paid for a portion of it;

GPL covers only redistribution without providing source, not use. Proprietary software has all the same restrictions, and many more. You can read more about it, including seeing the actual license (something you apparently have not done), at http://www.fsf.org/

RMS just made himself look bad when he didn't need to...although then again, what else is new?

In one of my last posts on here I talked about how (from what I've seen, anywayz) Red Hat had become profitable...there are a lot of other companies doing what they do, too. Making money with free software is entirely possible...RMS has written about it himself, and even used to do it himself when he was selling Emacs tapes. There's also this, which he could have even mentioned.

It is exasperating...No matter what else he does, the one thing he manages to consistently do is shoot himself in the foot.

> The GPL is designed to prevent commercial exploitation, and it does this
> by forcing companies who use it to publish their modifications.

This is not a misconception, it is in the license. If you use GPLed code in your project, you have to GPL the result. Everybody knows that. In fact, this is exactly what GPL is for.

> The objective of the GPL is to prevent the commercial sale of software
> in order to produce a gift economy in software development.

See http://www.fsf.org/licensing/essays/pragmatic.html , where it is explained how this result is to be achieved through the use of the GPL.

> Microsoft makes money by selling software.
> Making money by selling software is wrong.
> Microsoft is wrong.
> You can't sell GPL software.
> GPL software is better than Microsoft software.

This is simply an incorrect argument. The correct conclusion is "using GPL software is right", which follows from the second premise. If you disagree that making money from selling software is wrong, as most people do, you will not agree with the conclusion.

> You shouldn't use GPL software unless you contribute to the community in some way.

This is not a misconception. It is what the FSF really wants, as stated in the above "Pragmatic Idealism" essay. The key word here is "shouldn't". They will not prevent you, because they can not, but they will apply all the pressure available to them (mainly social pressure from the community) to ensure that you do indeed contribute. It would a misconception to state that you "can't" use GPL software unless you contribute, but it is perfectly correct to say that the above statement expresses the FSF's intentions.

> Any employee who discovers their employer has modified GPL software and hasn't published those changes should deliberately leak them.

Nobody has this misconception.

> Hacking into websites based on GPL CMSes in order to obtain their unpublished mods is intrinsically ethical.

This is not a misconception. Just because you don't publish your modifications, doesn't mean they aren't covered by the GPL.

Ah, the power of non free propaganda. People's heads are so filled with stuff that is at odds with their own experience. They might as well have asked, "How do I make money with a computer?" Of the bazillions of ways to do that, only one of them is the non free way and very few people really make money that way. Really, ask yourself, do you or anyone you know make most of their money writting non free code? Why is it that so many people feel the need to support a model so few people are involved with? That's the power of non free propaganda. It needs to be addressed by knocking down the assumptions that support the conclusions best expressed here: If you don't give me money, your computer will be useless. Most of the missconceptions the public has about software have been created to support that demonstrably false conclusion. Let's look at the particular question.

What kind of an economic model does an entrepreneur look at when he starts out with free software? is vague and hard to answer. What exactly does that mean? At best, they are asking for a laundry list of ways to make money with free software. There are as many ways to answer that question as there are ways to make money with a computer. The only difference between free software and non free is user freedom. You get all the tools you need for the job without cost and you can do anything you want with them. The only way you can't make money with free software is to take someone else`s work and make use it to deny the end user of their rights. The only reason people ask that question is because they are bombarded with FUD that says you can't make a living with free software and that the free software models will one day collapse because of that. After 20 years of GNU growth and mainstream acceptance, you would think that question would go away. It's important to understand that free software is not dependent on any economic model so it is here to stay.

Your statement,

I wonder why RMS is so opposed to economic acceptance. It seems that he believes F/OSS's noble goals will be corrupted if Linux gains momentum in the corporate world, but don't we have the GPL to prevent just that? Ultimately, corporate support will help secure the foundation of F/OSS -- I'm thinking of IBM and Sun, and the corporate support behind OpenBSD and FreeBSD

is equally vague and missleading. While free software is about freedom and not about making money, there is no hostility to commercial activity or corporate involvement. A FSF newsletter a while back was positively glowing over the way free software has been adopted by embedded developers. It's pretty obvious from this that free software can be commercial software and that no one has a grudge against that.

There is no need to be parsimonious with your gratitude. You say that as if we must choose between giving thanks to both the community and RMS and Torvalds. By the standard you endorse we end up essentially saying "what have you done for me lately?" instead of valuing both the community including both men for their work in the past and their continued work on things that matter.

After all, even by the silly logic of valuing what is and not what was, Torvalds and RMS both deserve thanks; Linus Torvalds is still involved in Linux kernel development, despite not writing all of the code in his fork of that kernel. Richard Stallman is the author of the most widely used free software licenses—the GNU GPL, the GNU LGPL, and the free documentation license the GNU FDL. And when it comes to the GPL (the subject of the talk at the heart of this /. thread), Eben Moglen says "there is no other copyright license in the world that is so strongly identified with the achievements, and the philosophy, of a single public figure".

Richard Stallman is, in my humble opinion, A HERO and even a true american patriot.

He has been protesting evil surveillance technology such as RFID for years. And there are few other people who have contributed more to free software and humanity in general as he has.

Take a look at his past speches: http://www.fsf.org/events/past-rms-speeches.html?b _start:int=0

And remember his protest at the UN Summit: http://www.secureidnews.com/weblog/2005/11/21/rich ard-stallman-protests-at-un-world-summit/

(as you may or may not be aware, the UN are evil. They openly admit they want the UN to be a one-world government and that they want to destroy the sovereignty of any existing nation. Richard Stallman is a hero for protesting against UN evil)

It would be nice if the FSF actually noticed trends that damage people's understanding of the GPL and did something about them. For example, many programs place the GPL in the role of a click-through license. This makes no sense whatsoever, and leads people to think that the GPL is a EULA and that it applies to *users* of GPL'd sofware. On top of that, it lends credence to the notion that click-through licenses are worth something.

The FSF is not the copyright holder to a lot of GPL-covered software (probably most GPL-covered software). So there is only so much they can do. Their lack of litigiousness is a benefit to society. We would be worse off if they spent their resources suing people to convince them of the righteousness of their argument like the RIAA does. But to say the FSF doesn't "notice trends damage people's understanding of the GPL and [do] something about them" or that the "FSF doesn't do jack" is simply wrong.

• Members of the FSF (including GPL author Richard Stallman, Prof. Eben Moglen, and former FSF Executive Director Brad Kuhn) have gone on speaking tours taking questions from all comers, including during dinner after the talk. The talks are often recorded and available online in formats one can play with free software licensed to share verbatim in any medium, even commercially. I feel privileged to have been at the 2006 recent FSF member meeting in Cambridge where I met Prof. Moglen and heard him speak. I was so impressed with his talk, I later aired it on my radio show and I share copies of it with people on my blog.
• The FSF has published a GNU General Public License FAQ and that FAQ contains an entry which addresses your concern:

  Can software installers ask people to click to agree to the GPL? If I get some software under the GPL, do I have to agree to anything?

  Some software packaging systems have a place which requires you to click through or otherwise indicate assent to the terms of the GPL. This is neither required nor forbidden. With or without a click through, the GPL's rules remain the same.

  Merely agreeing to the GPL doesn't place any obligations on you. You are not required to agree to anything to merely use software which is licensed under the GPL. You only have obligations if you modify or distribute the software. If it really bothers you to click through the GPL, nothing stops you from hacking the software to bypass this.

You said:

They [the FSF] claim that any application utilizing MySQL as its SQL database is combining the two applications into a new program and thus either a) becomes subject to the GPL or b) must purchase a commercial license from MySQL. Gee, what could make them want to interpret it that way? Yet while MySQL is flaunting this definition all over the place, the FSF has done nothing to correct them.

What, exactly, constitutes a derivative work in software hasn't been completely argued and drawn out in court yet. This, taken in combination with the FSF not being a copyright holder on MySQL, makes it unreasonable to expect the FSF to correct any misunderstanding MySQL exhibits in their licensing. But the FSF has made numerous statements about what they think on the issue of linking and derivative works. Prof. Eben Moglen, counsel to the FSF, even filed a friend of the court brief to Judge Saris in the MySQL v. NuSphere/Progress case. John Palfrey reported that Judge Saris referred to Moglen's brief and a counter brief as "classic book-ends" because they had drawn opposite conclusions on the matter of what is a derivative work. Judg

One question I've wondered about the GPL. If I write a program that links to a shared library that is GPL'd, do I need to GPL my application as well?

There are two schools of thought on this, and the answer to your question is pretty hotly debated.

The "stricter" school of thought, unsurprisingly the one favored by the FSF, is that statically or dynamically linking an executable to a library forms a work which can be considered a derived work of both sets of code. Under this theory, your application's source code doesn't have to be GPL, but its license does have to be compatible with the GPL since the linked work (app + library) taken as a whole is in part derived from the library and hence must be under the GPL. For instance, your app's source code could be licensed as LGPL or two-clause BSD in this situation with no problem, but could not be (for instance) CDDL or 4-clause BSD. Most Linux distributions follow this stricter, more conservative view.

On the other hand, it has been pointed out that this strict interpretation can sometimes lead to a peculiar conclusion. Suppose a work-alike copy of a GPL library is written from scratch and licensed permissively. Then a program linked against the GPL lib could also be used with the permissive library that forms a drop-in replacement. The strict theory of linking then implies that the license of your application is GPL if the GPL library is on your system, but not if the replacement library is instead. If this is not an acceptable conclusion, then it must be that dynamic linking against a GPL library does not make the application be under GPL as well.

This looser interpretation effectively defangs the GPL and makes it essentially equivalent to the LGPL, because anyone could change GPL'ed code they want to use into a shared library, then link their proprietary application against it.

Note that the interpretations differ only in the case of dynamic linking. When an application is linked statically against a GPL library, parts of the library object code end up in the compiled executable and therefore this is indisputably a derived work of both application code and library, hence under GPL. Proponents of the strict interpretation point out that from an end-user's viewpoint, there is no difference between static and dynamic linking other than the "-static" flag given to the linker, so the two methods of linking should not be legally distinguished either.

To the best of my knowledge (IANAL) there isn't any legal precedent favoring either interpretation.

"He appears to have no interest in the practical outcome of his evangelism"

Heck! what is this vast ammount of free software then?

Regardless (should have mentioned this in my original reply, since I did find it), your link does not have any mention of the Microsoft Community License. The MCL does not have the restriction on commercial use to which the FSF objects, the term "non-commercial" does not even appear in it at all. It is, at first glance, apparently non-GPL-compatible due to a patent clause, but that doesn't make it non-free - several licenses at http://www.fsf.org/licensing/licenses/index_html#G PLIncompatibleLicenses (such as the Apache license) are non-gpl-compatible for similar reasons.

You can copyleft and assign ownership to FSF. They have the legal muscle.

Funny that the anchor you linked to is "non-free documentation licenses"

There are plenty of OSI-approved licenses that can't be mixed with each other. See GPL-Incompatible, Free Software Licenses for a list of such licenses that can't be mixed with the GPL (and thus with the linux kernel. the GPL v3 will likely also be incompatible with the GPL v2, for programs that explicitly pick a version, in at least one direction)

Because OSI complied to microsoft's demand and didn't evaluate the license, we won't know their stance about it.
On the other hand the FSF has shown what they're thinking about it.

Although both institutions (read: ESR and RMS) are known to have divergent point of view, this hints about how much this license can be free, and what one should think before starting his own project using this kind of licensing (something for which knowing OSI, FSF and DFSG's stance can be genuinly useful, as some other /. signaled).

I know that most /.ers think that it's best to stick to known licenses that are widely used, documented and proven (including tested in court), and most of the time the debate is only about the duality BSD vs. GPL (Should we allow the code to be forked into a proprietary branch or not), and that's maybe what most home-brewed projects do.

But there are a lot of place (I've whitnessed some), particulary those big places that are new to the open-source concept, that don't automatically trust GPL and consider it proven (they've usually never heard of Groklaw, or the numerous cases of GPL-violation that were successfuly resolved). They don't start with a small subset of preferences (BSD/GPL), but do extensive - but, alas, sometime un-educated - researchs about everything they can encounter, they often start considering obscure licenses that the average OSS user has never heard of, often on the account of some higher hierarchy member or some beancounter that are affraid to 'lose control', and may end up using a solution that will turn up to be not as useful as expected.

It is in such case that organisations like OSI can come handy to help choose and discern among the huge diversity of licensing scheme.

Because OSI complied to microsoft's demand and didn't evaluate the license, we won't know their stance about it.
On the other hand the FSF has shown what they're thinking about it.

Although both institutions (read: ESR and RMS) are known to have divergent point of view, this hints about how much this license can be free, and what one should think before starting his own project using this kind of licensing (something for which knowing OSI, FSF and DFSG's stance can be genuinly useful, as some other /. signaled).

I know that most /.ers think that it's best to stick to known licenses that are widely used, documented and proven (including tested in court), and most of the time the debate is only about the duality BSD vs. GPL (Should we allow the code to be forked into a proprietary branch or not), and that's maybe what most home-brewed projects do.

But there are a lot of place (I've whitnessed some), particulary those big places that are new to the open-source concept, that don't automatically trust GPL and consider it proven (they've usually never heard of Groklaw, or the numerous cases of GPL-violation that were successfuly resolved). They don't start with a small subset of preferences (BSD/GPL), but do extensive - but, alas, sometime un-educated - researchs about everything they can encounter, they often start considering obscure licenses that the average OSS user has never heard of, often on the account of some higher hierarchy member or some beancounter that are affraid to 'lose control', and may end up using a solution that will turn up to be not as useful as expected.

It is in such case that organisations like OSI can come handy to help choose and discern among the huge diversity of licensing scheme.

The point of Free Software is to keep the software free. Ie, not being able to be hijacked by corporations to:

* use it on a webpage without releasing source
* use it on locked-down hardware that the customer never owns
* any other loophole that goes against the spirit of the GPL which has historically been abused in the past for GPL v2

GPL v3 is simply a needed adjustment that is long overdue.

GPL v3 is not out to disallow DRMed hardware, just as GPL v2 is not against copyright.

GPL v3 is against hijacking of supposedly Free Software.
Without GPL v3, the loophole in GPL v2 is only going to get bigger and bigger..

But I don't know, I just contributed some stuff at the GPL v3 propsals: http://gplv3.fsf.org/comments/gplv3-draft-2.html

FSF is being VERY UNPRECEDENTED open about this, and is even accepting comments. So this is your chance to change the future via the keyboard...

Well, Given that the major example of this clause (the GPU project) has reverted to the straight GPL, and there appears to be no support at the FSF for including this, even as an optional addition to the GPL.

FWIW, the offending terms were:

"The Program and its derivative work will neither be modified or executed to harm any human being nor through inaction permit any human being to be harmed."

While it would make the work non-free (by limiting Freedom-0), it is a far cry from "no use by the military."

You'll never get a consise answer to this about v2. Pretty much because the people who wrote is aren't lawyers either and there are enough inherent contradictions that the entire license could probably be invalidated if it was actually presented to a court.

Hopefully v3 addresses this specifically, regardless of which way they chose it should be clear.

http://www.fsf.org/licensing/licenses/gpl-faq.html #IfLibraryIsGPL

That sounds clear, but it is an interpretation of the license not the actual license itself.

Mostly that's why people interested in Free Software use a BSD or MIT license and people involved in commercial development stay away from the GPL. The GPL isn't anything but a soapbox for people like Eric Raymond and Richard Stallman. The limousine liberals of the software world.

Please read...

http://gplv3.fsf.org/gpl-draft-2006-07-27.html

don't take it from me, they have had web pages for many years.

I assume you mean that they have had different web pages for many years, but that's not true. http://www.fsf.org/ and http://www.gnu.org/ used to serve the same web site, until the former was redesigned a year or two ago. (See archive.org for May 25, 2003, for example).

But it's true that the GNU project and the FSF are different, and the FSF has increasingly been distinguishing the two.

You can't change the firmware, so there's no point in wanting to be able to.

http://www.fsf.org/campaigns/free-bios.html

The FSF is not comissioning any new large scale undertakings at the moment.

This is just blatantly wrong.

What do you call Gnu Flash? Other projects FSF is directing include Free Bios and an open 3D Card driver. More projects are listed here. Just like gcc was needed in the 80s, these are the utilities users need now.

At the risk of being modded for flame bait, I'll also point out that it seems most criticisms of the FSF are based on plain ignorance.

The FSF is not comissioning any new large scale undertakings at the moment.

This is just blatantly wrong.

What do you call Gnu Flash? Other projects FSF is directing include Free Bios and an open 3D Card driver. More projects are listed here. Just like gcc was needed in the 80s, these are the utilities users need now.

At the risk of being modded for flame bait, I'll also point out that it seems most criticisms of the FSF are based on plain ignorance.

I've asked for open source hardware drivers from the major vendors (mostly for wireless acrds), with almost no success, so I've found an alternative. The Free Software Foundation keeps a list of hardware with free/open source drivers here. After reading the list, I got a Zonet ZEW-1500 Wireless G card from Amazon (no longer there, try eBay). Ubuntu found it instantly, as did Knoppix (wireless support from a bootable CD! Woo Hoo!). Had no problem getting WPA working with it in Linux, as it was supported in firmware. I recommend you still badger the Big Vendors about releasing free drivers and/or specs, but you can drastically reduce the amount of tinkering you have to do to get your wireless card to work under Linux by getting one that already has free drivers available, and who knows? If enough people support the companies that have free drivers, the Big Vendors might just open their drivers up to remain competitive. But I'm not holding my breath.

No, in my opinion, it doesn't give you a justification.

Look, I can understand taking a lot of things without paying for them. If you're starving, and the local stores are selling food with such a high mark-up, you could never afford to pay for it, then yes, I can understand you stealing.

And to a certain extent, I can understand copyright infringement when applied to software. I don't do it, I don't agree with it, but I can understand someone being in a situation where they require the tools to do a particular job, and can't afford software which would never be their choice to buy anyway, but is the software they need because other people - thanks to network effects etc - have essentially made mandatory if you want to "play" with them.

Certainly, I think there's a strong argument for, in their present form, reforming copyrights in their present form (that is, in their present form*) when applied to computer software. Hey, I'm not the only one.

But music? I could go my whole life without needing to listen to a specific piece of music. Same goes for movies, and literature. I'm not saying my life wouldn't be enriched by it, but my life can be enriched by the free music out there anyway, it doesn't have to be the latest MTV-promoted big name.

Someone's decision to make their music only available to those who are willing to pay for it doesn't hurt me in the slightest. I can make a judgement as to whether that music would enrich my life enough for me to part with the required amount of cash. In the mean time, I have real alternatives. There's music in the public domain. There are artists with lower priced music or who source their music via alternative means. To decide to take advantage of someone else's work without paying on their terms strikes me as very unfair, especially if there's nothing they've done that makes me need that work.

* You know some dumbass is going to respond "You're saying we should abolish copyright for software?" and give me a thousand reasons, three or four of which are actually good ones, why this would be bad. I'm not proposing we abolish it. Hence me repeating that part three times.

It's non-free and non-free and not open source and not GPL compatible.

I'm about as likely to use this shared-source "GPU" as I am to use XFree86 4.4.

I'm even less likely to contribute to it.

I, for one, would not be comfortable using a license when nobody can seem to satisfactorily explain what can or can't be done with the code, and I certainly would not cross my fingers and hope that the courts happen to see things the way I think they should.

If you want the license explained, read the FSF's GPL FAQ, Groklaw, or any of the other places where people discuss licenses. If all those places can't "satisfactorily explain" the GPL to you, then you probably won't believe anything except what a lawyer advises you.

Most licenses are vague in some way. Even the n-clause BSD licenses, if you take the strict English interpretation of them, are ambiguous: they basically say that "redistribution is allowed if redistributions of source code must..." without actually saying that "redistributions of source code must..". The reality is that licenses are interpreted by the courts, and all of us have to take some risk and assume that we are interpreting the licenses the same way that the courts ultimately will. Even if you hire a lawyer, there's always the risk that the judge will disagree with your lawyer. There's not much the FSF can do about that.

As for GPLv3draft2, it's really quite clear: You have to distribute (or offer to distribute in designated ways) the Corresponding Source when you distribute binaries. The Corresponding Source includes any "keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances.". If your package manager has a list of keys that it trusts, but you can change that list, then the keys I use to sign the binaries are not "necessary to install and/or execute modified versions", and thus are not part of the Corresponding Source. If you can't change that list, then trusted keys are part of the Corresponding Source. These two cases are not "exactly the same" as far as the courts are concerned. If I'm distributing binaries without the Corresponding Source, then the permissions granted in GPLv3draft2 don't apply to me, and so I need another lawful excuse to distribute the copyrighted code.

I suggest you re-read the GPLv3 draft, and also read the rationale document (PDF). You have to read it a few times before you'll fully understand it, but it's really not that difficult to grasp.

I, for one, would not be comfortable using a license when nobody can seem to satisfactorily explain what can or can't be done with the code, and I certainly would not cross my fingers and hope that the courts happen to see things the way I think they should.

If you want the license explained, read the FSF's GPL FAQ, Groklaw, or any of the other places where people discuss licenses. If all those places can't "satisfactorily explain" the GPL to you, then you probably won't believe anything except what a lawyer advises you.

Most licenses are vague in some way. Even the n-clause BSD licenses, if you take the strict English interpretation of them, are ambiguous: they basically say that "redistribution is allowed if redistributions of source code must..." without actually saying that "redistributions of source code must..". The reality is that licenses are interpreted by the courts, and all of us have to take some risk and assume that we are interpreting the licenses the same way that the courts ultimately will. Even if you hire a lawyer, there's always the risk that the judge will disagree with your lawyer. There's not much the FSF can do about that.

As for GPLv3draft2, it's really quite clear: You have to distribute (or offer to distribute in designated ways) the Corresponding Source when you distribute binaries. The Corresponding Source includes any "keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances.". If your package manager has a list of keys that it trusts, but you can change that list, then the keys I use to sign the binaries are not "necessary to install and/or execute modified versions", and thus are not part of the Corresponding Source. If you can't change that list, then trusted keys are part of the Corresponding Source. These two cases are not "exactly the same" as far as the courts are concerned. If I'm distributing binaries without the Corresponding Source, then the permissions granted in GPLv3draft2 don't apply to me, and so I need another lawful excuse to distribute the copyrighted code.

I suggest you re-read the GPLv3 draft, and also read the rationale document (PDF). You have to read it a few times before you'll fully understand it, but it's really not that difficult to grasp.

The GPLv3 draft makes it impossible to create tamper-resistant software.

Two issues.

1) Treacherous Computing vs. ROM
You seem to think it is a bug in the GPLv3 that allows code to be used on ROM'ed machines but not treacherous computers. I see this as a feature not a bug. You might want to look at Stallman's description of the problem with treacherous computing so we at least have a common reference point even if you don't agree with everything he says. Personally, I've got no problem with people using my GPL'ed code on ROM'ed devices, but I am very concerned about using my GPL'ed code on treacherous computers. This is why I see the distinction made between the two by the GPLv3 as a feature not a bug.

2)Treacherous Computing via Virtualization
If I understand your second point correctly, you're suggesting that a virtualization layer (like Xen or VMware) could impose DRM restrictions on GPLv3 code. IANAL, so you might want to run this past the good folks at the FSF and see if they thought of it already, but it seems to me that holding DRM keys in a virtualization layer would be no different from holding keys in hardware so I don't see how it could make an end run around the GPLv3.

As I told you before, the GPLv3 says that if one person can modify and run the code then everyone needs to be able to modify and run the code. It doesn't matter what type of thing holds the keys, hardware or software, the GPLv3 is all about who controls the keys. If the manufacturer controls the keys and not the computer owner, then it's not legal to use GPLv3 code.

If these GPLv3 issues are of any interest to you at all, you will save both of us a lot of trouble if you just read it for yourself at the GPLv3 web site and also read their opinion pieces, particular the one about DRM. If you still think they've missed something, you should contact them and let them know. There is a link to their comments page from both the FSF links I gave you above.

Two issues.

1) Treacherous Computing vs. ROM
You seem to think it is a bug in the GPLv3 that allows code to be used on ROM'ed machines but not treacherous computers. I see this as a feature not a bug. You might want to look at Stallman's description of the problem with treacherous computing so we at least have a common reference point even if you don't agree with everything he says. Personally, I've got no problem with people using my GPL'ed code on ROM'ed devices, but I am very concerned about using my GPL'ed code on treacherous computers. This is why I see the distinction made between the two by the GPLv3 as a feature not a bug.

2)Treacherous Computing via Virtualization
If I understand your second point correctly, you're suggesting that a virtualization layer (like Xen or VMware) could impose DRM restrictions on GPLv3 code. IANAL, so you might want to run this past the good folks at the FSF and see if they thought of it already, but it seems to me that holding DRM keys in a virtualization layer would be no different from holding keys in hardware so I don't see how it could make an end run around the GPLv3.

As I told you before, the GPLv3 says that if one person can modify and run the code then everyone needs to be able to modify and run the code. It doesn't matter what type of thing holds the keys, hardware or software, the GPLv3 is all about who controls the keys. If the manufacturer controls the keys and not the computer owner, then it's not legal to use GPLv3 code.

If these GPLv3 issues are of any interest to you at all, you will save both of us a lot of trouble if you just read it for yourself at the GPLv3 web site and also read their opinion pieces, particular the one about DRM. If you still think they've missed something, you should contact them and let them know. There is a link to their comments page from both the FSF links I gave you above.

The license isn't a crowbar, it's a shield. It's a shield for YOUR code you're writing, a shield for the ideal that you don't want your code used unless others can modify it and use it. If someone's use of your code is limited by hardware restrictions and you want to further strengthen that shield by V3, then go for it. If you as an author don't like carrying the ideal that far and you think access to the source is enough, don't use V3 (as you seem to suggest you won't be). There's room for more than one OSS license.

The example you site has nothing to do with the GPLV3. The fault is either with:

1) The company who released hardware built on code that allowed others to change the code in an environment where that's a bad idea. (ie, build your own fricking code, don't rely on others who want their code to be modifiable, not just easy to print out and stare at)

or

2) The moron who loaded code onto a machine that could cause problems, probably violating federal law in using a non-FDA approved device (since I imagine the FDA approval only covers the device with specific code).

The GPLV3 is not evil and didn't cause anyone's heart monitor problems, the above did.

As for a comment period, check out:

http://www.fsf.org/news/gpl3.html

Scroll to the bottom, specifically the section near: "The Foundation will, before it emits a first discussion draft, publicize the process by which it intends to gather opinion and suggestions. The Free Software Foundation recognizes that the reversioning of the GPL is a crucial moment in the evolution of the free software community, and the Foundation intends to meet its responsibilities to the makers, distributors and users of free software. In doing so, we hope to hear all relevant points of view, and to make decisions that reflect the many disparate purposes that the license must serve."

This does bring up a flaw in the idea, though: what stops a company like TiVo from creating "unrelated" shell organizations so as to separate the kernel development and hardware development in order to get around this?

The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source.

• If Ovit's software runs only on the Tivo hardware, then the signing key is "necessary to ... execute modified versions in the ... recommended or principle context of use," and Ovit is guilty of copyright infringement (since the GPLv3 does not apply to their redistribution).
  
• If Ovit's software runs on other hardware than the Tivo (with "all the same functionality"), then their software is legal by the terms of the GPLv3, which is correct, because they really are making general-purpose media center software, and the lack of freedom on Tivo hardware is merely an irritation rather than a menace.
  

This argument keeps surfacing even though it has been debunked time and again. The GPL v3 only requires you to provide the embedded key if it is necessary to run the software. That's the letter and the spirit of the GPL v3. The second discussion draft clearly words out:

The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances.

Neither.

Apple didn't "get" Open Source (that's fine, many of us Free Software enthusiasts don't "get" Open Source either) and began deprecating it when it started to interfere with their other plans in general. The first to be deprecated was the open-sourciness, with Apple releasing code but generally not in a "community friendly" way and rarely making it easy for the community to contribute directly back.

There's no evil in that, if you're strongly opinionated about the direction code should take, and you have the resources to write it yourself, you don't necessarily want to spend time trying to integrate everyone else's changes with your own.

Some people noticed. In particular, the KHTML people got a little fed up with people pointing out that WebKit supported some feature or other that hadn't made it into KHTML yet. They explained that the changes to WebKit weren't easy to track and back-port. This was interpreted by the meeja, including Slashdot, as KHTML slapping down Apple, rather than slapping down the people who assume that simply because X is based on Y, Y can easily incorporate changes to X, and who keep flaming the developers of Y for not doing this.

Then Apple closed XNU-Intel. Yes, they did. There are several releases of XNU-Intel for which source code apparently will never be released (though who would want them?) Some people noticed. They pointed this out and were immediately hounded by a bunch of, for the most part, obnoxious Mac zealots who claimed this wasn't true because at some point in the future, Apple might change their mind, and any way, who said their mind had been made up, I mean, Apple hasn't made an official announcement, right? To make matters worse, Apple's one comment on this was so inane it simply fueled the fire. One developer at Apple, posting on an Apple mailing list, said that the talk of XNU-Intel being "closed" was "speculation" and people shouldn't assume anything.

This was meaningless and largely wrong. Those saying it was closed were right: it was. You couldn't download the source to XNU-Intel. When you're stating a fact, you're not engaging in speculation.

There was much anger at this point because many people felt lied to. Apple had been advertising the openness of Darwin for a long time, and "Team Apple*" had been loud in repeating this supposed advantage, and now, without any explanation, the core of Darwin was now closed. Team Apple responded by claiming the Apple developer who said "speculation" had actually used the word "yet", and the "yet" word was used in pretty much every response to anyone critical of Apple or simply pointing out the fact that XNU-Intel was closed. Team Apple changed tact on the "Open Source is an advantage of Mac OS X" thing too, claiming it was never Apple's intention to release a useful operating system as open source, and that nobody cares about operating system kernels anyway. Needless to say, this intensified the anger.

What do we have today?

Apple has taken considerable steps to undo the damage. There's still no real explanation as to why XNU-Intel was closed. No technologies were announced yesterday whose existance could be discerned by looking at the kernel - which has supported the Intel architecture since its original release, which has supported the Xeon CPU range even back in the Panther days, and probably long before. It was not necessary to withhold the XNU source before the release of the PowerMac G5, or, indeed, any of the recent radical changes in architecture. Meanwhile, the software-related announcements this week don't appear to have anything to do with the Tiger kernel.

So, anyway, leaving aside the nonsense that it's "been confirmed" that the withholding of the source "was due to Apple's policy of not commenting upon unreleased products", we don't have an explanatio

All hail the new unremovable advertising popups in GPLv3 (section 5c)!

If the modified work has interactive user interfaces, each must include a convenient feature that displays an appropriate copyright notice ... if the interface presents a list of user commands or options, such as a menu, a command to display this information must be prominent in the list; otherwise, the modified work must display this information at startup.

BSD licenses are not Free Software because they do not "preserve freedom" (sic) in the way GPL does.

Wrong. They're not "copyleft" licenses, but they are free software. RTFW.

the FSF has fought hard to promote a given definition of "Free Software", and as a trademark-like name, it's got different meaning from "free software", using the common english definitions of those words.

Wrong again. Go look at the FSF's website. None of their core philosophy documents capitalize "Free Software" the way you do, except when the it's followed by "Foundation".

besides, if you use the broader definition (which i'm certainly not going to try to talk you out of, since i think it's the better one), the point in the grandparent post is even less defensible. i was trying to be charitable.

Your opinion is overrated. Read the fscking document:/p>

Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

A program is free software if users have all of these freedoms.

It's not really that difficult to understand.

BSD licenses are not Free Software because they do not "preserve freedom" (sic) in the way GPL does.

Wrong. They're not "copyleft" licenses, but they are free software. RTFW.

the FSF has fought hard to promote a given definition of "Free Software", and as a trademark-like name, it's got different meaning from "free software", using the common english definitions of those words.

Wrong again. Go look at the FSF's website. None of their core philosophy documents capitalize "Free Software" the way you do, except when the it's followed by "Foundation".

besides, if you use the broader definition (which i'm certainly not going to try to talk you out of, since i think it's the better one), the point in the grandparent post is even less defensible. i was trying to be charitable.

Your opinion is overrated. Read the fscking document:/p>

Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

A program is free software if users have all of these freedoms.

It's not really that difficult to understand.

Terms and Conditions, section 1, paragraph 4

The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. *If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.*) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. *However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source.*

This specifically allows modified versions to hide the fact that they are modified. Thereby it creates two technical problems:

• it makes it impossible to verify and certify distributed systems consisting in whole or in part of (derived works of) Free Software.
• it makes it impossible to verify the integrity of a distribution package consisting of Free Software and hardware and/or non-free software, e.g. to determine eligibility for support or warranties.

These seem to me to exclude Free Software from a substantial set of reasonable and legitimate applications in existence today or foreseeable for the future.

Additionally, it seems to be in conflict with the following provision:

Terms and Conditions, section 5, paragraph 2

a) The modified work must carry prominent notices stating that you changed the work and the date of any change.

In particular, the section quoted earlier seems to amend this with, "unless the notice would be machine-readable, in which case the modified work may choose not to carry such a notice". This serves as a strong deterrent to authors of original works to free those works if they customarily provide them e.g. as part of a hardware package on which they in turn provide a warranty.

Lastly, this whole issue seems to open up a veritable can of worms with regards to the definition of "derived work" vs. "aggregate". In the case of Tivo for example, the distribution package consists of a computer with some proprietary hardware on which some free software and some proprietary software is installed, all of which works properly only in connection with an online service. Now for some reasons, the proprietary software part is s

"BSD licenses are not Free Software because they do not "preserve freedom" (sic) in the way GPL does. i think i agree that it's a stupid distinction, but the FSF has fought hard to promote a given definition of "Free Software""

Who told you this???

Here is the FSF's definition of "free software". There's no such "preserve freedom" clause.

They also have a list of free software licenses free software licenses. Note that BSD is included. (It is non-copyleft, but free.)

They certainly *do* prefer the GPL, in general (though not necessarily everywhere), but they definitely do not do that by claiming that non-GPL'd software is not free software.

But if there really are regulations which forbid software on certain devices from being modified once it's installed, it's still possible to use software licensed under the GPL -- simply burn the software into a ROM. Then nobody can upgrade it without replacing the ROM. Of course, device manufacturers will protest that this prevents them from upgrading it themselves. This shows that their true desires are not to comply with FDA rules, but to get special rights that nobody else has.

Actually, the FSF explicitly considers the BSD License to be a free software license.

I believe the distinction is that a free software license is merely one which does not infringe on the freedoms they list here. Actively ensuring the freedoms of the end-user is the GPL's niche to be sure, (through tricks like copyleft) but they do not consider that stuff to be neccesary in order for software to be free.

There is a lot of waffle in the article about listening to people but nobody had presented a simple table showing the requirements for GPLv3 in different drafts.

What about this one?

If the job is related to free software, we'd be happy to post it.