Weekly Edition
Return to the Announcements page
| |||||||||||||
FSF: GPLv3 Update #2
On January 16th, the leaders of the Free Software Foundation, Richard Stallman and Eben Moglen, welcomed over 300 people in an auditorium at the Massachusetts Institute of Technology to the first in a series of international conferences dedicated to producing the next version of the GNU General Public License. As a subscriber to this mailing list, you received a copy of the new license draft simultaneous with its release at the conference---but if you weren't also in the room, you missed Professor Moglen's detailed walk-through of the new text, and Richard Stallman's description of the threats faced by the free software community to which the new license must respond. You can now download the video of the opening presentation at <http://gplv3.fsf.org/av/gplv3-draft1-release.ogg.torrent>>. Since then, comments on the license draft have been welcomed at <http://gplv3.fsf.org/comment>>, but the commenting process actually began during the remainder of the two-day conference during a series of panels exploring the specific issues raised by Moglen and Stallman and inviting dialogue with the audience. The two most thought-provoking panels were the the panel on Digital Restrictions Management (DRM), and the panel on internationalization. The DRM panel included FSF's David Turner, the Electronic Frontier Foundation's Staff Technologist and DRM expert Seth Schoen, and the Wikimedia Foundation's Legal Officer Jean-Baptiste Soufron. They detailed the threats posed by Treacherous Computing (often misleadingly called Trusted Computing) and discussed with the audience ways that the new GPL will deal with them. The related license provisions have been highlighted in the news recently as a result of concerns expressed by the Linux developers. Stallman has responded to these concerns: GPLv3 would not require Linux developers to publish the private keys that they use to sign Linux source versions to show they are authentic. But GPLv3 would require the manufacturer of the Tivo you bought to give you the key needed to sign a binary so it will run on your Tivo. That means you will really be able to run the modified versions on your Tivo and they will really run. The Tivo was the first well-known case of a machine that included free software but refused to run the users' modified versions, but it surely won't be the last. It happens that Linux is one of the programs that were tivoized in this way. We hope that the developers of Linux will adopt the GPLv3, so as to make future Linux versions resistant to tivoization in the future. Identifying any unintended consequences of the new GPL is a vital part of the update process, and the FSF welcomes everyone to comment on the license. Since the GPL seeks to provide protection for free software worldwide, the panel discussion hosted by a group of free software luminaries from around the world, including Juan Carlos Gentile (Hipatia); Enrique Chaparro (FSF Latin America); Stefano Mafulli (FSF Europe); and Niibe Yutaka (Free Software Initiative of Japan), was another essential component. They focused on key differences between languages and jurisdictions that will need to be considered, and on the need to translate not only the license itself but also the documents surrounding the drafting process. More conferences are planned for the future, and we will be sure to let you know the dates as they become available. Please support the continuation of this process by making a donation at <https://www.fsf.org/donate>>, or by becoming an FSF associate member at <http://member.fsf.org>>. As a benefit, you will then be able to attend our annual membership meeting on April 1st in Cambridge, Massachusetts. At the conference, in addition to the license, we also released a new t-shirt and hoodie featuring the GPLv3 logo. You can show your support by ordering them at <http://www.gnu.org/gear/gplv3-tshirt.html>>. -- John Sullivan, FSF Program Administrator _______________________________________________ Info-gplv3 mailing list Info-gplv3@gplv3.fsf.org http://gplv3.fsf.org (Log in to post comments)
FSF: GPLv3 Update #2 Posted Feb 11, 2006 17:24 UTC (Sat) by sumC (subscriber, #1262) [Link] And what codec are requierd to play that clip?I'm in Windows right now and mpc didn't recognize it.
FSF: GPLv3 Update #2 Posted Feb 11, 2006 17:28 UTC (Sat) by sumC (subscriber, #1262) [Link] Nevermind, It's Ogg Theora and the codecs(win) are here:http://www.illiminable.com/ogg/
tivoized Posted Feb 11, 2006 18:30 UTC (Sat) by smitty_one_each (subscriber, #28989) [Link] A quick google seems to indicate this verb means 'to view content processed by a TiVo'.Maybe a more evocative term, say, 'tivoided', to capture the nullification of freedoms and avoid confusion, could be used.
FSF: GPLv3 Update #2 Posted Feb 11, 2006 18:48 UTC (Sat) by karim (subscriber, #114) [Link]
RMS' comment confirms what I stated earlier in reaction to the first
Again: right cause, wrong venue.
Karim
FSF: GPLv3 Update #2 Posted Feb 11, 2006 20:00 UTC (Sat) by dmantione (guest, #4640) [Link] As long as the vendor can keep its drivers closed source that is true.However, the GPL puts a lot of pressure on that, the only way that you can keep your drivers closed source is by writing an independend work in the sense of the copyright laws. It is being done, but the GPL has also freed a lot of devices so far.
FSF: GPLv3 Update #2 Posted Feb 11, 2006 20:08 UTC (Sat) by karim (subscriber, #114) [Link]
It goes beyond the drivers. Here are some pointers:
The kernel is only part of the picture. There are
Karim
FSF: GPLv3 Update #2 Posted Feb 11, 2006 21:24 UTC (Sat) by dmantione (guest, #4640) [Link] In the case the drivers are closed source, you are right. However, theanti-DRM provisions in the GPL would still be of invaluable use if the drivers are GPL, you are wrong, because then the user can request the key to to be able run a modified GPL'ed driver. The moral of the story is write GPL drivers and fight propietary drivers. That puts a lot of pressure on manufacturers. After all, it is all about exercising pressure, in the end anybody is free to use a propietary OS. DRM-devices cannot be prevented, but pressure can reduce their proliferation. The GPLV2 has opened up a lot of hardware, not because it is a hard requirement, but just because pressure. The anti-DRM provisions in V3 are very welcome IMHO.
FSF: GPLv3 Update #2 Posted Feb 11, 2006 21:36 UTC (Sat) by karim (subscriber, #114) [Link]
I'm sorry, my point is being missed.
Thing is as long as the hardware is being controlled
User-space applications that control hardware using
Karim
GPL useless? Posted Feb 11, 2006 22:11 UTC (Sat) by stevenj (guest, #421) [Link] Thing is as long as the hardware is being controlled from user-space, using what amounts to user-space drivers, and as long as the applications doing this are closed-source, the GPLv3 is entirely useless. I think you're missing the point. The GPL does not and cannot prevent the user from relying on proprietary software other than the GPLed program. Its only purpose is to make sure that the GPLed software itself (or works derived therefrom) is never made proprietary — or in this case, effectively proprietary, if you can modify the source but can't run it due to DRM. You might as well say that because the GPL does not prevent Linux users from relying on MS Word, it is entirely useless.
GPL useless? Posted Feb 11, 2006 22:32 UTC (Sat) by ibukanov (subscriber, #3942) [Link] >Its only purpose is to make sure that the GPLed software itself (or works derived therefrom) is never made proprietary or in this case, effectively proprietary, if you can modify the source but can't run it due to DRM.
But even GPLv2 goes beyond the program itself! Specifically, it prevents redistribution of proprietary code linked with GPL software. As I understand karim, his point is that the user space drivers for Linux effectively bypasses that restriction and GPLv3 would not change that.
So even if Linux would be available only under GPLv3, a device manufacturer could still take advantage of Linux without contributing anything back while putting draconian DRM restrictions into the device.
GPL useless? Posted Feb 12, 2006 6:40 UTC (Sun) by stevenj (guest, #421) [Link] So even if Linux would be available only under GPLv3, a device manufacturer could still take advantage of Linux without contributing anything back This is true for any application running on the kernel, whether it contains userspace "drivers" or not. The GPL can only reach as far as copyright law allows (i.e. according to the definition of "derived work") — this is up to the courts, not up to the license. No version of the GPL has ever prevented you from relying on proprietary software that is not legally a derived work of the GPLed code. (In the case of the kernel, there is also the somewhat fuzzy exception by which Linus currently allows some proprietary drivers.)
GPL useless? Posted Feb 12, 2006 15:49 UTC (Sun) by ibukanov (subscriber, #3942) [Link] > No version of the GPL has ever prevented you from relying on proprietary software that is not legally a derived work of the GPLed code.
Surely as a user I can use whatever proprietary software together with GPL works. But GPL prevents me from compiling a proprietary application against GPL library and distributing the resulting binary.
Consider the case of GNU readline library, http://directory.fsf.org/readline.html, which is available under GPL only. As a user I can compile against it any application, but I can not redistribute the resulting binary under GPL-incompatible license.
Now consider an embedded device with Linux as OS and user-space proprietary drivers. Since Linux is a an essential part of the system, it means that the device software is a very clear case of derivative work. Yet due to this technical trick the manufacturer can distribute the drivers under any license as they are not linked against the kernel.
So GPL is very a strange license. It prevents to include readline into proprietary software when the benefits of the GPL code is mostly in usability of the combined work and when the proprietary code can live without readline.
Yet GPL allows to use GPL-ed Linux as the essential part of the system with non-free drivers when drivers would not simply exist without Linux code.
GPL useless? Posted Feb 12, 2006 17:28 UTC (Sun) by stevenj (guest, #421) [Link] Yet GPL allows to use GPL-ed Linux as the essential part of the system with non-free drivers when drivers would not simply exist without Linux code. It's not at all clear that the GPL itself allows non-free drivers. It's just that the Linux developers have chosen to allow this. The argument that Linus made is that certain binary modules are not derived works of the kernel under copyright law. If he's right, then the GPL has no power over this case and never will. If he's wrong, well, the license has no power unless the copyright holders choose to enforce it. In any case, there are plenty of ways to write one program that benefits from another program without crossing the line into derivative works. It's pointless to criticize the GPLv3 for not prohibiting such situations.
GPL useless? Posted Feb 12, 2006 23:31 UTC (Sun) by ibukanov (subscriber, #3942) [Link] > It's not at all clear that the GPL itself allows non-free drivers.
A user space driver is just an application. As such it can be licensed under any license. What some Linux developers tolerate are binary-only kernel modules that are very different from driver-like userspace applications.
> In any case, there are plenty of ways to write one program that benefits from another program without crossing the line into derivative works.
Linux-based embedded device is IMO very clear case of derivative work.
So GPLv2 prevents distribution of a proprietary program linked against readline with very weak dependency on GPL-ed code. Yet in the same time one can distribute a device that depends on Linux in an essential way (a strong case of a derivative work) and use what ever license for its user-space drivers.
I agree with karim that GPLv3 does not change that. IMO the reason for that is that GPLv3 does not have any rules for hardware that is "derived" from GPL-ed code (the case of many devices with embedded Linux), it only deals with software.
GPL useless? Posted Feb 14, 2006 19:30 UTC (Tue) by sepreece (subscriber, #19270) [Link] There are many kinds of dependency and use that do not make a piece of software (or hardware) a derivative work under copyright law. There is also a fair amount of uncertainty about exactly what does make one piece of software a derivative work of another.
Using published interfaces of a work is very unlikely to create a derivative work, since the interfaces are functional (rather than expressive) and therefore out of the scope of copyright law.
However, the specific boundaries are case law and subject to interpretation.
Linux-based embedded devices typically include Linux (sometimes modified to suit the hardware), device drivers (possibly standard ones, possibly specific to the hardware), and a set of device-specific applications. In the case of a Linux-based phone, for instance, all the code that makes it a phone is application code that just runs on top of Linux, using standard interfaces.
However, GPLv3 draft 1 goes beyond the scope of copyright in the restrictions it imposes. It says, in effect, that if you want to distribute the GPLv3ed work, you must satisfy those restrictions, which seem to include the ability to update the GPLv3ed software and have the device behave the same as it did before. One could argue about whether that restriction includes the operation of other software embedded in the device.
FSF: GPLv3 Update #2 Posted Feb 11, 2006 23:27 UTC (Sat) by Webexcess (subscriber, #197) [Link] If the kernel was licensed GPLv3, and an embedded device was using user-space drivers to implement its DRM, at least a user could build a vendor's kernel from the source and still have a working device. Right now we can't even verify that the version of kernel source provided matches what is installed on a hardware device when that device refuses to boot without a signed kernel.
The new provisions are exactly what would allow the user of a device to know what has been changed in the kernel by forcing the vendor to give their changes back.
FSF: GPLv3 Update #2 Posted Feb 12, 2006 3:54 UTC (Sun) by karim (subscriber, #114) [Link] Just for the sake of argument:
Like Pavel mentioned in the LKML post, nothing in the GPLv3 seems to cover
Again: right cause, wrong venue.
Karim
FSF: GPLv3 Update #2 Posted Feb 12, 2006 9:12 UTC (Sun) by khim (subscriber, #9252) [Link] This is totally useless argument. If there are (or will be) demand for product with modified kernel and the only problem will be need to replace ROM... and it'll be legal... there will be people who'll do this for masses. Think PlayStation and mod-chips (and it's only legal in some countries to modify PlayStation! with GPLv3 it'll be legal world-wide!). Yes, GPLv3 is not a solution - but that's half of a solution and it's more then we had before. P.S. And don't forget that said computer manufacturer will be forced to produce useable ROM from the start. And will be forced to replace defective devices and resolder ROM where new firware will be enough for competitors. In short: replacement of flash with ROM is costly! Not everyone will be inclined to do so just to fight GPLv3.
FSF: GPLv3 Update #2 Posted Feb 13, 2006 3:52 UTC (Mon) by karim (subscriber, #114) [Link] Forgive my asking: How many actual consumer end products you've actuallyparticipated in developing? Based on my "limited" knowledge and experience of such things:
1) Consumer devices that ship with ROMs are not that uncomon. I've played
2) If the GPLv3 is half a solution, then it's no solution at all. There
3) Hardware manufacturers will not pull any punches to use as much
Karim
FSF: GPLv3 Update #2 Posted Feb 13, 2006 7:35 UTC (Mon) by dmantione (guest, #4640) [Link] You still haven't understood the point about captalism. Using GPLsoftware is a competitive advantage, because you don't need to spend a lot of time developing the software. You can develop all of your own drivers. You can develop hardware that can be disabled before the OS boots. But it costs money. With GPLv3 there is no such advantage regarding DRM anymore, you can no longer add a few lines to the display drivers to do Macrovision and be done. You must at least write the driver from scratch and keep it propietary. Even then you are in legal gray area. Sure, they can write all it themselves. They can write their own OS. But if they want DRM they cannot take the competitive advantage by abusing the sweat and tears of the free software community.
FSF: GPLv3 Update #2 Posted Feb 13, 2006 12:34 UTC (Mon) by khim (subscriber, #9252) [Link] But if they want DRM they cannot take the competitive advantage by abusing the sweat and tears of the free software community. Oh, you can, you can. Karim descibed it all very well. You can do this, you can do that and you can plug thing there. But... in the end it does cost real money. You need more money for development, more money for support, etc. And most hardware manufacturers do not need working DRM since working DRM is competive disadvantage. Do you remember ASUS's DVD-ROM's who "by mistake" cleared RPC-2 counters when button was bressed on power-on ? Later they fixed this bug (but it took few years) but I'm pretty sure it'll not be last case. If there are two products: one with perfect DRM (and costly one due to need to circumvent the GPLv3) and one with sloppy one - product with sloppy one will be bestseller. It's that simple... P.S. Dreamcast, GameCube, Playstation and others are different: the same guys who build hardware benefit from DRM. Most other manufacturers are only implement DRM in any form to avoid lawsuits... P.P.S. Even with GameCube, Playstation it's not exactly clear. There are 10-20 times more PlayStations sold then GameCubes since PlayStation comes complete with mod-chip and you can play pirated games. Number of games sold is only 3:1 or may be 2:1 (since most are playing pirated games on PlayStation and play 2-3 legally bought games in GameCube and then throw it away or sell it) but still there are more games for PlayStation sold then for GameCube.
FSF: GPLv3 Update #2 Posted Feb 12, 2006 7:58 UTC (Sun) by dmantione (guest, #4640) [Link] > Thing is as long as the hardware is being controlled> from user-space, using what amounts to user-space > drivers, and as long as the applications doing this > are closed-source, the GPLv3 is entirely useless. That is very well a possibility, but there are a lot of things that cannot be done from user space, like interrupts and PCI bus mastering. That is again pressure on the manufacturer to do things in kernel space and therefore pressure to make it GPL. > User-space applications that control hardware using > memory-mapped registers are not that uncommon, and > whether or not the driver doing the mmap() operation > is GPL or not is inconsequential. You'll have a > device where you can run a kernel to play around in > RAM, but that's about it: no display, no network, no > decoding ... IOW, GPLv3-compliant DRM. If the display driver is propietary, yes. If the network driver is propietary, yes. If the decoding driver is propietary, yes. But why are those companies using Linux? Because it saves them a lot of development time. Capitalism does the rest, companies using GPL driver have an advantage against the one who don't. Under GPL 2 they can modify the display driver to support Macrovision analog coding and sign it. Under GPL3 not, there the user has the right to run a modified driver and request keys. Under GPL3 the only way you can impose DRM is to write your own propietary display driver and disable Macrovision permanently before boot. That requires a lot of money, since you need to be able to design your own graphics hardware.
FSF: GPLv3 Update #2 Posted Feb 12, 2006 8:00 UTC (Sun) by dmantione (guest, #4640) [Link] Sorry, the manufacturer would have to *enable* Macrovision permanentlybefore boot.
FSF: GPLv3 Update #2 Posted Feb 13, 2006 0:21 UTC (Mon) by jamesh (guest, #1159) [Link] Note that you can write GPLv3 code that implements Macrovision (or whatever other DRM system). The only problems are:
FSF: GPLv3 Update #2 Posted Feb 12, 2006 9:21 UTC (Sun) by khim (subscriber, #9252) [Link] Under GPL 2 they can modify the display driver to support Macrovision analog coding and sign it. Under GPL3 not, there the user has the right to run a modified driver and request keys. Even with "user-space drivers" it's easy enough to intercept macrovision request and replace it with NOP. Yes, you can fix it with true crypto (and even then you'll be forced to do this right) but again: cost of device will go up, up and up. If you are saying that GPLv3 is not enough alone to prevent tivoization, then you are of course right. But GPLv3 will crack the door somewhat. To open door the rest of the way will be task for hackers - they are doing it today even without GPLv3 help and it'll be easier in the future with help of GPLv3. What's not to like ? GPLv3 cannot solve the problem by itself, true but it's good part of the solution... It makes tivoization more costry - and that can only be called "good thing", right ?
FSF: GPLv3 Update #2 Posted Feb 13, 2006 3:35 UTC (Mon) by karim (subscriber, #114) [Link] In as far as having effective user-space drivers, then try playing with the-rt series. In due time that's exactly what -rt will do: enable developers to create proprietary userspace applications that can react deterministically to hardware events: IOW true user-space drivers.
With regards to manufacturers writing their own drivers. This has never
Back to the GPLv3, I think I've said what needed to be said. If anyone
Again: fighting DRM is a worthy cause, and I encourage you to find ways to
Karim
FSF: GPLv3 Update #2 Posted Feb 13, 2006 7:40 UTC (Mon) by man_ls (subscriber, #15091) [Link] Conceding, to any extent, that there are ways around GPLv3 for implementing DRM is admitting that the DRM clauses in said license are useless. Because any possible workaround, and there are many, will be used.There are workarounds for a lot of things in life, yet people don't know these or don't bother at all. If only lazy or incompetent hardware manufacturers are ever stopped from implementing DRM on their devices using code under the GPLv3, then probably 90% of the devices on the market will end up DRM-free. And remember that with DRM, quite often it is enough to have a free device to effectively break the chain of restrictions. If my application can print a protected PDF then the protection does not work. Likewise, if my device ignores the broadcast flag then said flag is useless.
FSF: GPLv3 Update #2 Posted Feb 12, 2006 18:48 UTC (Sun) by jpick (guest, #29470) [Link] If you drop code I released under the GPLv3 license onto a DRM enabled device, even if it's just user space code -- I can sue you, because I haven't granted you permission to use that code for the purpose of restricting people ability to copy copyrighted media.
That's how the license works.
FSF: GPLv3 Update #2 Posted Feb 13, 2006 3:41 UTC (Mon) by karim (subscriber, #114) [Link]
Wow. That's just brilliant. Gratuitous legal threats on an internet forum.
Karim
Threats? Posted Feb 13, 2006 10:15 UTC (Mon) by man_ls (subscriber, #15091) [Link] I'm sorry, I don't see any legal threats there, just discussion of a theoretical point. Maybe in the US it's different, but here where I live legal discussions are still allowed. Of course they do not constitute the start of any "legal process".
FSF: GPLv3 Update #2 Posted Feb 13, 2006 15:35 UTC (Mon) by jpick (guest, #29470) [Link] Hey dude, chill...
It's a hypothetical example. I put the wording in the "first person" so it was more immediate, and easier to understand. It got your attention, right? That's what they taught me to do in all those English classes I took way back when I was in school.
It was not a threat to you personally, except in the hypothetical case where I released GPLv3 code (which I have not done) and you used it in a shipping DRM device (which you have not). If in fact I do release some GPLv3 code (very likely, in a year or so, once the license is approved), and you actually do use it in a shipping DRM device (boo, hiss), I'd probably settle out-of-court for a beer. :-)
When I read a legal license, the only way I can figure it out in my mind is to think of the hypothetical scenario where it actually comes into play -- in front of a judge.
I've spent the last five years working in Silicon Valley. I've discovered that when you throw a rock, you are more likely to hit a rich lawyer than an engineer. This legal stuff matters...
FSF: GPLv3 Update #2 Posted Feb 14, 2006 3:55 UTC (Tue) by karim (subscriber, #114) [Link] Well, nice to see you're good-spirited. It's hard to make out what anyone'strue colors are with terse statements such as those earlier, but I'm glad to see a positive tone.
So have fun, keep up the good spirits and let the lawyers through the
Karim
FSF: GPLv3 Update #2 Posted Feb 11, 2006 23:34 UTC (Sat) by dvrabel (subscriber, #9500) [Link] The GPL v3 draft refers to "recommended or principal context of use". For a kernel in your proposed 'all drivers are proprietary user space applications' system this principle context of use would be executing (correctly and with full capabilities) said closed source software.
Also, if you only post your comments to LWN or linux-kernel then the FSF will never understand your point.
FSF: GPLv3 Update #2 Posted Feb 12, 2006 3:49 UTC (Sun) by karim (subscriber, #114) [Link]
The "recomended or principal context of use" of a kernel is to run user-
In this, the unsigned kernel will exhibit 100% identical behavior. What
In as far as convincing the FSF of anything, believe me I've tried
Karim
FSF: GPLv3 Update #2 Posted Feb 12, 2006 9:24 UTC (Sun) by khim (subscriber, #9252) [Link] And
these user-space applications will operate the same way and successfully
do so: 1) is only possible if (when) kernel allows it. 2) is not possible without 1). So at least GPLv3 kernel will be very good first step for hackers. Worthy goal by itself...
FSF: GPLv3 Update #2 Posted Feb 13, 2006 4:04 UTC (Mon) by karim (subscriber, #114) [Link] Having access to the registers of disabled hardware is useless. Please goback and read the pointers I listed earlier. If a device is manufactured as I described then having the ability of mmapping the registers will not be helpful to you in any way. You'll still have a dead device.
Again, attacking DRM is a good thing. Believing that the GPL can be used
Karim
FSF: GPLv3 Update #2 Posted Feb 13, 2006 7:20 UTC (Mon) by dmantione (guest, #4640) [Link] In the case of user space drivers the registers will be enabled. Do notmix one situation with the other.
A couple of straw men? Posted Feb 13, 2006 8:01 UTC (Mon) by xoddam (subscriber, #2322) [Link] > If the GPLv3 is half a solution, then it's no solution at all.> There are no half measures. If it's not a effective anti-DRM > mechanism, then its DRM clauses are empty promises never to > be fullfilled. No GPLv3 program can be subjected to digital restrictions which take away the freedom of its users (to use it for any purpose or to study it, modify it, improve it and distribute it), except in violation of these clauses. In what way is this a half-measure? > The "recommended or principal context of use" of a kernel is to > run user-space application. You seem to be arguing from a presumption that the effectiveness of the anti-digital-restriction clauses of the GPLv3 will have effect only with respect to operating system kernels, or that the licence tries to exercise some non-existent rights over the hardware it runs on. Both these ideas are unfounded. It's a copyleft licence intended to be applied to programs of any type. The Linux kernel is the one piece of prominent copylefted software whose lead developer has categorically stated that he *doesn't* want to use version 3 of the GPL. The new anti-digital-restriction provisions protect users of GPL'd programs from digital restrictions by providing that no use of such a program may be considered 'circumvention' under DMCA-type laws, and by protecting the users' right to patch the software and continue to run it. The licence isn't capable of protecting other programs, such as user-space programs running on a GPLv3'd kernel. That's not a problem and it's hardly the point. Once upon a time there was no copylefted software outside the FSF; did that make the GPL a half-solution? No, because users who valued their freedom chose GPL'd software, as they will continue to do.
FSF: GPLv3 Update #2 Posted Feb 12, 2006 7:31 UTC (Sun) by Arker (guest, #14205) [Link] I can guarantee you the FSF understands. The problem is that copyright only goes so far -and in the bigger picture, that's probably a good thing. The point here is to do as much as possible to prevent the perversion of Free Software. The fact that it can't be eliminated, surely, does not argue that it shouldn't be minimised?
Right cause AND right venue Posted Feb 13, 2006 4:06 UTC (Mon) by felixfix (subscriber, #242) [Link] You have it backwards. I GPL my free code not to force manufacturers to tell me how things work, but to prevent them from using my code without a fair trade. If they want to save development time, they must pay by permitting others to save time by re-using their hardware. If they want to keep their hardware secret, they can't use my software.
Far too many people make this same mistake. Please don't propogate it.
Right cause AND right venue Posted Feb 13, 2006 4:14 UTC (Mon) by karim (subscriber, #114) [Link] The GPL has never been about hardware. It's about forcing those thatreceive your code to continue what you had started: sharing the source with those down the chain. It's about making sure no one can get your code, add things to it, keep those things to himself and then only distribute the result without the code. In fact, if you read what made RMS start this whole software freedom thing you'll find that it's almost exactly that: disgust with those that took from others without contributing back.
What hardware lies beneath is not something I can find in the GPLv2.
Karim
Right cause AND right venue Posted Feb 13, 2006 4:25 UTC (Mon) by felixfix (subscriber, #242) [Link] I never said the GPL was about hardware. I mentioned manufacturers and that includes hardware, software, any kind of ware. The GPL is about giving back to those who saved the manufacturers time, regardless of what kind of ware it is.
Right cause AND right venue Posted Feb 13, 2006 4:34 UTC (Mon) by karim (subscriber, #114) [Link] The GPL covers the software. It does not cover the hardware. As a licensorof software, you have no right to the hardware others manufacture. No more that of consumer devices than the VHDL used to make the CPU you're running your software to read these words.
The GPL doesn't talk about anyone's saving of time. It's about forcing 3rd
Follow the LKML thread on this. Linus has gotten this one down much better
Karim
Right cause AND right venue Posted Feb 13, 2006 4:54 UTC (Mon) by felixfix (subscriber, #242) [Link] What a bunch of weaseling! Of course the GPL doesn't mention saving time. Nor does it mention that 2 + 2 = 4. But 99% of the reason for re-using code is to save time, and you can measure that time using any basic arithmetic you want, even if that arithmetic is not mentioned in the GPL.
And of course the GPL doesn't cover the hardware. But RMS wanted the software which ran the printer hardware. Is that too much a stretch for your narrow words? What would be the purpose of wanting their software if he can't run it on their hardware?
If they want to re-use my software, they have to let me re-use it myself on their hardware. That is the spirit of GPL v2 and I hope it becomes the letter of GPL v3.
Right cause AND right venue Posted Feb 13, 2006 7:43 UTC (Mon) by dmantione (guest, #4640) [Link] Linus is a fool here. He states obviously wrong things: keys to determinethe origin of a program are not necessarily the keys necessary to run a program. His keys not at least. But he is mostly a fool because he fails to recognize at leats one of the many advantages in v3, and fails to name a disadvantage that holds.
Right cause AND right venue Posted Feb 13, 2006 8:57 UTC (Mon) by Wol (guest, #4433) [Link] READ THE FOUR FREEDOMS !!!
The whole purpose of the GPL is to make sure you CAN RUN THE CODE!
And if the hardware is DRM'd such that you cannot run your altered copy of the code then the hardware manufacturer is in breach of the spirit of the GPL. That spirit has been there for 20 years.
The whole point of the GPL v3 is that technology and the law has done an end-run around v2. The FSF has brought out v3 to counter that.
At the end of the day, this whole storm in a teacup is simple, and you seem to be wilfully misunderstanding it. The GPL gives you various rights, including BOTH the right to modify the code AND the right to run the modified code. DRM takes away that second right. v3 gives it back to you. And the GPL has been giving you those rights for 20 years - this DRM stuff is no change in the spirit of the GPL, it's just a change in the wording to match a change in circumstances.
Cheers,
The incumbent Posted Feb 13, 2006 10:25 UTC (Mon) by man_ls (subscriber, #15091) [Link] But that doesn't mean that you should be able to run it on the hardware they designed.This is the paragraph of the GPLv3 draft under discussion: "any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications."Good luck defending from this (if you ever have to). You can use user space programs, binary drivers or whatever; the result should be a funcioning device. I don't see any difference between hardware and software, and certainly disabled hardware is not functioning hardware.
The incumbent Posted Feb 14, 2006 19:53 UTC (Tue) by sepreece (subscriber, #19270) [Link] Trivial counterexample, w/r/t to modifying the kernel and reloading the modified version (you can substitute any GPLv3ed component for the kernel in the example). If the user space software on the device checksums the kernel before it starts to run, then your change to the kernel will change that checksum and keep the user-level software from running. Since the change in the checksum is the result of your changes (that is, the user-level software runs as it did before except "as altered by your modifications"), the license would appear to be satisfied.
Not so trivial Posted Feb 14, 2006 20:56 UTC (Tue) by man_ls (subscriber, #15091) [Link] In your example I did not modify the user-level software. So how come it does not run as it did? If I do modify it and stop it from working it would be ok, of course; but here the software decided it didn't like my changes and disable the device. Clearly not allowed.Yes, you can try to weasel your way out of the license; but it is not so easy. The intentions of the licensor and of the designers of the license are clear; Eben Moglen summed it up by saying "plays all the same movies". User-space or kernel-space, kernel or driver, hardware or software, it cannot decide to stop functioning; the "principal context of use" should work as it did before. So you can say that the wording of the GPLv3 could be clearer in regards to DRM, amd maybe it's necessary. But if the licensor comes and explains her intentions, and they are reasonable and have been made clear on public record for some time, the licensee is busted.
Not so trivial Posted Feb 15, 2006 0:12 UTC (Wed) by sepreece (subscriber, #19270) [Link] Well, there are three issues, at least as to the letter of the license.
The first is, as noted, that in the example it is, in fact, your change that results in the other software not working. Note that this is less than completely clear, because it IS possible (even easy) to change the GPLv3ed software in ways that keep the add-on software from working (because you change semantics of a service or break something that the add-on (non-GPL) software depends on.
The second is that it's not clear that the scope of "working as before" includes, or can include, more than the GPLv3ed software.
And, the third is as noted in a comment below, that the meaning of "you" is ambiguous - it isn't clear whether it refers to the licensed distributor or to the recipient of the distribution.
I thought their intention was clear, despite the ambiguities, until I read one of the comments on the GPLv3 draft site. Now I'm less sure.
Not so trivial Posted Feb 15, 2006 6:55 UTC (Wed) by man_ls (subscriber, #15091) [Link] I thought their intention was clear, despite the ambiguities, until I read one of the comments on the GPLv3 draft site.Which comment, if you'd be so kind? I think intention is the crucial part; the wording can be solved in time for the definitive version.
Not so trivial Posted Feb 15, 2006 16:00 UTC (Wed) by sepreece (subscriber, #19270) [Link] The post below, by the user "idra". I took this person to be an FSF person, because he/she had apparently had the power to rearrange all the accumulated comments on that paragraph as children of a single parent comment. The note from idra said:
I too asked myself about this.
I propose to change the wording of the paragraph to something like:
Complete Corresponding Source Code also includes any encryption or
That language seems to indicate that the "you" means the distributor, not the recipient.
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 13, 2006 7:17 UTC (Mon) by xoddam (subscriber, #2322) [Link] Karim,You are correct that the FSF is using the GPL to combat digital restrictions, but you are wrong to say they don't understand the situation. They know very well that a copyleft licence only confers the right to prepare and distribute copies and derived works. It confers no power whatsoever over any functionality provided independently of the copylefted work, except inasmuch as the law might consider 'combined' works to be 'derived' ones. A simple but inaccurate summary of the effect of copyleft as it applies to a program would be, 'you may copy this program and make modifications, providing that all your copies and revisions are free software and are supplied under this licence'. The definition of 'free software' is an enumeration of end-user freedoms, including freedoms, one of which is the ability to prepare and run a modified version of the software without loss of functionality. It is clear that if the end user does not have the wherewithal to prepare replacement software that actually works, the software cannot be considered to be free. This means that 'firmware' supplied on ROM is not free software unless the end user can create and install a replacement ROM. It also means, *obviously*, that software supplied under TPM constraints is not free unless the user can create and install a replacement. It seems that the definition of 'source code' to include a *cryptographic* key is an attempt to preserve a historical distinction between 'firm' ware (whose replacement *requires* a hardware modification, but is legally unencumbered) and digitally restricted 'soft' ware (which can be replaced without interfering with the machine, but risks prosecution under the DMCA unless the key is provided by the original maker of the machine). The GPL in its various versions and drafts is an approximation to the summary above. It doesn't define 'free software' in the general sense, which I'm starting to see as a flaw in itself given the loopholes you and others have pointed out. It has never been a GPL violation to supply software on ROM, which has hitherto not been seen as a problem, despite the obvious freedom deficit for the majority of end users. But ROMs were never first and foremost a means to thwart users, they were just the cheapest way to do the job. If makers of devices are likely to start using ROMs for no better reason than to deny their users' freedom, IMO the FSF would do well to emphasise the non-free nature of read-only software! Treacherous hardware, on the other hand, is explicitly about denying freedom to the users of the device, and as such it is important that the makers of such devices be called on it. The FSF is doing a pretty good job of bringing the issue into the sphere of public debate and 'consumer' awareness. The anti-digital-restriction provisions of the GPLv3 are part of this public-relations work, in the same way as the GPL has always been used to raise awareness as well as to license software. As for your other comments about latch-protected hardware and so on: you are absolutely correct, if digital restrictions prevent the use of certain hardware components when unsigned software is in use, but the GPLv3-licenced software on the device still works flawlessly, the anti-DRM provisions of this draft do not affect this use case. The user was obviously not promised a DRM-free implementation of the hardware functionality in question. The copyleft provided by GPLv3 can only protect use of the GPLv3'd software, not any other features of the device. Hardware manufacturers would be free to use software licensed under this draft of the GPLv3 for functionality which does not implement digital restrictions, even on treacherous devices, providing that the user is able to prepare and run modified versions of the code in question. 'Device makers' are NOT a separate category from anyone else who might violate a copyright licence! The anti-digital-restriction provisions of the draft GPLv3 serve only to ensure the freedom of the users as regards the work covered by the licence, and cannot reasonably go further. It is the public awareness and lobbying work of the FSF which will continue to fight digital restrictions in other corners. They should, however consider that no GPLv3-licensed program may be considered part of a 'technical prevention measure' for the purposes of such laws as the proposed CBDTPA, because the users are given these programs with their freedom intact.
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 13, 2006 11:17 UTC (Mon) by ibukanov (subscriber, #3942) [Link] > The copyleft provided by GPLv3 can only protect use of the GPLv3'd software, not any other features of the device.
But why GPL covers only software? IMO a device that was designed to run only Linux and that depends on Linux in an essential way is a derivative work. My not-a-lawyer understanding of this is that the device as a whole, not only its software parts, needs to confirm to GPL when distributed. But since GPL even in v3 talks only about software, not about any derivative work, one can still put DRM on the device.
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 13, 2006 23:36 UTC (Mon) by xoddam (subscriber, #2322) [Link] > But why GPL covers only software?It doesn't, which gives rise to the loophole I mention above. The only ways in which the category of 'software' applies to everything covered by the GPL are (a) the sense in which the work might exist in various forms, one of which is "the preferred form of the work for making modifications to it", and (b) the sense in which the work has a *function* as well as a form, for users must be permitted to *use* the work, including their modified versions, for any purpose. Typesetting source for books or for musical notation, or hardware designs (for *any* kind of device) are just as well-defined and just as suitable for protection under the GPL as are programs; but the meaning of 'free software' (which is *not* defined in the licence) is narrower than 'things which may be covered by this licence'. This means that it is possible to distribute works under the terms of the GPL which are not free software (such as books, ASICs, ROMs, or for GPLv2, TPM-encumbered programs). The corollary is that the licence is much more broadly applicable than to 'mere' software. If the licence were to define 'program' more explicitly (in terms of the susceptibility of its most *useful* forms to digital copying, for instance) and state extra conditions which must hold if the licenced work is a program (ie. that the end user must have all four defined Software Freedoms), it would close such loopholes at the cost of making it more difficult to combine GPL'd programs with works under other licences. This would also preclude adaptation of GPL'd works into other forms which lie in the grey area between 'program' and hardware, such as ROMs and ASICs. IMO that's a price worth paying, if device manufacturers are going to start using ROMs and treacherous program modules as a means to restrict the freedom of end users. > IMO a device that was designed to run only Linux and that depends > on Linux in an essential way is a derivative work. My not-a-lawyer > understanding of this is that the device as a whole, not only its > software parts, needs to confirm to GPL when distributed. Well that's for lawyers and the courts to decide. My understanding is that the FSF has no intention of pursuing anything so uncertain; I don't believe that any copyright infringement cases have ever rested on such a broad interpretation of 'derived work'. As long as the specific work covered by the GPL is distributed according to the terms of its licence, the remainder of the device can hardly be considered to violate the copyright of GPL portions. > But since GPL even in v3 talks only about software, not about > any derivative work, one can still put DRM on the device. Well, yes. It is not the intention of the FSF to exclude an entire class of hardware from *ever* running Free Software. On the contrary, it has always been their goal to *bring* freedom to platforms of all types, whether they be hardware like Sun workstations or TPM-encumbered gaming consoles, or virtual platforms like Java or Flash. The FSF is also entirely in favour of programs (such as deCSS) which implement DRM schemes, providing that they are *free software*, which breaks the whole premise of digital restrictions on the end user. They would say so explicitly without the caveat 'where legal', if that did not risk prosecution for 'contributory infringement'.
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 14, 2006 16:05 UTC (Tue) by ibukanov (subscriber, #3942) [Link]
> The FSF is also entirely in favour of programs (such as deCSS) which implement
Thanks for this remainder. Indeed one of the goals of FSF is to make sure that free software remains free and this is one of the reasons behind GPLv3. As I see it now the license update has *nothing* to do with DRM.
What the draft of GPLv3 does among other thing is to address recent developments that allows through technical or legal measures to make GPLv2 software non-free. That is, it tries to deal with code signing that prevents a user to run a modified version of a program release under GPLv2 and with legal tricks like using DMCA to prevent re-distribution of modified sources.
The fact that closing these loopholes also complicates life for a manufacturer who wants to use free software in boxes with DRM is just a consequence, but not a primary or even secondary objective of the draft.
This also explains the apparent discrepancy when GPL does not allow proprietary code linked against GPL library even if the library brings only trivial benefits while even with GPLv3 OS one can use it in a DRM-ed box. In the first case user can not exercise the freedom of running the proprietary code against the modified library but in the second he can even if the modified version would be useless due to box' design.
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 14, 2006 3:50 UTC (Tue) by karim (subscriber, #114) [Link] First, I'd like to thank you for taking the time to write such a response.I don't disagree with most of what you said. In fact, I think we agree on more issues that disagree.
However, with regards to the FSF, here is a statement from Richard taken
I personally do not believe Richard capable of intentionally misleading
Statements like these present a very bad image of the FSF. They show an
Not to mention that, as this thread has demonstrated, it leads a lot of
In as far as the argument that protecting individual components from being
So, in the end, what really remains: nothing of substance. Linus said it
And if some believe that the meager consolation is that we can now
Really, believe me when I say I hate DRM as much as you do if not even
Karim
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 14, 2006 5:50 UTC (Tue) by xoddam (subscriber, #2322) [Link] > "... you will really be able to run the modified versions on your> Tivo and they will really run." > > Clearly Richard seems to imply that the ability to run a modified > kernel will allow you to do whatever you want with said Tivo. I don't agree that he has implied that. He is talking about an actual device which has exploited a loophole in version 2 of the GPL to prevent the user from exercising the freedom which that licence was intended to grant. The revised licence will close this particular loophole; if a device maker were to choose to deliver a Tivo-like device running GPLv3 software, the users would be allowed to exercise the freedoms granted by the licence of those programs. The licence *can't* say anything about functionality those programs don't provide. You have explained very clearly how it is possible to use free software on a machine which implements digital restrictions *independently* of the free programs on the device. You have even explained how device makers can actually provide the freedoms protected by the licence of the free programs at the same time as using *other* mechanisms -- hardware and non-free programs -- to implement digital content restrictions. What device makers *cannot* do is use a GPLv3 program to take away users' freedom without violating the terms of the licence, and that is as much as we can possibly ask of a copyright licence on a program. The revised GPL *will* preserve the users' freedoms with respect to GPL'd programs. If the device is cleverly designed to enforce digital restrictions with respect to hardware and non-free software on the device at the same time as permitting the use of GPLv3 programs in accordance with the licence, this is not functionally very different from using completely separate devices for the two purposes. It *is* different from the perspective of the determined reverse engineer; that's not a meagre consolation, just an observation. > Statements like these present a very bad image of the FSF. They show > an FSF that is entirely out of touch with the technical capabilities > of embedded system designers and THAT is very bad for anyone > championing free software. You're saying the FSF thinks they've achieved something they haven't. They never wanted to prevent the use of free software on devices which implement DRM; on the contrary, they want to bring freedom *to* these devices, and continuing to permit free software to run on them is vitally important to that end. They've closed a loophole in the licence which allowed the denial of end-users' freedom *in respect of GPL'd programs*. What *you* have demonstrated is that embedded system engineers are technically capable of complying *both* with the requirements of free software licences to grant users' freedoms *and* with the demands of the MPAA to restrict them. That's an accolade for the ingenuity of system designers, not a point scored against the FSF. I think you've read too much into Stallman's particular example of the Tivo. > as this thread has demonstrated, it leads a lot of true free software > developers to believe that the FSF has actually helped them win one > against DRM. Some people have indeed misrepresented the anti-DRM clauses, not least Linus Torvalds. The wording in the licence is clear, however; there's little we can do to stop people who mouth off before they've looked twice at what's actually written, except to call them on it and explain more clearly. Stallman isn't the idiot here. The fight against digital restrictions isn't over here, it has hardly begun. IMO the anti-digital-restriction clauses in the draft GPLv3 have closed an important loophole. In the same position (but IANAL, nor am I RMS for that matter) I would have gone further, to the extent of disallowing distribution of copylefted programs on ROM or translation into hard-wired circuitry. They've shown admirable restraint, actually, without exaggerating the effect of these clauses. > So, in the end, what really remains: nothing of substance. On the contrary. There is now a licence which can protect copylefted programs from being made non-free by treacherous hardware. > banking on such things as the GPLv3's DRM clauses to stop DRM > makes us look like a bunch of idiots. Don't do that then :-) Seriously, the DRM clauses aren't meant to stop DRM, they're meant to preserve the freedom of users to use copylefted programs as the licensor intended. No-one will argue that the Tivo respects the spirit of the GPL. > ... fighting it really requires understanding where it comes > from. And it doesn't come from the gizmo manufacturers. You are *absolutely* correct here. The 'gizmo manufacturers' are only doing what they have to do to operate in a market which has been cornered by a bunch of copyright thugs. That *is* where the FSF (and of course the EFF) are fighting the fight. But providing and protecting free software is the first mission and the first obligation of the Free Software Foundation. With these protections free software can continue to be available, and more importantly continue to be *free*, even if the present battle against DRM is lost completely and we find ourselves in a nightmare world with universally treacherous hardware.
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 14, 2006 16:21 UTC (Tue) by ibukanov (subscriber, #3942) [Link] > In the same position (but IANAL, nor am I RMS for that matter) I would have gone further, to the extent of disallowing distribution of copylefted programs on ROM or translation into hard-wired circuitry.
You do need this to close this read-only GPL-ed software loophole. One can just require that for a reasonable price a user of a box with free software should be able to get the same box with modified code.
I.e. if a manufacturer sells boxes with ROM-only free-software, then he should either provide an option to get a ROM chip replacement that the user can put in the box for the price of chip+postage+small fee for ROM burning. Or, if ROM chip can not be replaced, then the manufacturer should provide another box with the modified software for the price of another box+postage+small service fee.
With such requirement one do not even need to explicitly mention boxes that only boots signed code. In this case manufacturer would have to either provide keys or allow me to upload the code to some website to get a signed version back.
Closing the GPL loophole: it doesn't define 'free software'. Posted Feb 18, 2006 2:26 UTC (Sat) by pimlott (guest, #1535) [Link] I find Karim more convincing on what the FSF represents to accomplish with the anti-DRM clause. The FSF are not impractical idealists who take merely symbolic stands. For many years, when asked why the FSF wasn't concerned about embedded software, RMS would answer: It's practically impossible to replace the software, so it's not a real freedom issue. Today, of course, it's possible to replace the software in many devices. So when the FSF puts their effort into drafting an anti-DRM clause, I have to think they believe it will provide an effective freedom.
Karim has (rather brilliantly, IMO) shown that device makers can comply with the anti-DRM clause while making modified versions of the software completely useless on the device. This is no effective freedom at all for the purchaser of the device. The anti-DRM clause strains to prevent the device from retaliating against the modified software. Karim has show that it can retaliate forcefully. You claim that the anti-DRM clause is a symbolic victory, because at least one can run a modified version of the GPLv3 software--never mind that it's useless. I say that the FSF isn't about symbolic victories, it's about real freedom.
So Karim has convinced me that the anti-DRM clause is a mistake. Don't forget that the GPLv3 should be around for a decade. If embedded device makers (and other suppliers of closed systems) implement Karim's treacherous scheme in year one, that clause will be pretty embarrassing for the next nine. I think the FSF should decide whether to go a little further with the anti-DRM clause and outlaw Karim's scheme (no opinion here on whether that is legally possible), or give up.
What Karim has and has not shown Posted Feb 19, 2006 23:48 UTC (Sun) by xoddam (subscriber, #2322) [Link] > Karim has (rather brilliantly, IMO) shown that device makers can> comply with the anti-DRM clause while making modified versions of > the software completely useless on the device. He has done no such thing. Karim has (rather brilliantly, I agree) shown that device makers can comply with the anti-digital-restrictions clause of GPL'd software on a device which implements digital restrictions, *providing* that the user is not restricted thereby from using, modifying and copying the GPL'd software. What Karim has has *not* shown is that a distributor may comply with the GPLv3 whilst rendering modified versions of the covered work useless. The licence text "such that its functioning in all circumstances is identical" explicitly disallows such disabling of a GPL'd work. (As sepreece has pointed out, the wording here could be better and it is therefore unlikely to remain in the present draft form. Anything we speculate on here is obviously contingent on the final licence text) Since the GPLv3'd software would be user-modifiable (and the user would be protected against DMCA-type penalties), any digital restrictions scheme implemented with GPLv3'd software may be removed by the user -- so a device maker would be best advised to use non-GPL'd software for this purpose. > If embedded device makers (and other suppliers of closed systems) > implement Karim's treacherous scheme in year one, that clause will > be pretty embarrassing for the next nine. The purpose of the GPL, including the digital restrictions clause, is to preserve the freedom of users to share and improve GPL'd software. All a copyright licence can do is grant permission to copy and modify something *where this would otherwise be prohibited by law*. The general fight against DRM must proceed elsewhere. In the meantime it's now the year *before* year one, the licence is still being drafted, and all these considerations are already being pointed out. Early days yet.
What Karim has and has not shown Posted Feb 20, 2006 22:17 UTC (Mon) by pimlott (guest, #1535) [Link] What Karim has has *not* shown is that a distributor may comply with the GPLv3 whilst rendering modified versions of the covered work useless. The licence text "such that its functioning in all circumstances is identical" explicitly disallows such disabling of a GPL'd work.Well, this question centers around the interpretation of "useless" and "identical functioning". How far can the device degrade the usefulness of the modified GPLv3 software without triggering the anti-DRM clause? Karim proposed a device that "wouldn't allow much of anything but booting your kernel and xoring bits in RAM with no access to display or networking or anything useful". That makes the kernel (or any other bit of software) useless to me--the only way you know it's even running is it gets warm and the battery eventually dies. :-) But it's hard to see how this violates the "identical functioning" requirement (do you think so?), and if it does, I expect there is a more subtle ploy that doesn't yet has the same effect.
What Karim has and has not shown Posted Feb 21, 2006 0:36 UTC (Tue) by xoddam (subscriber, #2322) [Link] > Karim proposed a device that "wouldn't allow much of anything but> booting your kernel and xoring bits in RAM with no access to display > or networking or anything useful" IMO that would absolutely violate the licence, if the same program unmodified would be able to use the I/O devices in question. That's certainly the intention: Moglen said (in the talk, Ciaran O'Riordan's transcript is linked below), 'I would translate that for vernacular use, into "plays all the same movies".' If the legalese doesn't already mean what Moglen says it does, I'm sure he'll fix it before we reach GPLv3-rc1. Karim also suggested, less extremely, a device where GPLv3 software is present, usable and free, but is prevented from reading the cleartext of digitally restricted media (regardless of whether, and by what key, it is signed). That would not violate the licence. The point I'm trying to make is that the licence is intended to protect the freedom of the user with respect to the licenced software, not to prevent the use of DRM altogether.
What Karim has and has not shown Posted Feb 21, 2006 3:05 UTC (Tue) by pimlott (guest, #1535) [Link] IMO that would absolutely violate the licenceSo this is what it comes down to: The device maker might argue that the kernel itself is behaving identically, only the other components are declining to talk to it. Or, more subtly, say, the display could continue to talk to the kernel as if operating normally, but actually remain blanked. It is clear here that the device as a whole is functioning differently, but is the kernel? I and I think Karim are afraid that the answer is no, and that this loophole cannot be closed.
I've made a transcript Posted Feb 12, 2006 23:40 UTC (Sun) by coriordan (guest, #7544) [Link] Please bear in mind that this is a work in progress. When I was making this, I made mistakes, and the method I was using made it very slow to correct minor mistakes, so I didn't bother. I'll do the process a second time to catch as many as possible. With that note, here's a transcript of the opening session from the first international GPLv3 conference. I haven't transcribed the Q&A session. I might if I get time.
I've made a transcript Posted Feb 13, 2006 12:30 UTC (Mon) by coriordan (guest, #7544) [Link] The transcript is done now. I haven't done the Q&A, but it's not as interesting (lower sound to noise).
FSF: GPLv3 Update #2 Posted Feb 13, 2006 1:38 UTC (Mon) by sbergman27 (guest, #10767) [Link] This question is a bit tangential, I suppose, and for that I apologize in advance. But Eben's style of speaking is interesting. There is an exagerated pause between each word of every sentence. (It's almost like listening to Captain Kirk (BUT... WITHOUT ... THE ... FORCEFULNESS!).
I have read what Eben has said on many occassions. But this is the first time I have actually seen and heard him speak.
I'm going to guess that his style of speaking in the video reflects the fact that he realizes that he is speaking to an international audience, a large portion of whom speak English, but not as a first language.
Is that correct? Or is he just "being an attorney". ;-)
FSF: GPLv3 Update #2 Posted Feb 13, 2006 3:07 UTC (Mon) by beoba (guest, #16942) [Link] It's a good lecture hall voice.
FSF: GPLv3 Update #2 Posted Feb 13, 2006 12:32 UTC (Mon) by coriordan (guest, #7544) [Link] There are links to a number of links to audio and video recordings of other presentations he's given on the Wikipedia page about him.
FSF: GPLv3 Update #2 Posted Feb 14, 2006 2:35 UTC (Tue) by sbergman27 (guest, #10767) [Link] Thanks. I must say I am impressed with the guy. I dare say that he is more effective at getting the message across than Richard. Richard may be the vision, but Eben is the voice.
Unfortunately, most of these clips are not viewable or listenable with Free Software. :-(
The battle goes on, I guess.
FSF: GPLv3 Update #2 Posted Feb 14, 2006 21:02 UTC (Tue) by sepreece (subscriber, #19270) [Link] Looking back at the GPLv3 draft 1 text, I'm suddenly confused.
The clause that most of the discussion above is about says:
Complete Corresponding Source Code also includes any encryption or
I thought this meant that a recipient could modify and reinstall the work and expect it to work. However, rereading it I suddenly noticed the "you" and "your". In this license I believe "you" refers to the person licensed to redistribute the work (that is, the person to whom the license grants rights). So, the clause above would appear to grant the right of modification and reinstallation to the licensee - the person who distributed the version in question.
That is, if person A released work W under GPLv3 and person B included that work in a device D under the terms of the license that is subsequently sold to some end-user U, it seems like the clause above is a grant to person B, NOT to person U.
Is this a simple editorial mistake, but later text in the same paragraph refers specifically to "the user" as opposed to "you", so I'm not even sure what they meant. At the least, the use of "you" throughout the document should be reviewed and clarified so as to be unambiguous.
|
|||||||||||||