Hard links are probably a mistake. They do what you want but they are even more user-unfriendly. Unix origianlly had hard links (it's what ln does if you don't give the -s switch). Soft links were added because hard links were usable.
A good idea may be OS-9 style semi-soft links. They act like soft links, but if you delete the actual file it picks one of the soft links and changes it into the actual file. Requires extensive changes to the file system and cannot go between file systems or point at read-protected files. Still maybe a good idea.
Some shells do cd the way you suggest. Probably a good idea, I certainly have been hit by this.
ls -F will show symbolic links by putting an '@' on the end. tcsh (and probably others) have a built in command called ls-F, doing "alias ls ls-F" produces a very fast listing with symlinks marked. It does not appear to break scripts to do this.
I think we need to modify Linux itself (perhaps only libc and not the kernel) so the following is true:
0. Everybody should know that you can find where the executable is in/proc/self/exe. Run readlink() on that until you find the actual directory. Let's call that the "application directory". Any bugs where this does not result in an actual name of the directory the executable resides in must be fixed.
1. Linux (or ld) should act as though LD_LIBRARY_PATH is prefixed with the application directory. Anybody who knows of a way to do this without having two executables, please tell me! I am trying to write commercial software, and this is one point where Windows is vastly superior. Windows does fall down then by not having symbolic links, so in the end both systems are a pain.
2. Programs should use the application directory to look for their configuration files. (They should also look in ~/.appname and maybe/etc, but no files are required there).
3. The shells or exec() or something should be fixed so if you have a directory called appname with an executable file in it called appname/main, then typing the name of the directory, or finding it on the PATH, will in fact execute appname/main. Note: no stupid ".app" extension that OS/X uses.
4. Most serious change is to read/write. A program is allowed to read a directory and to write an empty directory. The resulting data is exaclty as though tar was run on that directory. This will allow utilities that don't know about directories to copy these applications and also to email them and so on.
Except for the ISO-8859-1 characters, all systems have been forced to give up on "case insensitivity". I recommend Unix retain it's original simple roots. Internationalization is the way to go and you cannot have "case insensitive" and true internationalized text at the same time. The rules for "case insensitive" are much too complex.
A "filename" is a stream of bytes. For obscure reasons the byte with the value 0 and the byte with the same value as the ASCII character '/' are not allowed, but there are no other rules. (the slash rule could probably be eliminated but it would require changing the system call for naming a file).
This will remove a good deal of "GUI" from the implementation of file systems.
It is recommended that programs presenting file names show the bytes as UTF-8 encodied Unicode, and display illegal UTF-8 sequences (including any code encoded with more bytes than needed) as the individual bytes turned into ISO-8859-1. Programs must never assigne any meaning other than "character" to any byte with the high bit set, to avoid security problems when characters are spoofed with mangled UTF-8.
The few programs that accept filenames typed in by the user should try to be user-friendly. One minor way is to do case-insensitive matching to the existing files. Far more imporatant is to do filename completion and spelling correction, which for some reason nobody ever suggests that these should be part of the file system.
I would keep the upper-case names like "System" just like you described them. However anybody who thinks "case insensitive file systems" are a good idea needs to do a lot more analysis of the problem.
Good point. At work they have aliased rm to rm -i so it always asks a question. Everybody I know has turned this off. It is worse than useless, as I think 95% of the time the reason a file is being removed is to free disk space.
Have rm ask if any file is named more than once on it's command line, or if any file does not exist. Do this before deleting any files.
Re:What this is about
on
Linus on DRM
·
· Score: 1
They can if the emulator is able to run the same decoding step the hardware can. Supposedly this is secret and thus such an emulator is impossible. But the secret is in the hardware, and lots of people will probably know it anyway...
Re:What about compiling from source?
on
Linus on DRM
·
· Score: 1
You seem to be confusing DRM with signatures. Obviously anything can be cryptographically signed and this can be used to prove that either person A signed it or somebody stole person A's key. Thats signatures.
You can also today make a system where person B can decide that only things signed by C can be run on person B's machine. However they cannot say what C can run on C's machine, C can decide to run only C's stuff, or A's stuff, or anybody's stuff.
DRM means that person M can decide that persons A and B can only run things signed by C. The difference is that A and B's machines do not belong to M.
Re:What this is about
on
Linus on DRM
·
· Score: 2, Interesting
I'm pretty certain Palladium adds machine instructions that a program can use to check if Palladium is still on and that the OS is trusted. It can refuse to run if Palladium is turned off and there is nothing any patched kernel or debugger can do about it. They can't patch around it because the test involves decrypting code with the private key buried in the palladium hardware.
The OS is responsible for making sure that everything loaded is "trusted" and turning off Palladium for the untrusted ones. If it didn't do this (or if there is a mistake, which is why "security" of Palladium will be absolutely zero) then the user can load some program that can examine the trusted program after it has been decrypted by Palladium and thus break the DRM.
Re:What this is about
on
Linus on DRM
·
· Score: 1
It could be argued that the source of a signed binary, which in the language of the GPL is "the preferred form for modification", must include the private key used to create the signature. However, as Linus points out, he and others have been signing GPL'd releases for years without anyone demanding copies of their private signing keys, so I don't really think that argument is valid.
Though I agree with you, there is a difference. Linus's key is not necessary if you want to modify the source code and produce and run your own binary. However a Palladium type key is required to produce a usable binary, so it could be considered a necessary part of the source.
Re:DRM will be *needed* by linux
on
Linus on DRM
·
· Score: 1
You apprantly have not been reading the same Tivo comments I have. The automatic downloaded is *hated* here, and many other aspects. Check your glasses perscription, something is really wrong.
Re:source to the key in the kernel?
on
Linus on DRM
·
· Score: 1
Not quite. What you are describing is signed executables, which Windows has right now and Linux has the eqivalent in signatures and sums attached to downloaded files.
The difference with proposed DRM hardware is that you cannot run a random piece of software even if you want to. Any plausable security system would tell you if a piece of software is "trusted" but not prevent you from running it. This is a huge difference, and anybody trying to pass off DRM as a "security" measure is lying.
In fact DRM will do nothing to enhance security. Outlook and Sendmail and that 007 game for the XBox were all "trusted" and have been "signed" and allowed to run. On Linux you absolutely cannot run any program that is not setuid, but for some reason that didn't stop the bugs, because contrary to what Microsoft's advertising will claim, turning on setuid (or "signing") does not magically make the bugs go away.
Actually the "end users" of GPL are free to do whatever they want as long as they don't violate copyright law. So more accurately the GPL is 0% "end user" stuff and 100% "developer" stuff.
A more accurate comparison would be to a Microsoft NDA for access to their source code.
PF = Packet Filter. It is used for networking and firewalls. Apparently there are several alternatives for FreeBSD and this is one of them.
It might be helpful to provide rudimentary information like this in the slashdot articles.
Re:The GPL is a GOOD idea for commercial software
on
Free as in Marketable?
·
· Score: 1
If you have a really clever "core algorithim" that is itself valuable you may want to keep that code secret. This could be done while GPL'ing the rest (you add an exception to the GPL for the additional code that is in a.o file, this is totally legal under GPL rules because all the code is yours). I agree with you that bugs and things people want to change are usually not in the "clever" part but in the boring parts that there is no reason to hide, and thus such a secret part lowers the value of the released code very little.
I'm not sure if such stealing is a problem, though. Lots of compainies send out full source with NDA agreements, and hire and fire employees that have full access to the source code, and invite visitors into the company. Instead the threat of lawsuits, or otherwise being caught, is what keeps people from using the code.
Copying can usually be proven by showing unneccessary matches in the functionality of two products. Large tables of data can be contaminated with bogus but harmless data to detect copying, just like the fake streets in road maps.
It's also possible that widely available GPL code, where only you can make a closed-source derivative, would scare away competitors from making a product, on the assumption that they would be acuesed of stealing the GPL version. Microsoft is sort of doing this with "shared source", it actually is designed to prevent people from writing interoperable programs.
Sorry. I just meant to counteract the common fud that adding GPL code is going to destroy any commercial value for the code. If in fact it has commercial value as closed-source to the evil university they will have little to no difficulty removing the GPL library. They will also likely blame the writer for putting it in there, rather than admit that the use of the GPL library probably got the thing tested and implemented sooner.
Using the GPL library to make your job easier is perfectly fine. But trying to say this will stop commercial exploitation overstates the power of the GPL.
The GPL is a GOOD idea for commercial software
on
Free as in Marketable?
·
· Score: 3, Insightful
It guarantees nobody else can "extend" it and sell it as their own product.
Nothing prevents you from selling closed-source versions of the same code you release GPL. You can provide official support or installation or manuals (no reason to release the good manuals with the GPL code). Or you can also add a few extensions of your own to the closed-source version so it has more value other than just official support.
The GPL version may be extremely useful for advertising your program. If it does anything useful you will find awareness of your program very high.
You can also copyright the name of the program in such a way that anybody forking a version is forced to change the name significantly so there is no way to confuse the two. If your name is considered "official" then that other version will have a hard time competing.
The problem is your IP department has been brainwashed into believing the GPL is bad for them. In some cases they are so stupid that they think it is worse than releasing the code public-domain. In fact unless you have millions of dollars in marketing budget, the GPL is the only method you have to make your product commercially viable. Microsoft is scared to death of this competition appearing which is why they are fighting it in every way they can, including posting some misleading letters here.
You seem to misunderstand the GPL. The likely result if they manage to make it releasable GPL-only is that the IP department will say they can't release it at all, meaning your source code will NEVER be used.
The GPL DOES NOT FORCE YOU TO RELEASE ANYTHING!!!! It forces you to release the source code if you distribute the program. Get that in your head.
Trying to force the code to be GPL is probably worse than anything. It took a long time to locate what libBFD is. It is used to read/write elf and coff formats interchangably. I guess it could be used instead of dlload or if you are writing a compiler or linker. Still there are plenty of LGPL or public domain tools to read/write these formats so if there really is commercial value to the program you will find your clever GPL-force removed rather quickly and may find yourself demoted for trying such obvious sabotage.
Without your explicit restriction, I can include your code in my GPL program. The public domain and your license allows the user to do *more* with the code than the GPL does, it necessarily fullfills all requirements of the GPL. All the GPL freedoms are available, plus more freedoms for your sections of the code. Thus the GPL is not violated. If you think the GPL is violated then you admit that your license has restrictions that are not in the GPL.
GPL code is FULL of public-domain code.
Now I cannot say "this code is under the GPL" for *your* code or any derivation of it. That would certainly violate the rules you intended for your license. It is also possible that you intend to disallow GPL programs from using your code, but that must be a restriction in *your* license. Since you do not name the GPL specifically then your license also prevents linking with NDA code or anything that is not under your license.
Anyway I am quite tired of this. You obviously have a stick up your butt about the GPL and want to try to destroy it. A license that requires algorithims to be in the public domain and not GPL'd would be quite useful, but you are not providing it, because your license makes use of the algorithms impossible.
You're right. Of course, the same applies to the GPL.
Exactly. Neither the GPL or your license are acceptable for an implementation of a standard. Since you have made your license as useless as the GPL I don't see what purpose it can serve other than to be a political statement.
I don't disallow GPL applications from using my code. The GPL disallows the distribution of code which links GPL-licensed code to my code.
No it doesn't. I can call public-domain and BSD code from GPL with no problem. If I couldn't then GPL programs could not run on BSD, and probably not on Linux where lots of libraries and code is BSD licensed. Your code is subject to your rules and the GPL may not be applied to *it*, and I think you can enforce the license on modifications to it, but use of your code does not violate the GPL because it does not prevent anybody from recompiling or modifying the GPL program, or examining how it works.
If you don't want people writing GPL programs using your code, you must explicitly state that in the license. See Microsofts anti-GPL license for examples, where they specifically list example licences that code calling the distributed code may not have. Since you also admit above that your license prevents NDA agreements, there must be something in your license that is preventing certain types of code.
Another problem I just thought of. I work for a company that sells software including source code under NDA to other companies. Inclusion of a single line of your code would make such an NDA impossible. This is not going to fly for MicroSoft or any other company doing serious software development.
Also most of this code is in demo "plugins" for a large closed-source application. We would prefer to place restricitons on the usage of this plugin code, as it provides much of the value of our software. But our software is probably worthless without demo code showing how to write the plugins. Without it somebody could reproduce the core and reuse all the plugins unchanged. We mostly copyright the plugin source, but some of it is GPL (mostly to try to encourage some standard file formats to be used, without freeing anything valuable). Again neither of these would be allowed by your license.
Well the wording is a bit confusing. I think that 3c is either meaningless or you don't want it. What you want is 4c and to clearly state that it applies to the source code. Ie the user has the option of including the source code, but the source code is copyrighted, and if included it is subject to the given terms.
I do find all your wording questionable. 4b is much more onerous than 3b and thus seems to actively discourage release of modified source code. Also disallowing GPL applications from *using* your code is a serious discrimination against a very large pool of software developers and would do more to prevent your "standard" from being accepted that a LGPL library would.
Also "GPL tainiting" is not going to be believable without an actual example of it happening. In reality nobody wanting to use a standard is going to accept a piece of GPL code and they will use the original version, it is virtually impossible for part of a standard required by commercial software to be GPL. An actual example of this happening must be provided if anybody is going to believe you. Notice that any such example must have started out non-GPL and now requires the use of GPL code to interoperate.
You should address this if you want anybody to think you are anything other than an industry shill.
Okay further reading of your license reveals that it is split into two sections for "closed" and "open" license. Since "open" is a subset of "closed" (an open distribution can be turned into a closed one by simply deleting the code), there cannot be any rules that apply only to the open version. Thus I figure everything in section 3 applied to all distributions.
I have to say though that I am totally baffled by what 3C is trying to prevent. Could you explain exactly what evil thing somebody could do if this clause was not there?
I don't think your license has any problems with the "open is a subset of closed" problem. All your rules have something to do with what can be done with the source code and thus can be claimed to apply to all redistribution, including ones missing the source code so that the rules are meaningless. However I would rewrite it to say something like "if source code is included with the distribution, the following rules apply to this source code" and put 4b and 4c in there.
Clause C seems to say that you are not allowed to give away even any version of the program (closed or open source) in any way where the receiver is allowed to do anything other than run the program. This completely disallows all similarities to the BSD or public domain license, and even means that reselling is not allowed.
Perhaps a better wording would be to say that the user can use your code to build a program and distribute it in any way they want (ie with any kind of EULA, for free or for cost, and with or without any portion of the source code). What you are really doing is expanding the definition of "use", you don't need to copy clauses from the GPL in your totally different license.
Seperately there is a copyright on the source code, and any redistribution of this copyrighted work requires your license. This would be very similar to your license.
You will probably need to do something so that nobody can claim that they "compiled" your code and that it is closed unless the end user agrees to the GPL. This is a huge loophole and I think you will have to put severe restrictions on what can be in the EULA, things that I don't think MicroSoft would be happy about. Reverse engineering would have to be allowed, for one. It would be much safer to require release of the modified source code under your license.
I also don't think this will prevent GPL "applications" that use your code. Since there is no restriction on the use of the product, somebody can claim that their GPL program "uses" the library and distribute two seperate pieces. However this is harmless as they are not allowed to modify the core of the library and add useful functions to it that are GPL'd, I think they are forced to use the library interface.
In any case I would *love* Big Evil Corporation to use my code. I don't see this happening unless they are forced to release changes, if they can make their own version then they are NOT using "my" code. I do agree that RMS is trying to make *all* code free and that a new license that explicitly is designed just to allow free standards is required and more useful. However your attempt seems somewhat reactionary, and an approach that does not say "the GPL is evil!" would have more success.
Clause C seems to mean that on one level of derivation can be done. The second derivate apparently is required to be under standard copyright. This clause seems to be in complete conflict with what you claim your goals are (and in conflict with what I suspect your real goals are, as well) so I am guessing that it was added due to legal analysis, since otherwise you state that somebody can "use the code for any purpose" and that adding GPL code to it falls into the "any purpose" catagory.
As stated your license is unacceptable to me, because it allows a company to steal my code, extending my work with small fixes, and take full advantage of it with no compensation to me. I believe your "goals" could be accomplished with something like the following rules:
1. The code must be designed like a library, with a usable interface so people can call it.
2. If the code is used in such a way that the user does not modify any source files or header files, then it can be treated entirely as though it was in the public domain. The code may be "linked" with a program in any way the user wants, including cutting and pasting blocks of code, deleting unused branches, and anything else that could be considered not changing it's behavior or algorithim.
3. If the code and header files are modified for a *distributed* product, the user MUST release the modified versions under this exact same license. None of this GPL nonsense about "offers", instead the code must be posted for free on the net and clearly announced with the first offer for sale or distribution of the product, and the posting location must also be printed in the back of any manual or any on-line help or about box. The posting location must be maintained as long as the product is sold or distributed.
If the modifications are released the modifier may then use the modified version of the library exactly like in version 2.
4. There will probably have to be clauses so the modification can't be to add "call_secret_code_here();". This could be the big problem with this license idea.
I think that is true but a lot of people seem to disagree. On fltk we put an explicit "exception" to the LGPL that we copied from a number of other libraries, that explicitly says that statically linking with a program is ok.
I do feel that the wording of the LGPL is rather convoluted here, and although I disagree with a lot of the anti-RMS stuff here it does seem worded in such a way as to discourage people from writing their *own* closed-source code.
It seems to me that wording that says you must distribute any changes to the source or header files of the library that you made, but that if you use them unchanged than the library is effectively public-domain would serve all the purposes of the LGPL. (There may have to be some more wording to avoid cheating, ie you must provide all code that is linked in by the modified headers and source, so somebody can't just add "call_secret_stuff()" to the file and say they complied.
Slashdot Mirror
A good idea may be OS-9 style semi-soft links. They act like soft links, but if you delete the actual file it picks one of the soft links and changes it into the actual file. Requires extensive changes to the file system and cannot go between file systems or point at read-protected files. Still maybe a good idea.
Some shells do cd the way you suggest. Probably a good idea, I certainly have been hit by this.
ls -F will show symbolic links by putting an '@' on the end. tcsh (and probably others) have a built in command called ls-F, doing "alias ls ls-F" produces a very fast listing with symlinks marked. It does not appear to break scripts to do this.
0. Everybody should know that you can find where the executable is in /proc/self/exe. Run readlink() on that until you find the actual directory. Let's call that the "application directory". Any bugs where this does not result in an actual name of the directory the executable resides in must be fixed.
1. Linux (or ld) should act as though LD_LIBRARY_PATH is prefixed with the application directory. Anybody who knows of a way to do this without having two executables, please tell me! I am trying to write commercial software, and this is one point where Windows is vastly superior. Windows does fall down then by not having symbolic links, so in the end both systems are a pain.
2. Programs should use the application directory to look for their configuration files. (They should also look in ~/.appname and maybe /etc, but no files are required there).
3. The shells or exec() or something should be fixed so if you have a directory called appname with an executable file in it called appname/main, then typing the name of the directory, or finding it on the PATH, will in fact execute appname/main. Note: no stupid ".app" extension that OS/X uses.
4. Most serious change is to read/write. A program is allowed to read a directory and to write an empty directory. The resulting data is exaclty as though tar was run on that directory. This will allow utilities that don't know about directories to copy these applications and also to email them and so on.
A "filename" is a stream of bytes. For obscure reasons the byte with the value 0 and the byte with the same value as the ASCII character '/' are not allowed, but there are no other rules. (the slash rule could probably be eliminated but it would require changing the system call for naming a file).
This will remove a good deal of "GUI" from the implementation of file systems.
It is recommended that programs presenting file names show the bytes as UTF-8 encodied Unicode, and display illegal UTF-8 sequences (including any code encoded with more bytes than needed) as the individual bytes turned into ISO-8859-1. Programs must never assigne any meaning other than "character" to any byte with the high bit set, to avoid security problems when characters are spoofed with mangled UTF-8.
The few programs that accept filenames typed in by the user should try to be user-friendly. One minor way is to do case-insensitive matching to the existing files. Far more imporatant is to do filename completion and spelling correction, which for some reason nobody ever suggests that these should be part of the file system.
I would keep the upper-case names like "System" just like you described them. However anybody who thinks "case insensitive file systems" are a good idea needs to do a lot more analysis of the problem.
Good point. At work they have aliased rm to rm -i so it always asks a question. Everybody I know has turned this off. It is worse than useless, as I think 95% of the time the reason a file is being removed is to free disk space.
Have rm ask if any file is named more than once on it's command line, or if any file does not exist. Do this before deleting any files.
They can if the emulator is able to run the same decoding step the hardware can. Supposedly this is secret and thus such an emulator is impossible. But the secret is in the hardware, and lots of people will probably know it anyway...
You can also today make a system where person B can decide that only things signed by C can be run on person B's machine. However they cannot say what C can run on C's machine, C can decide to run only C's stuff, or A's stuff, or anybody's stuff.
DRM means that person M can decide that persons A and B can only run things signed by C. The difference is that A and B's machines do not belong to M.
The OS is responsible for making sure that everything loaded is "trusted" and turning off Palladium for the untrusted ones. If it didn't do this (or if there is a mistake, which is why "security" of Palladium will be absolutely zero) then the user can load some program that can examine the trusted program after it has been decrypted by Palladium and thus break the DRM.
Though I agree with you, there is a difference. Linus's key is not necessary if you want to modify the source code and produce and run your own binary. However a Palladium type key is required to produce a usable binary, so it could be considered a necessary part of the source.
You apprantly have not been reading the same Tivo comments I have. The automatic downloaded is *hated* here, and many other aspects. Check your glasses perscription, something is really wrong.
The difference with proposed DRM hardware is that you cannot run a random piece of software even if you want to. Any plausable security system would tell you if a piece of software is "trusted" but not prevent you from running it. This is a huge difference, and anybody trying to pass off DRM as a "security" measure is lying.
In fact DRM will do nothing to enhance security. Outlook and Sendmail and that 007 game for the XBox were all "trusted" and have been "signed" and allowed to run. On Linux you absolutely cannot run any program that is not setuid, but for some reason that didn't stop the bugs, because contrary to what Microsoft's advertising will claim, turning on setuid (or "signing") does not magically make the bugs go away.
A more accurate comparison would be to a Microsoft NDA for access to their source code.
It might be helpful to provide rudimentary information like this in the slashdot articles.
I'm not sure if such stealing is a problem, though. Lots of compainies send out full source with NDA agreements, and hire and fire employees that have full access to the source code, and invite visitors into the company. Instead the threat of lawsuits, or otherwise being caught, is what keeps people from using the code.
Copying can usually be proven by showing unneccessary matches in the functionality of two products. Large tables of data can be contaminated with bogus but harmless data to detect copying, just like the fake streets in road maps.
It's also possible that widely available GPL code, where only you can make a closed-source derivative, would scare away competitors from making a product, on the assumption that they would be acuesed of stealing the GPL version. Microsoft is sort of doing this with "shared source", it actually is designed to prevent people from writing interoperable programs.
Using the GPL library to make your job easier is perfectly fine. But trying to say this will stop commercial exploitation overstates the power of the GPL.
Nothing prevents you from selling closed-source versions of the same code you release GPL. You can provide official support or installation or manuals (no reason to release the good manuals with the GPL code). Or you can also add a few extensions of your own to the closed-source version so it has more value other than just official support.
The GPL version may be extremely useful for advertising your program. If it does anything useful you will find awareness of your program very high.
You can also copyright the name of the program in such a way that anybody forking a version is forced to change the name significantly so there is no way to confuse the two. If your name is considered "official" then that other version will have a hard time competing.
The problem is your IP department has been brainwashed into believing the GPL is bad for them. In some cases they are so stupid that they think it is worse than releasing the code public-domain. In fact unless you have millions of dollars in marketing budget, the GPL is the only method you have to make your product commercially viable. Microsoft is scared to death of this competition appearing which is why they are fighting it in every way they can, including posting some misleading letters here.
The GPL DOES NOT FORCE YOU TO RELEASE ANYTHING!!!! It forces you to release the source code if you distribute the program. Get that in your head.
Trying to force the code to be GPL is probably worse than anything. It took a long time to locate what libBFD is. It is used to read/write elf and coff formats interchangably. I guess it could be used instead of dlload or if you are writing a compiler or linker. Still there are plenty of LGPL or public domain tools to read/write these formats so if there really is commercial value to the program you will find your clever GPL-force removed rather quickly and may find yourself demoted for trying such obvious sabotage.
GPL code is FULL of public-domain code.
Now I cannot say "this code is under the GPL" for *your* code or any derivation of it. That would certainly violate the rules you intended for your license. It is also possible that you intend to disallow GPL programs from using your code, but that must be a restriction in *your* license. Since you do not name the GPL specifically then your license also prevents linking with NDA code or anything that is not under your license.
Anyway I am quite tired of this. You obviously have a stick up your butt about the GPL and want to try to destroy it. A license that requires algorithims to be in the public domain and not GPL'd would be quite useful, but you are not providing it, because your license makes use of the algorithms impossible.
Exactly. Neither the GPL or your license are acceptable for an implementation of a standard. Since you have made your license as useless as the GPL I don't see what purpose it can serve other than to be a political statement.
I don't disallow GPL applications from using my code. The GPL disallows the distribution of code which links GPL-licensed code to my code.
No it doesn't. I can call public-domain and BSD code from GPL with no problem. If I couldn't then GPL programs could not run on BSD, and probably not on Linux where lots of libraries and code is BSD licensed. Your code is subject to your rules and the GPL may not be applied to *it*, and I think you can enforce the license on modifications to it, but use of your code does not violate the GPL because it does not prevent anybody from recompiling or modifying the GPL program, or examining how it works.
If you don't want people writing GPL programs using your code, you must explicitly state that in the license. See Microsofts anti-GPL license for examples, where they specifically list example licences that code calling the distributed code may not have. Since you also admit above that your license prevents NDA agreements, there must be something in your license that is preventing certain types of code.
Also most of this code is in demo "plugins" for a large closed-source application. We would prefer to place restricitons on the usage of this plugin code, as it provides much of the value of our software. But our software is probably worthless without demo code showing how to write the plugins. Without it somebody could reproduce the core and reuse all the plugins unchanged. We mostly copyright the plugin source, but some of it is GPL (mostly to try to encourage some standard file formats to be used, without freeing anything valuable). Again neither of these would be allowed by your license.
I do find all your wording questionable. 4b is much more onerous than 3b and thus seems to actively discourage release of modified source code. Also disallowing GPL applications from *using* your code is a serious discrimination against a very large pool of software developers and would do more to prevent your "standard" from being accepted that a LGPL library would.
Also "GPL tainiting" is not going to be believable without an actual example of it happening. In reality nobody wanting to use a standard is going to accept a piece of GPL code and they will use the original version, it is virtually impossible for part of a standard required by commercial software to be GPL. An actual example of this happening must be provided if anybody is going to believe you. Notice that any such example must have started out non-GPL and now requires the use of GPL code to interoperate.
You should address this if you want anybody to think you are anything other than an industry shill.
I have to say though that I am totally baffled by what 3C is trying to prevent. Could you explain exactly what evil thing somebody could do if this clause was not there?
I don't think your license has any problems with the "open is a subset of closed" problem. All your rules have something to do with what can be done with the source code and thus can be claimed to apply to all redistribution, including ones missing the source code so that the rules are meaningless. However I would rewrite it to say something like "if source code is included with the distribution, the following rules apply to this source code" and put 4b and 4c in there.
Perhaps a better wording would be to say that the user can use your code to build a program and distribute it in any way they want (ie with any kind of EULA, for free or for cost, and with or without any portion of the source code). What you are really doing is expanding the definition of "use", you don't need to copy clauses from the GPL in your totally different license.
Seperately there is a copyright on the source code, and any redistribution of this copyrighted work requires your license. This would be very similar to your license.
You will probably need to do something so that nobody can claim that they "compiled" your code and that it is closed unless the end user agrees to the GPL. This is a huge loophole and I think you will have to put severe restrictions on what can be in the EULA, things that I don't think MicroSoft would be happy about. Reverse engineering would have to be allowed, for one. It would be much safer to require release of the modified source code under your license.
I also don't think this will prevent GPL "applications" that use your code. Since there is no restriction on the use of the product, somebody can claim that their GPL program "uses" the library and distribute two seperate pieces. However this is harmless as they are not allowed to modify the core of the library and add useful functions to it that are GPL'd, I think they are forced to use the library interface.
In any case I would *love* Big Evil Corporation to use my code. I don't see this happening unless they are forced to release changes, if they can make their own version then they are NOT using "my" code. I do agree that RMS is trying to make *all* code free and that a new license that explicitly is designed just to allow free standards is required and more useful. However your attempt seems somewhat reactionary, and an approach that does not say "the GPL is evil!" would have more success.
As stated your license is unacceptable to me, because it allows a company to steal my code, extending my work with small fixes, and take full advantage of it with no compensation to me. I believe your "goals" could be accomplished with something like the following rules:
1. The code must be designed like a library, with a usable interface so people can call it.
2. If the code is used in such a way that the user does not modify any source files or header files, then it can be treated entirely as though it was in the public domain. The code may be "linked" with a program in any way the user wants, including cutting and pasting blocks of code, deleting unused branches, and anything else that could be considered not changing it's behavior or algorithim.
3. If the code and header files are modified for a *distributed* product, the user MUST release the modified versions under this exact same license. None of this GPL nonsense about "offers", instead the code must be posted for free on the net and clearly announced with the first offer for sale or distribution of the product, and the posting location must also be printed in the back of any manual or any on-line help or about box. The posting location must be maintained as long as the product is sold or distributed.
If the modifications are released the modifier may then use the modified version of the library exactly like in version 2.
4. There will probably have to be clauses so the modification can't be to add "call_secret_code_here();". This could be the big problem with this license idea.
I do feel that the wording of the LGPL is rather convoluted here, and although I disagree with a lot of the anti-RMS stuff here it does seem worded in such a way as to discourage people from writing their *own* closed-source code.
It seems to me that wording that says you must distribute any changes to the source or header files of the library that you made, but that if you use them unchanged than the library is effectively public-domain would serve all the purposes of the LGPL. (There may have to be some more wording to avoid cheating, ie you must provide all code that is linked in by the modified headers and source, so somebody can't just add "call_secret_stuff()" to the file and say they complied.