[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Boilerplate License Revision Proposal



>> We are not talking about somebody who is working for RedHat working on the
>> Gnome project. It is easy to get paid to write software. It is not so easy
>> to get paid to write documentation.
>
>that's damn right. who would/could fund our authors?
>Redhat? Oreilly? Ney, already asked.

No, they won't because it won't do them any good. RedHat? Has o.k. manuals
and most Linux Books are already written for them.

O'Reilly? Nope, they will publish some books and work with us to some
degree but they are a "For-Profit" company. That means they gotta make
money.

>
>> On the other hand, <joe> really enjoys O'Reilly and the things they have
>> done for the community.<joe> decides to give O'Reilly printing rights. 
>
>It is breaking the competition and establishing a monopoly.

Monopoly:

Exclusive control by one group of the means of producing or selling a
commodity or service. 

If <joe> offers this document to O'Reilly does it stop SAMS from creating
a document on the same subject by a different author?

No it does not. 

The monopoly argument is completly bogus. In order for their to be a
monopoly O'Reilly would have to have a minimum of 51% of the Technical
Publishing market.

That means they would have to be bigger than PTR and they are not even
close. Go to a book store, look on the shelf. How many Linux books do you
see covering the same topics?

How many have FSF qualified "Free" Licenses. Out of about 200
titles? Maybe 6.

Is this bad? No, because <joe> just cleared 40k plus percentage on writing
his Linux Book and he can happily live another year while creating another
book. We also got (potentially) a great book out of the deal.




>
>

-- 
--
<COMPANY>CommandPrompt	- http://www.commandprompt.com	</COMPANY>
<PROJECT>OpenDocs, LLC.	- http://www.opendocs.org	</PROJECT>
<PROJECT>LinuxPorts 	- http://www.linuxports.com     </PROJECT>
<WEBMASTER>LDP		- http://www.linuxdoc.org	</WEBMASTER>
--
Instead of asking why a piece of software is using "1970s technology," 
start asking why software is ignoring 30 years of accumulated wisdom. 
--


--  
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]