Licence text and fabs

Posted Oct 5, 2006 7:30 UTC (Thu) by mingo (subscriber, #31122) [Link]

Now you artificial unrepresentative example isn't, but IIRC in a similar case when Sega tried to lock its console by checking for the Sega word/logo at the beginning of ROMs, a judge ruled since the Sega word/logo use was 100% technical and the check could have been implemented by Sega the same way with a non trademarked/copyrighted/protected string/bitbucket, using Sega instead didn't win them any special additional protection.

well, what i wrote into the key wasnt a simple word/logo. And yes, it can be used as a totally valid cryptographic key - it has enough random content to be cryptographically strong, and it has enough expressive content to be copyrightable. And if it's kept secret by the hardware, it can very much be a trade secret as well. The Sega logo is hardly a trade secret. Do you have any case law that says that trade secret works that are /independent/ of the copyright holder's work are trumped by copyright law? In my reading it would be contrary to the letter and the spirit of both the law and the Constitution.

This was a relatively small key i constructed, but what if that key includes actual, functional code as well, which would have to be executed by the CPU for the hardware to work correctly. What if that key is your family inheritance that your ancestors signed their legal documents with for decades, and which includes expressive content that has sentimental value to me as well. Your assumption that just because it's used as a key it cannot have expressive properties was false when you first said it, and it is still false now.

And you are still missing the larger point as well. This portion of the GPLv3 is a seemingly small but dramatic departure from the spirit of the GPLv2, which explicitly said that it does not attempt to control other works (unless those works being based on GPL-ed code), be that source code, keys or anything else. GPLv2 Section 2 says:

 Thus, it is not the intent of this section to claim rights or contest
 your rights to work written entirely by you; rather, the intent is to
 exercise the right to control the distribution of derivative or
 collective works based on the Program.

this language is gone from the GPLv3, and the DRM language does a first step towards using distribution rights to control other works. Today it is only used to control certain keys. So far I have not seen anyone even try to limit the scope of this new step, it seems the party line of the FSF is that "everything that /we/ think or ever thought would be needed for the 4 freedoms is a fair game". Would you ever sign a contract with that kind of open-ended language in it?

And in what way will you change the bargain next time around? Until today it was in essence source code for source code, and it took 10 years to explain even this simple concept to developers. Tomorrow it's the hardware's keys too in some cases, the day after tomorrow it will be what? Will the GPLv4 say:

 You must ship 10 free samples of hardware and design specifications
 to the FSF headquarters and offer free on-site training and free
 tools for tweakers to be able to make use of their right to tweak.

Will the GPLv4 perhaps include:

 You may only distribute copies of works that are GPL-compatible in their 
 totality. Aggregation with any non-GPL work is prohibited.

is that the plan?

Future contributors will be asking me that, and I have no answer for them, do you have any?

We are going to lose alot more contributors this way than due to this uncertainty of the deal than whatever freeloading might become possible via DRM. Freeloading was always possible - heck, a simple end-user of GPL-ed code who never contributes back and never distributes GPL-ed works is a "freeloader" almost by definition.

I'm not worried about freeloaders as long as it's economically unfeasible for them, both the GPLv2 and the GPLv3 has loopholes that enable freeloading and leaching. I'm alot more worried about having a fair and clear deal towards developers, because they wrote this 1 billion lines of GPL-ed code, not the FSF.

Or was this section of the GPLv2 just a false promise to lure developers into writing 1 billion lines of code?

Posted Oct 5, 2006 7:31 UTC (Thu) by mingo (subscriber, #31122) [Link]

And no-one has explained it to me yet how it would reduce the amount of DRM in hardware if the GPL adopted anti-DRM language. All the indicators are that such a step /increases/ the amount of DRM done, because a fair portion of current embedded Linux would switch to other OSs. (partly because they are forced by other content makers to use DRM, partly because they'd sense a fundamental uncertainty in the licensing foundations of Linux.)

Also, the FSF should be well aware of the fact that it's always the first layer of software that matters for DRM, most of the time. So it's the kernel that has to deal with hardware and DRM issues. It's the kernel's contribution rules that you are playing with here. In fact without the kernel moving to GPLv3 the whole DRM section is almost totally pointless. (unless you count Hurd, which would have to remove tons of Linux code to begin with, if it wants to switch to the GPLv3) The remaining free software projects are mostly just curious bystanders. Yeah, i oppose DRM just as much as you do, but do /you/ have to deal with the fallout of this happy activism?

Posted Oct 5, 2006 7:36 UTC (Thu) by mingo (subscriber, #31122) [Link]

Which again is academic because actual DRM keys do not look like yours.

[sarcasm] Oh, thank goodness no-one else will think of this and they will not produce DRM keys that are copyrightable. Phew, that was close, i was almost getting worried! [/sarcasm]