Only one person can hold a domain. 10 people can have the same trademark--providing it's in 10 different industries.
Worse, there are lots of countries on the planet and they all have their own trademark laws. Nobody uses the.us domain, and the com/net/org domains are available to anyone worldwide.
So what's the point in using trademarks? Just about any word or phrase is probably a trademark somewhere in the world.
The FCC is just going to wait until it's technically feasible to do something interesting, and it's politically clearer what would be useful to do.
Most of the routers being installed into big ISPs now have the ability to selectively drop IPs (or at least class C's)--the whole bandwidth industry is rapidly consolodating into a few big companies.
In a few years there will only be a couple of big players, who will be happy to toe the line, and they will have installed equipment that allows them to implement whatever restrictions are wanted.
By then the politicians will know what it is they want to restrict, and the FCC will suddenly be a lot less hands off.
Corporations are amassing more and more of the worlds resources, governments are becoming less and less important. Small countries are much smaller than big companies; and big companies and midsize countries negotiate pretty much as equals. (Consider that GEC represents 1% of the US GNP).
Microsoft just happens to be a little bit clumsier in their manipulation than everyone else. When they get caught with their hand in the cookie jar they look guilty--other companies make it look like they're performing a valuable service.
Hey, remember the Gulf War? Remember how GEC build launch pads to launch the rockets they build to fly with the guidance systems they designed using the engines they constructed to hit targets tracked by satellites they launched in order to make the 6pm news on NBC (the TV network they own), all funded by the money they lent to the government (GE Capital Corp.). And they made you like it--now that's a class act.
Microsoft has a long way to go before they'll be able match that.
There can be no doubt that Sun understands how free software works. The company was founded by Bill Joy, the architect of the original BSD unix, which was released free under the original BSD license.
In its early days Sun kept the tradition alive. They developed a proprietary OS, based on BSD, and included in it a "contrib" collection of free software programs. The combination of a quality OS with commercial support, and a good collection of tools (many free) generated an impressive, healthy culture of SunOS devotees.
Sun also made their original money by undercutting other vendors on price: they were the first Unix vendor to sell "out of the box" systems, everyone else wanted to build you a custom system for every occasion.
The company changed radically in the late 80's, when it fell under the control of a very powerful and very ill informed middle management. They adopted AT&T's SysV OS and dumped BSD, in the belief that this would help get them onto the "business desktop". In order to seem more professional they dumped all the free tools, and buried all evidence of their free software BSD origins.
They never made it onto the business desktop, but they did manage to adopt AT&T's proprietary, paranoid attitude.
Today you have to view Sun as a company with a split culture. There are those who believe in the proprietary AT&T SysV "business desktop", and then there are those who fall into the BSD camp, and have hung on for various reasons.
Or to put it another way: Sun, when Bill Joy is in control, is probably an OSS/free software friend; but Sun when Scott McNealy is in control is a calculating, proprietary, business environment.
1-- This has absolutely nothing to do with whether he traded at an allowed time, or filed proper advance notice. He probably did both those things, he is in trouble for something different.
2-- There definately was a victim. Every trade on the market has a buyer and a seller. Despite how it might seem when you call your broker up, you cannot buy shares out of thin air, you always buy them from someone. Whoever bough Cowpland's shares (probably a lot of people) were not engaged in a fair transaction: the person they were buying from secretly knew that they were being set up to take a fall. He had information that they could not possibly have had.
3-- Insider trading is not helpful. Someone suggested it "helps" by causing information about a company to be reflected in the price. We don't need insider trading to have this--audited financial statements that come out four times a year are pretty good at giving things away. You can shuffle the books around only so long before the GAAP rules force you to report the truth.
If Cowpland really did know that Corel was about to take a loss, and he traded at a time when he had that information and few others did, then he should fry.
That's about as greedy, inconsiderate, and illegal as it gets. OK, not as bad as if he'd made a derivatives bet--I guess even Cowpland felt that would be too obviously criminal. He was trying to be unobviously criminal--which is what criminals generally do.
Requiring people to submit changes goes against their right to privacy
What right to privacy? Without a grant of copyright from the author (ie: a license) they have no right to modify the software in the first place. You can't have a right to privacy with respect to something you have no right to do.
My main motive, though, for including this requirement is that in the future I believe application servers will be very important. A lot of software will never be "distributed" then, it will only be "displayed" and "performed" on an application server--which winds up being a loophole through the GPL/LGPL.
distribute binaries without source code
The SPL allows you to distribute your derived binaries without source, but not the licensed software itself. I guess I could loosen it up so that you are only required to make the source available.. have to think about that one. It could be a critical issue in an "applet" where the compiled original gets "distributed" as a binary to the users web browser--good point.
Simplicity unimportant for GPL
Simplicity is definately important. There are a huge number of people out there who have never used or seen the GPL before, I know because I receive questions from them all the time, since they can't understand the license my software is under (namely the GPL). Maybe this is because I write Java software, and many users of it aren't using Unix. At any rate, the effort required to create a new license is less than the effort required to explain the GPL.
GPL compatible
Yes, it has a specific clause allowing use under the GPL. Like the LGPL, it wouldn't be GPL compatible without that clause.
I have been working out an alternative to the LGPL with the primary goal of being shorter and easier to read; and secondary goals of cleaning up some housekeeping issues that always bugged me with the LGPL and GPL.
Follow the link above, and mail me any comments you have.
The housekeeping issues dealt with: ensure that the original author receives changes (LGPL does not); prevent creating a non-free library or application builder to wrap the functionality of the code in a proprietary shell; move jurisdiction to the author's state or province, in case of a legal battle; and ensure that copyright credits actually appear in the primary documentation, rather than buried in the code somewhere.
Again, the primary goal is simplicity, the rest of it is just nice to have. The SPL is two pages as opposed to the LGPL's eleven.
The SPL has been reworked several times in response to comments, and the current version is about to be reviewed by a lawyer--though there is still lots of time to change.
The one thing I'd like to do is extend it so it works just as well for scripts as for compiled code.
Procedures like this are important for proprietary software development, but not for open-source projects. Bear that in mind when you read peoples responses here, because/. is obviously going to be biased toward open-source style advice.
With free software and open-source projects, people coming on board the project have probably already reviewed the source code in detail. They've had it for awhile, and probably are joining your team because they've begun tinkering with it on their own.
With a proprietary project, new developers have never seen the code before and have no idea how it might work, because it's proprietary. Therefore you need to spend resources helping them learn about it, and documents are one way.
With an open-source project, all of the users can peer through the code and search out the bugs when something doesn't work. This in my opinion is the biggest "10x" advantage that open-source projects have. Also, a saying I like is that "every problem has an obvious solution, if enough eyes see it". A bug that just mystifies you will be totally obvious to one of your users.
With a proprietary project, your users cannot read the code, and only you and the people on your team can debug it. Therefore you must devote time and energy toward tracking down bugs--to make up for not having hundreds or thousands of eager users doing that for you. And the bugs may not be obvious to you at first (not enough eyes) so you have to have additional procedures to methodically track them down.
Thus a properietary project needs peer-reviews, code-walkthroughs, and so forth.
In a nutshell, all that "software engineering institute" advice really is valuable, and you really should do it. Though people here will tell you that they have almost no procedure and things seem to work--it's likely they're talking about either one or two person projects, or else about open-source projects.
In a proprietary software environment, you really do need to do a few things by the book.
Of course if those documents aren't reliably maintained, or there isn't a way to mark them as "out of date", or whatever, then they may not be very much good for knowledge transfer; they should still be of some "design review" benefit though.
My biggest problem with this is...
WHY ON EARTH ARE THEY MSWORD FILES?! For gods sake, put those things in HTML and post them on your internal web. They're much more accessible that way.
Slashdot Mirror
Only one person can hold a domain. 10 people can have the same trademark--providing it's in 10 different industries.
.us domain, and the com/net/org domains are available to anyone worldwide.
Worse, there are lots of countries on the planet and they all have their own trademark laws. Nobody uses the
So what's the point in using trademarks? Just about any word or phrase is probably a trademark somewhere in the world.
This is just stupid.
The FCC is just going to wait until it's technically feasible to do something interesting, and it's politically clearer what would be useful to do.
Most of the routers being installed into big ISPs now have the ability to selectively drop IPs (or at least class C's)--the whole bandwidth industry is rapidly consolodating into a few big companies.
In a few years there will only be a couple of big players, who will be happy to toe the line, and they will have installed equipment that allows them to implement whatever restrictions are wanted.
By then the politicians will know what it is they want to restrict, and the FCC will suddenly be a lot less hands off.
Corporations are amassing more and more of the worlds resources, governments are becoming less and less important. Small countries are much smaller than big companies; and big companies and midsize countries negotiate pretty much as equals. (Consider that GEC represents 1% of the US GNP).
Microsoft just happens to be a little bit clumsier in their manipulation than everyone else. When they get caught with their hand in the cookie jar they look guilty--other companies make it look like they're performing a valuable service.
Hey, remember the Gulf War? Remember how GEC build launch pads to launch the rockets they build to fly with the guidance systems they designed using the engines they constructed to hit targets tracked by satellites they launched in order to make the 6pm news on NBC (the TV network they own), all funded by the money they lent to the government (GE Capital Corp.). And they made you like it--now that's a class act.
Microsoft has a long way to go before they'll be able match that.
There can be no doubt that Sun understands how free software works. The company was founded by Bill Joy, the architect of the original BSD unix, which was released free under the original BSD license.
In its early days Sun kept the tradition alive. They developed a proprietary OS, based on BSD, and included in it a "contrib" collection of free software programs. The combination of a quality OS with commercial support, and a good collection of tools (many free) generated an impressive, healthy culture of SunOS devotees.
Sun also made their original money by undercutting other vendors on price: they were the first Unix vendor to sell "out of the box" systems, everyone else wanted to build you a custom system for every occasion.
The company changed radically in the late 80's, when it fell under the control of a very powerful and very ill informed middle management. They adopted AT&T's SysV OS and dumped BSD, in the belief that this would help get them onto the "business desktop". In order to seem more professional they dumped all the free tools, and buried all evidence of their free software BSD origins.
They never made it onto the business desktop, but they did manage to adopt AT&T's proprietary, paranoid attitude.
Today you have to view Sun as a company with a split culture. There are those who believe in the proprietary AT&T SysV "business desktop", and then there are those who fall into the BSD camp, and have hung on for various reasons.
Or to put it another way: Sun, when Bill Joy is in control, is probably an OSS/free software friend; but Sun when Scott McNealy is in control is a calculating, proprietary, business environment.
Contrary to what many people are suggesting here:
1-- This has absolutely nothing to do with whether he traded at an allowed time, or filed proper advance notice. He probably did both those things, he is in trouble for something different.
2-- There definately was a victim. Every trade on the market has a buyer and a seller. Despite how it might seem when you call your broker up, you cannot buy shares out of thin air, you always buy them from someone. Whoever bough Cowpland's shares (probably a lot of people) were not engaged in a fair transaction: the person they were buying from secretly knew that they were being set up to take a fall. He had information that they could not possibly have had.
3-- Insider trading is not helpful. Someone suggested it "helps" by causing information about a company to be reflected in the price. We don't need insider trading to have this--audited financial statements that come out four times a year are pretty good at giving things away. You can shuffle the books around only so long before the GAAP rules force you to report the truth.
If Cowpland really did know that Corel was about to take a loss, and he traded at a time when he had that information and few others did, then he should fry.
That's about as greedy, inconsiderate, and illegal as it gets. OK, not as bad as if he'd made a derivatives bet--I guess even Cowpland felt that would be too obviously criminal. He was trying to be unobviously criminal--which is what criminals generally do.
What right to privacy? Without a grant of copyright from the author (ie: a license) they have no right to modify the software in the first place. You can't have a right to privacy with respect to something you have no right to do.
My main motive, though, for including this requirement is that in the future I believe application servers will be very important. A lot of software will never be "distributed" then, it will only be "displayed" and "performed" on an application server--which winds up being a loophole through the GPL/LGPL.
distribute binaries without source code
The SPL allows you to distribute your derived binaries without source, but not the licensed software itself. I guess I could loosen it up so that you are only required to make the source available.. have to think about that one. It could be a critical issue in an "applet" where the compiled original gets "distributed" as a binary to the users web browser--good point.
Simplicity unimportant for GPL
Simplicity is definately important. There are a huge number of people out there who have never used or seen the GPL before, I know because I receive questions from them all the time, since they can't understand the license my software is under (namely the GPL). Maybe this is because I write Java software, and many users of it aren't using Unix. At any rate, the effort required to create a new license is less than the effort required to explain the GPL.
GPL compatible
Yes, it has a specific clause allowing use under the GPL. Like the LGPL, it wouldn't be GPL compatible without that clause.
Try this:
http://vsdl.org/SPL.html
Simple Public License:
I have been working out an alternative to the LGPL with the primary goal of being shorter and easier to read; and secondary goals of cleaning up some housekeeping issues that always bugged me with the LGPL and GPL.
Follow the link above, and mail me any comments you have.
The housekeeping issues dealt with: ensure that the original author receives changes (LGPL does not); prevent creating a non-free library or application builder to wrap the functionality of the code in a proprietary shell; move jurisdiction to the author's state or province, in case of a legal battle; and ensure that copyright credits actually appear in the primary documentation, rather than buried in the code somewhere.
Again, the primary goal is simplicity, the rest of it is just nice to have. The SPL is two pages as opposed to the LGPL's eleven.
The SPL has been reworked several times in response to comments, and the current version is about to be reviewed by a lawyer--though there is still lots of time to change.
The one thing I'd like to do is extend it so it works just as well for scripts as for compiled code.
http://vsdl.com/SPL.html
Procedures like this are important for proprietary software development, but not for open-source projects. Bear that in mind when you read peoples responses here, because /. is obviously going to be biased toward open-source style advice.
With free software and open-source projects, people coming on board the project have probably already reviewed the source code in detail. They've had it for awhile, and probably are joining your team because they've begun tinkering with it on their own.
With a proprietary project, new developers have never seen the code before and have no idea how it might work, because it's proprietary. Therefore you need to spend resources helping them learn about it, and documents are one way.
With an open-source project, all of the users can peer through the code and search out the bugs when something doesn't work. This in my opinion is the biggest "10x" advantage that open-source projects have. Also, a saying I like is that "every problem has an obvious solution, if enough eyes see it". A bug that just mystifies you will be totally obvious to one of your users.
With a proprietary project, your users cannot read the code, and only you and the people on your team can debug it. Therefore you must devote time and energy toward tracking down bugs--to make up for not having hundreds or thousands of eager users doing that for you. And the bugs may not be obvious to you at first (not enough eyes) so you have to have additional procedures to methodically track them down.
Thus a properietary project needs peer-reviews, code-walkthroughs, and so forth.
In a nutshell, all that "software engineering institute" advice really is valuable, and you really should do it. Though people here will tell you that they have almost no procedure and things seem to work--it's likely they're talking about either one or two person projects, or else about open-source projects.
In a proprietary software environment, you really do need to do a few things by the book.
Of course if those documents aren't reliably maintained, or there isn't a way to mark them as "out of date", or whatever, then they may not be very much good for knowledge transfer; they should still be of some "design review" benefit though.
My biggest problem with this is...
WHY ON EARTH ARE THEY MSWORD FILES?! For gods sake, put those things in HTML and post them on your internal web. They're much more accessible that way.