Peter Dickerson wrote:

I tried to make it as succinct as possible, but I needed to have the
major bases covered.

1. I can't allow anyone else to claim ownership of the code fork I
offer; otherwise, someone could change one comment, say "DOSFS is mine"
and try to suppress my original.

2. I explicitly disclaim liability for any damage caused by the code
and require that, as a condition of licensing, the user indemnifies me
and keeps me out of any lawsuit.

3. In some jurisdictions, it is not possible to limit liability in this
way, even for a giveaway product. Therefore I have to make it clear
that if you're covered by such laws, you can't legally use DOSFS.

4. I don't require you to release any sourcecode, or tell me that
you're using DOSFS, or do anything else whatsoever. However if you DO
tell me you're using it, and you tell me some feature you added or bug
you found, this isn't secret information and I may publish it as part
of the free DOSFS tree.

"larwe" <zwsdotcom@gmail.com> wrote in message
news:1158147241.041089.19510@i42g2000cwa.googlegro ups.com...
Yes. I wasn't trying to imply anything odd. I was just justifying not
quoting the license verbatim.

Yes. Its your code, it will stay your code. That you let others use it and
update it for their one ends is great.

Yes. FatFS has english and japanese docs, so I suspect the author does not
have english as their first language. Hence the terseness there. It always
pays to make it clear where the resposibility lies for use of the code.

This is the hardest one because now the user must make sure how the law
applies to them but noone can blame you for put that in.

Indeed I reported what I perceived to be a problem and you kindly offered to
look at it.

Peter

Chris Hills wrote:

Some edited quotes:

.... certainly it is becoming progressively harder to get into the
engineering field. This is true both from the perspective of an
entrepreneur wanting to make a new product, or a prospective
engineering student simply trying to decide what to learn in order to
be marketable, and cramming all this knowledge into his or her skull.

[...]

The single biggest barrier to entry in product development,
particularly for the US market, is intellectual property (IP) issues.
Due in part (it is said) to the privations suffered by tech firms after
the dot-com implosion, we live in a society of unparalleled IP-related
litigiousness. It should be no surprise to you that patents and other
IP disputes are a major business - for some technology companies, the
only profitmaking business. All over America, there are erstwhile
investors who presently hold the worthless remnants of failed
companies. Tucked away inside many of these paper corporations is a
dusty shoebox full of assorted patents. Armies of lawyers are poring
over these documents as you read this, trying to determine if any
extant product can be argued to infringe upon those patents.

[...]

This is partly the inherent nature of science and engineering; no sane
engineer builds everything from scratch. He or she will obviously use
time-proven techniques and add whatever new innovation the application
requires. In theoretical science, all that's necessary is to cite the
proper references when you publish your research, and there are no
problems. When you're developing a commercial product, however,
big-money patent issues pop up. No product you will ever make can
possibly evade this tar pit.

[...]

The reason I bring up these IP issues is that as a small
entrepreneurial engineering company, you might not be able to afford
detailed IP searches for every product you intend to develop.
Unfortunately, this means that when you release a product, you're
playing Russian roulette with the gun held to your head for a very long
time - as much as twenty years, or even longer. Large companies,
which can afford to pay for full searches, also have the option of
either buying the patent in question, or negotiating cross-licensing
agreements with their own patent portfolio; these luxuries are
inaccessible to the small firm.

[...]

One of the other reasons you're so likely to be bitten by a patent
problem when you build a product these days is that interoperability
with very recent commercial standards is much more important now than
it used to be.

[...]

Today, the software and protocol landscape is much more homogeneous
than it was twenty years ago. It might not always appear that way to a
developer, of course - there are seemingly millions of new extant
standards, simply because computers and networks now have many
capabilities that didn't exist back in the 1980s. However, in a given
field (say, operating systems) there are usually only two or three
usefully popular standards, at most. If you want to attach to a modern
LAN, you'd be crazy not to support TCP/IP over Ethernet, not to mention
a commonly-used higher-level protocol like SMB or HTTP. The fact that
so many players are implementing products on the same foundations
increases the chance that they are going to infringe on each others' IP
rights.

[...]

Closely related to the latter point, another big barrier to entry is
that these immensely complicated modern systems contain a huge amount
of functionality (executed either in software or by the hardware of the
system) compared to their more elderly counterparts. It is a stated
goal of several large corporations to raise the barriers to entry in
their industry by training consumers to require more and more
"free" functionality as a baseline.

[...]

By the way, some people will argue with this last point. They will
point out that a huge amount of infrastructure IP (often free) is now
available to get your project off the ground, so the overall effort of
developing a new application might even be less than it was in the
"good old days". While it is certainly true that there exists a
vast amount of software and reference hardware design material
available for free, or at least a reasonable cost, I'll point out that
this merely trades engineering hours spent writing from scratch for
engineering hours integrating and testing. The testing effort required
to certify correct operation of a modern product is quite unbelievable
(it increases exponentially with a linear increase in the size of the
system), and in many cases skipping tests on "proven" components,
particularly software components, is foolhardy.

[.............]

I liked this quote. It fits well the way I see the planet today:
overcrowded of useless people fiercely elbowing each other in the
necessity to grab some of the goods coming out of the automated
factories...
So antiutopic.

Dimiter (wishing he were Hari Seldon or at least had some plan...:-)

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


larwe wrote:

Didi wrote:
It's amusing that you say this, because the intro, which I didn't
quote, was this:


Our colleges will cease to offer engineering degrees (since there is no
demand), and the knowledge of how to design and build machinery will
pass forever into the hands of our outsourcing partners. To borrow a
peculiarly apposite image from H.G. Wells, we will become the consumer
Eloi, with the rest of the world predatory Morlocks who both feed us
and prey upon us.

I imagine our colleagues around European water-coolers hear the same
sort of talk. This sort of thing irritates me no end, because there are
much more important things than outsourcing to worry an engineer in the
twenty-first century.

In a recent book, I described this alarmist line of thinking as the
Malthusian school of thought, in a nod to Thomas Malthus (1766-1834).
Malthus famously predicted that human population would expand
exponentially, outstripping the food supply, with catastrophic results.
He was wrong; thus far, technological advances have kept the total
potential world food supply well in excess of the needs of our total
world population. In my opinion, the Malthusian-style outsourcing
doomsayers are wrong as well, but certainly it is becoming
progressively harder to get into the engineering field.

Well I only made an observation. I agree there are lots of more
important
things to do - but this does not change the reality.
To quote some more old philosophers, "let's not throw the baby out with
the water" regarding Malthus. His formula is naive, however his vision
is not - expecting the planet cannot be saturated as a system is simply
stupid. Where the point is I don't know - and frankly, like most
people,
I am busy surviving rather than thinking on things like that, except
when
triggered and in the suitable mood :-).
Overall I am not pessimistic, don't get me wrong. We have evolved
so far, with a little (or some more...) luck we can evolve where now we
just
cannot imagine we could ever be. But this does not change the painful
reality of today, which it is for most of the billions walking around.
I guess the pain is just part of the push designed into the
evolutionary
process - so its level is likely to stay with us well regulated
as long as there is life... Oh and don't be surprised if life opts to
migrate
onto silicon - there's so much more of it on Earth than carbon :-).
I would say we have made the first few steps that part of the evolution
will take - I am sure this will be well understood in this group :-).

Dimiter (wishing more he were Hari Seldon with a less painful plan :-)

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

larwe wrote:

Chris Hills wrote:
Just to balance the bias here, that kind of problem occurs with *all*
types of licences. The only difference is that with open source, it is
harder to hide - with closed source development, you can cheat more easily.

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:45085b7d$0$17142$8404b019@news.wineasy.se...
May, may not. One side does not fit all. The solution, if it does, is to not
modify the code, or not use it.


I agree that this has nothing to do with open source. In the embedded world
nobody outside the development group ever sees the software as software but
as a board or a component or a product. If you want to cheat, use open
source outside its license terms or reuse code written for a previous
employer, you can probably hide the fact easily. Both are bad. If you don't
like the terms, don't use it.

Peter

In article <1158157286.227643.92310@i42g2000cwa.googlegroups. com>, larwe
<zwsdotcom@gmail.com> writes
I a sure I can come up with a larger number of unattributed out of
context partial quotes to prove anything I wanted.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:

Those are all quotes /FROM THE ARTICLE/.