Ah, you're right. I missed the definition of a Secondary Section:
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
OK, I see where you're coming from now. Sorry for the flame.
The thing you missing is that for the Debian Project, this is an ideological issue - are they justified in calling it a free software distribution if the documentation is (by their standards) not as free as the code itself?
Really, it's up to the project to decide what to do, as the people involved are the only ones who can say whether or not their consciences allow them to continue distributing the docs under the current GFDL.
Well, if that was your point, you didn't actually say so. Sorry.
In any case, you can always go back to the original GPL release and base your closed app on that if you want to. You're not losing anything, because even if you did release your code into the public domain, that would give you no particular rights to use changes made to that code by other people.
In other words, you'd be in exactly the same position whether you released your app as GPL or public domain, except that people would be able to incorporate your code into their closed apps if you release it into the public domain.
The other thing most likely to be marked as invariant would probably be appendices containing raw data (such as performance testing, experimental results, etc.), since altering these would destroy their validity.
Sorry, you're wrong. The GPL's restriction on linking prevents this. If you want to do something like that, the application would have to be under the LGPL to allow linking with binary-only libraries.
Really, did you think every person/corporation wanting to exploit GPL'd software hadn't already thought of that and rejected it after actually reading the license?
What are you talking about? The GFDL is specifically for documentation, and Debian is complaining about how it affects documentation to which it is applied.
Nobody said anything about using it for software. RTFA already, OK?
I don't restrict this to GNU FDL-licensed documents that have Cover
Texts or Invariant Sections because previous discussions have indicated that there may be still other problems with the GNU FDL 1.2. I seem to recall someone raising a fairly persuasive critique of section 4K, for instance. Thus, if we're going to nail some theses to the church door, we might as well make sure that they're comprehensive.
So yes, he has considered your idea. Personally, I think the best way out of the whole mess is to get the FSF to release a new version of the GFDL removing the invariant section and cover text blocks and fixing up whatever other issues Debian has with it, since 99% of the time stuff released under it is going to allow licensing under later versions of the license as well.
In case you didn't realise, any works completely of your creation can be used in any way you like, as you're the sole copyright holder.
So the only case where you wouldn't be able to take a work you've released under GPL and include it in a closed source application is where you've either (a) originally taken source that was under GPL or similar and added to it or (b) applied patches from people where those patches were supplied in the understanding that the resulting app would be released under GPL or similar license.
In other words, your comment about releasing your own works into the public domain because it gives you more freedom are wrong.
That's great news, then. I'm planning on replacing my current board (dual Slot1 SuperMicro) when the Opteron comes out, so it looks like I'll be going with another SuperMicro.
Dunno about the Quake results - every motherboard I've heard of for the Opteron doesn't have an AGP slot, so unless they try it with a PCI Radeon 9000 or something like that, I don't think they'll be able to do any meaningful benchmarks for games.
"Gosh, Mr. Green, we were only doing what anyone would -- fighting terrorism -- the enemy of free people worldwide!"
Re:U2..? High speed...?
on
Secret Empire
·
· Score: 3, Interesting
Damn, you beat me to it;)
Yes, the U2 was designed to fly high enough that nobody could reach it to shoot it down, but a couple of generations of Soviet AA missiles later, that stopped being true.
The US continued using them, though, which is what lead to the Gary Powers incident.
The gcc/egcs split was more recent, and more acrimonious. Thankfully, that panned out in a way that benefited gcc, rather than hindering its development.
I just hope the same thing happens in this case. Keith Packard has been doing some very good work in XFree86 lately, but there have been accusations that he's too 'corporate-controlled' (I have no knowledge as to the truth of these accusations one way or the other).
Well, I dunno... IIRC Linus has mentioned that multiple times, but I've been symlinking my latest source directory to/usr/src/linux for several years now (from 2.0.32 or so), and I've never once struck a problem.
But, if you're paranoid, I suppose it's good advice.
Untar them and move them all into someplace like/usr/local/lib/mplayer/dlls.
5) Get the latest mplayer source (0.90) and run configure with something like this:./configure --enable-largefiles --with-extraincdir=/usr/local/include --with-extralibdir=/usr/local/lib --with-win32libdir=/usr/local/lib/mplayer/dlls --with-xanimlibdir=/usr/local/lib/mplayer/dlls --with-reallibdir=/usr/local/lib/mplayer/dlls
Now, there seems to be a problem with the 1000x540 version of the trailer (the video plays at half speed, the sound at full speed). To get around that, I suggest you reencode the trailer. Use something like this:
No offence, but in that case I don't get why you said But the problems I have seen with the 1M is that you have more bandwidth than most of the servers out there and the speed is never fully utilised - at the moment.
Slashdot Mirror
She's also a talentless hack.
OK, I see where you're coming from now. Sorry for the flame.
The thing you missing is that for the Debian Project, this is an ideological issue - are they justified in calling it a free software distribution if the documentation is (by their standards) not as free as the code itself?
Really, it's up to the project to decide what to do, as the people involved are the only ones who can say whether or not their consciences allow them to continue distributing the docs under the current GFDL.
Well, if that was your point, you didn't actually say so. Sorry.
In any case, you can always go back to the original GPL release and base your closed app on that if you want to. You're not losing anything, because even if you did release your code into the public domain, that would give you no particular rights to use changes made to that code by other people.
In other words, you'd be in exactly the same position whether you released your app as GPL or public domain, except that people would be able to incorporate your code into their closed apps if you release it into the public domain.
The other thing most likely to be marked as invariant would probably be appendices containing raw data (such as performance testing, experimental results, etc.), since altering these would destroy their validity.
Sorry, you're wrong. The GPL's restriction on linking prevents this. If you want to do something like that, the application would have to be under the LGPL to allow linking with binary-only libraries.
Really, did you think every person/corporation wanting to exploit GPL'd software hadn't already thought of that and rejected it after actually reading the license?
What are you talking about? The GFDL is specifically for documentation, and Debian is complaining about how it affects documentation to which it is applied.
Nobody said anything about using it for software. RTFA already, OK?
So yes, he has considered your idea.
Personally, I think the best way out of the whole mess is to get the FSF to release a new version of the GFDL removing the invariant section and cover text blocks and fixing up whatever other issues Debian has with it, since 99% of the time stuff released under it is going to allow licensing under later versions of the license as well.
Well, at least they got the headline right!
It looks like they dodged the issue when Debian-legal originally went over the GFDL.
In case you didn't realise, any works completely of your creation can be used in any way you like, as you're the sole copyright holder.
So the only case where you wouldn't be able to take a work you've released under GPL and include it in a closed source application is where you've either (a) originally taken source that was under GPL or similar and added to it or (b) applied patches from people where those patches were supplied in the understanding that the resulting app would be released under GPL or similar license.
In other words, your comment about releasing your own works into the public domain because it gives you more freedom are wrong.
That's great news, then. I'm planning on replacing my current board (dual Slot1 SuperMicro) when the Opteron comes out, so it looks like I'll be going with another SuperMicro.
Dunno about the Quake results - every motherboard I've heard of for the Opteron doesn't have an AGP slot, so unless they try it with a PCI Radeon 9000 or something like that, I don't think they'll be able to do any meaningful benchmarks for games.
The more things change, the more they stay the same.
"Gosh, Mr. Green, we were only doing what anyone would -- fighting terrorism -- the enemy of free people worldwide!"
Damn, you beat me to it ;)
Yes, the U2 was designed to fly high enough that nobody could reach it to shoot it down, but a couple of generations of Soviet AA missiles later, that stopped being true.
The US continued using them, though, which is what lead to the Gary Powers incident.
Funny thing is, I *have* actually upgraded my glibc while doing that, and not struck any problems (then again, I may just have been lucky).
The gcc/egcs split was more recent, and more acrimonious. Thankfully, that panned out in a way that benefited gcc, rather than hindering its development.
I just hope the same thing happens in this case. Keith Packard has been doing some very good work in XFree86 lately, but there have been accusations that he's too 'corporate-controlled' (I have no knowledge as to the truth of these accusations one way or the other).
Well, I dunno... IIRC Linus has mentioned that multiple times, but I've been symlinking my latest source directory to /usr/src/linux for several years now (from 2.0.32 or so), and I've never once struck a problem.
But, if you're paranoid, I suppose it's good advice.
'Cellys'? I presume you mean Celerons, but I've never seen a RAID card with a Celeron - all mine have i860s.
No. You can be a badly-abused servant of the gods if you like, though.
I was 24 when I got married, and I spent just under $US4000 on the engagement ring.
The latest release will work. I use 0.90rc5.
d )
/usr/local/lib/mplayer/dlls.
./configure --enable-largefiles --with-extraincdir=/usr/local/include --with-extralibdir=/usr/local/lib --with-win32libdir=/usr/local/lib/mplayer/dlls --with-xanimlibdir=/usr/local/lib/mplayer/dlls --with-reallibdir=/usr/local/lib/mplayer/dlls
In order to get QT files to work properly, you'll need a few other bits and pieces.
Here's some instructions I posted a while back:
1) Install libsndfile if you don't have it. (http://www.zip.com.au/~erikd/libsndfile/#Downloa
2) Install FAAD to get sound from QT files (http://faac.sourceforge.net/download.php)
3) You probably want to install xvid as well... nothing to do with QT, but the more codecs, the better, right? (http://www.xvid.org/downloads.html)
4) Go to http://www.mplayerhq.hu/MPlayer/releases/codecs/ and grab:
Latest Win32 codecpack
QuickTime6 DLLs
QuickTime extra DLLs
RealPlayer9 codecs
XAnim DLLs
MJPEG2000 DLLs
Win32/DMO codecs
Untar them and move them all into someplace like
5) Get the latest mplayer source (0.90) and run configure with something like this:
Now, there seems to be a problem with the 1000x540 version of the trailer (the video plays at half speed, the sound at full speed). To get around that, I suggest you reencode the trailer. Use something like this:
mencoder -ovc lavc -oac mp3lame -lavcopts vcodec=mpeg4:vhq:v4mv:vbitrate=2000 -noskip trailer_final_1000_dl.mov -o trailer-divx4.avi
It should play fine (Worked For Me).
I've done a run of 30,000 CDs for around 30 US cents per CD. With higher volumes, that would obviously be lower.
If you were doing a million, I dare say the cost would be under 10 cents each.
The fact that the page pointed to is inaccessible from anything other than IE doesn't make me confident that this technology will be an open standard.
Ah well, I suppose if people want to sell their freedom for a T2 DVD, there's nothing I can do to stop them...
No offence, but in that case I don't get why you said But the problems I have seen with the 1M is that you have more bandwidth than most of the servers out there and the speed is never fully utilised - at the moment.