"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:45085b7d$0$17142$8404b019@news.wineasy.se...
> Chris Hills wrote:
> > In article <TiCNg.12798$Mh2.9757@newsfe6-win.ntli.net>, Peter Dickerson
> > <first{dot}surname@tesco.net> writes
> >> I have also had my attention directed towards commercial FAT support
code
> >> that has support for LFN. I'm still investigating that. I'm fairly
> >> sure it
> >> can do what I want but I'm not clear whether there is more work
> >> integrating
> >> with my other requirements than adding LFN to open/free/public code.
> >
> > The problem is that you may have a conflict as you could not release the
> > source code with the commercial stuff in it. The Open source may require
> > you to release the modified code...

May, may not. One side does not fit all. The solution, if it does, is to not
modify the code, or not use it.

> > This is always the problem when using open source. One licence wants all
> > the adapted code to be released and the other says you can't....
> >
>
> 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.

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

Chris Hills wrote:
> In article <TiCNg.12798$Mh2.9757@newsfe6-win.ntli.net>, Peter Dickerson 
> <first{dot}surname@tesco.net> writes
>> I have also had my attention directed towards commercial FAT support code
>> that has support for LFN. I'm still investigating that. I'm fairly 
>> sure it
>> can do what I want but I'm not clear whether there is more work 
>> integrating
>> with my other requirements than adding LFN to open/free/public code.
> 
> The problem is that you may have a conflict as you could not release the 
> source code with the commercial stuff in it. The Open source may require 
> you to release the modified code...
> 
> This is always the problem when using open source. One licence wants all 
> the adapted code to be released and the other says you can't....
> 

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.

> 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.

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:
> Didi wrote:
> > > 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.
> >
> > I liked this quote. It fits well the way I see the planet today:
> > overcrowded of useless people fiercely elbowing each other in the
>
> 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.

Didi wrote:
> > 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.
>
> I liked this quote. It fits well the way I see the planet today:
> overcrowded of useless people fiercely elbowing each other in the

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.

> 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.

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:
> Chris Hills wrote:
>
> > >a) IP issues are the biggest barrier to entry into the embedded
> > >engineering market, and
> >
> > How so?
>
> 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.
> 
> [.............]

Chris Hills wrote:

> >a) IP issues are the biggest barrier to entry into the embedded
> >engineering market, and
>
> How so?

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.

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

"larwe" <zwsdotcom@gmail.com> wrote in message
news:1158147241.041089.19510@i42g2000cwa.googlegroups.com...
>
> Peter Dickerson wrote:
>
> > Actually, in the case of FatFS the terms are "You can use, modify and
> > republish it for non-profit or profit use without any limitation under
your
> > responsibility". Not that I necessarily want to do that. I think that if
I
> >
> > It seems DosFS has a similar, though more wordy, license.
>
> I tried to make it as succinct as possible, but I needed to have the
> major bases covered.

Yes. I wasn't trying to imply anything odd. I was just justifying not
quoting the license verbatim.

> 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.

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

> 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.

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.

> 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.

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.

> 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.

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

Peter

Peter Dickerson wrote:

> Actually, in the case of FatFS the terms are "You can use, modify and
> republish it for non-profit or profit use without any limitation under your
> responsibility". Not that I necessarily want to do that. I think that if I
>
> It seems DosFS has a similar, though more wordy, license.

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.