A long time ago we planned for SPI to protect Debian developers from
liability connected with their development of Free Software. That never
came to fruition. With the sword-rattling going on by various patent
holders, it's a goal even more worth carrying out today.
Some of us have homes,
97201
Thanks
Bruce Perens
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
who brings a resume. Free
beer, as they say.
But if the consensus of the other folks on debian-devel is that this
message did not belong there, I will apologize and withdraw it.
Thanks
Bruce
Adam Heath wrote:
On Tue, 2 Aug 2005, Bruce Perens wrote:
For those of you who are at OSCON
Wouter Verhelst wrote:
I don't know what the essense of Free Software is to you;
You do so. I created the DFSG. It defines what the essense of Free
Software is not only to me but to this project.
However, to me, the essense of Free Software is that it allows one to
modify the software
Michael K. Edwards wrote:
What part of "normally distributed ... with ... the operating system"
is confusing?
The license requires that the source code all of the pieces that
constitute a derivative work of some original piece of GPL code
must be provided. This would be the original GPL
Wouter Verhelst wrote:
Indeed; however, IMO excerting the right to modify as defined by the
DFSG should never result in the loss of support, or other negative
consequences, because in that case you might as well not have it. This
type of certification does carry that kind of negative consequence.
Michael K. Edwards wrote:
Hopefully this continues to be interesting to debian-devel readers.
It's not even interesting to me, and I hope that someone of greater
legal competence sets you right and ends the discussion.
The LGPL requires that the creator of a derivative work provide
So, I did this a few days ago, and ddcprobe was not in any Debian
package. Also, it got the mouse as /dev/input rather than
/dev/input/mouse, and the resulting X configuration didn't work. It
would be really nice if it worked.
Thanks
Bruce
Petter Reinholdtsen wrote:
Do you want a working
Olaf van der Spek wrote:
Is that really JPEG? Or JTAG?
That's all we need, lossy ROM image compression :-) Yes, JTAG.
Thanks
Bruce
Wouter Verhelst wrote:
'ISV' is just another name for 'Software Hoarder'.
Please keep in mind this portion of Debian's Social Contract:
We will support our users who develop and run non-free
software on Debian
One of the reasons for this is that you can get more people to
appreciate
Michael K. Edwards wrote:
Agreed there needn't be development tools on the target system. But
the development system itself needs to be fully and accurately
specified, both among the participating distros and to the end users.
That's what it takes to satisfy the letter of the GPL, at
Wouter Verhelst wrote:
To address these issues, the Free Software people created the LSB
When I founded the LSB, the job I proposed for it was to do what the
LCC is now proposing to do. I didn't believe that a paper standard
alone would be effective at resolving cross-distribution
Manoj Srivastava wrote:
I am not sure I am convinced that the benefits are worth
outsourcing the core of our product -- and I think that most business
shall tell you that is a bad idea.
Well, please don't tell this to all of the people who we are attempting
to get to use Linux as the core of
Manoj Srivastava wrote:
Hmm. Does this not impede Debian in new directions we may like
to take the distribution, like, say, making Debian be Se-Linux
compatible, if we so choose?
I think it means that Debian gets to be leader regarding the things it
cares about. I doubt that the other
Manoj Srivastava wrote:
Hmm. I am not sure how to take this: either you are spoiling
for a fight, or you do not take your duties as a developer very
seriously.
I was taking the implications of your statements farther than you
intended, in order to get you to give them additional
Bill Allombert wrote:
But overriding them means we lose the certification ?
We can't allow it to be the case that overriding due to an existing and
unremedied security issue causes loss of certification. There's no
common sense in that.
Thanks
Bruce
smime.p7s
Description: S/MIME
Manoj Srivastava wrote:
So it was inflammatory, then. Comes under spoiling for a fight.
Only if you confuse Socrates and Sophism.
So, which version of flex you think you want to ship?
Fortunately, flex isn't in the problem space. If you stick to what
version of libc, etc., it'll make
Bill Allombert wrote:
Then could you elaborate the scope of the certification ?
It's still a matter for negotiation. If the certification won't admit to
common-sense rules, it won't work for anyone - not just Debian.
Thanks
Bruce
smime.p7s
Description: S/MIME Cryptographic Signature
Michael K. Edwards wrote:
binutils and modutils both depend on it.
On flex? No. At least not in unstable.
However, Debian seems to have addressed the issue by providing both
versions of flex. I don't see what would prevent us from going on with
that practice.
Or is the LCC proposing to
Steve Langasek wrote:
On flex? No. At least not in unstable.
Yes, it does.
Oh, you mean build-depends.
Not standardizing the toolchain used to build a set of standardized binaries
would seem to leave the LCC open to a repeat of the gcc-2.96 fiasco,
however...
The
Ron Johnson wrote:
The *price* of product has *nothing* to do with how much it *cost*
to create.
In a purely competitive market the price of goods would
approach their cost. The system of "intellectual property" is a barrier
that prevents certain goods from becoming commodities. There
Kenneth Pronovici wrote:
Aha, I see where you found this in my original note (although you didn't
quote it). In that paragraph, thousands of dollars was just an
example for illustration, although I chose the magnitude of the cost
from one of the links Bruce posted (I recall seeing a $5400
Darren Salt wrote:
A lot of these BLOBs have been identified as ARM7 code, and generally
"thumb" (the 8-bit ARM instructions).
No. THUMB is a 16-bit instruction set.
Oops. You're right.
Thanks
Bruce
smime.p7s
Description: S/MIME Cryptographic Signature
Marco d'Itri wrote:
The reason for this is not only the additional cost of the flash chip,
but also that (good) devices which use flash need to be more complex:
you would have to add a programming device, possibly a dual power supply
to drive it and you would need anyway some intelligent enough
Matthew Garrett wrote:
Non-free code in flash is no more or less a problem than non-free code on disk.
Except that we have to distribute it. If the manufacturer is so
concerned about their code that they can't disclose its source, they
should hide the code on the device, below the bus
Andrew Suffield wrote:
Come on, this argument is from the 1980s, and your side *lost* in the real world. Free software is here.
It's sort of silly to say my side lost, in this context. I'm
trying to make Free Software usable by all people and have been doing
so since sometime in the
John Hasler wrote:
The embedded code is essentially a driver for the internal device and reveals only a limited amount about how it works. Exactly how much it reveals depends on the design and varies a lot.
Well, for embedded programming to make sense you really need to document
everything
Matthew Garrett wrote:
No, you're missing the point. I understand that there are practical
arguments against this desire for freedom, but that doesn't alter the
philosophical basis - as far as freedom is concerned, there is no
difference in having non-free code in ROM or on disk.
Yes, but
Andrew Suffield wrote:
On Mon, Dec 13, 2004 at 11:07:35AM -0800, Bruce Perens wrote:
It will take fund-raising to do it.
^##$@@. There goes that "free software is impossible" argument again.
Well, maybe I'm doing the wrong thing to feed a troll like this
Andrew Suffield wrote:
There is absolutely no reason why any money is needed for this. Design the damn thing.
My personal EE skill is insufficient for the task. I can help someone
else get it done.
Regarding how much money it takes, it's a matter of how soon we want
it. I've no doubt that
Hamish Moffatt wrote:
Manufacturing an ASIC involves NRE (non-recurring engineering) costs of
hundreds of thousands to millions per revision.
If you haven't looked at OpenCores.org yet, please do so to get an idea
of how far they have been able to carry this so far.
I have priced this out as
Goswin von Brederlow wrote:
Your opinion (and I would generaly agree there) would be that the
pseudo source files released are not source as per GPLs definition
A lot of these BLOBs have been identified as ARM7 code, and generally
thumb (the 8-bit ARM instructions). They come from C or
Goswin von Brederlow wrote:
Imagine a source where all variables are named vnumber and all
functions fnumber. Is that still free? Where do we draw the line?
When does source stop to be bad style and start to become obfuscated
and unacceptable for main?
This has been handled before. Some
Glenn Maynard wrote:
contrib exists for software which is free but fails SC#1, we will never
make the system depend on an item of non-free software. Moving something
from contrib to main that does, in fact, depend on such an item is a pretty
basic violation of Debian's principles.
It's not
Hamish Moffatt wrote:
And 4. They're not allowed to by regulations, eg wireless hardware
whose firmware cannot be distributed by FCC rule.
It's not at all clear to me that the type-approval process depends on
security by obscurity in the firmware. Some manufacturers may think it
does, but I
Tim Cutts wrote:
Maybe not most, but many, and the proportion is increasing. If we
force these into contrib, then a lot of hardware will not work out of
the box for people trying to install Debian. Especially wireless
cards on laptops.
This is likely to put people off the distribution.
This
Tim Cutts wrote:
If Debian tries to be too rigid, we run a serious risk of consigning
ourselves to history, because people just won't install Debian any
more if it doesn't work out-of-the-box on most hardware - and the time
is pretty much already here that most systems contain at least one
Is a driver that loads a BLOB Free Software? The problem is connected
with distribution. The BLOB is unquestionably software. It runs below
the bus, which is our usual demarcation between Free Software
and the rest of the system, but it starts life above the bus at boot
time, and we have to
Wouter Verhelst wrote:
That assumes all non-free (as in speech) firmware is also non-free (as
in beer). This is simply not true; in fact, since they are in the
kernel, I'd think they are free (as in beer).
Actually, a number of device manufacturers have not allowed sublicensing
of their BLOBs.
Glenn,
If you don't have a physical copy of the device, the driver doesn't
work either. Very similarly to the way it would act if you don't have
the firmware. The problem is that we have to distribute the
firmware when it's a BLOB.
Thanks
Bruce
Glenn Maynard wrote:
If the driver has
Goswin von Brederlow wrote:
Apart from being ugly the above is perfectly legal and nothing speaks
against adding it, _provided_ this is the source. I have actually seen
GPL sources with such byte sequences in it for cases where the
toolchain couldn't emit the right opcodes.
Yes, but in
Matthew Garrett wrote:
How does moving firmware from the disk to the hardware (therefore making
it harder to modify and more expensive) further the cause of free
software?
If you want to drive manufacturers to open their firmware, it doesn't. I
am not sure that we should be driving
Brian Nelson wrote:
We're not really in any position to say where firmware belongs.
We are in a position to say what sort of hardware we want to support.
Indeed, we have a lot to say about that. I guess I should write it down.
Flash memory has a finite life, and repeatedly flashing it will
Glenn Maynard wrote:
It's free, but it has a non-optional dependency on non-free software, which
means contrib, not main.
In the case of a device driver, that dependency would still be there if
the firmware was in ROM. Which would put pretty much all of our device
drivers, X (talks to VESA
Goswin von Brederlow wrote:
Also why would anyone be forced to distribute the blob? The problem
isn't that we have to distribute the blob. The problem is how free
do we judge the driver to be.
We judge that by the DFSG. The DFSG doesn't include any language about
dependencies on non-free
William Ballard wrote:
What makes you think you'll be any more successful than when the Unix
Consortium tried to do the same thing for Unix?
The members considered that they had proprietary value at the level at
which they were collaborating. We conclusively do not, because of the
Open
Jim Gettys wrote:
Pay for say, and centralized development teams funded by such payers, are a major trap.
Let's make sure to keep giving OSDL that message.
Thanks
Bruce
smime.p7s
Description: S/MIME Cryptographic Signature
Michael K. Edwards wrote:
Fixing ABI forks, and articulating best known practices about managing
ABI evolution going forward, that's a good idea. Building an open
source test kit that exercises the shared ABIs, validating that the
test kit builds substantially the same on each distro, and helping
Greg Folkert wrote:
I will strongly oppose any shared binaries. I don't want any RPM shoved down my
throat.
One is not equal to the other. It's entirely possible to have a single
package source that builds into both RPM and DEB.
I would like to use see a shared usage of the same Source Core
Steinar H. Gunderson wrote:
So given that Debian's release schedule once again slips past 18 months, do
we have to wait another 18 months to get etch out?
I don't see why, we don't do that for X or GNOME or anything else.
But some of us don't want to see Debian's release schedule slip again. I
Goswin von Brederlow wrote:
And how will you get the other members to support architectures they do not support?
They would have to support merging in of source-code changes for all
architectures that any member builds. They would not be called upon to
compile those architectures.
And that
Steinar H. Gunderson wrote:
Then I don't see what you mean by synchronization.
You use the LCC version available to you at the time you release,
whatever that is. It may make sense for you to schedule your release to
come some months after the LCC's, but I can't see that you have to do
[EMAIL PROTECTED] wrote:
Akamai is fully able to turn customers away, and has done so for various reasons (e.g. the customer is a spammer).
That's the key. And we had a posting from Joe Alewin that was most
informative on this topic.
For an example of a non-discriminatory mirror, consider the
The Linux Core Consortium would like to have Debian's involvement. This
organization has revived what I originally proposed to do as the LSB -
to make a binary base for Linux distributions that could be among
several distributions who would share in the effort of maintaining
certain packages.
Steve,
Henrique answered your question. There has been some divergence between
various distributions regarding the naming and especially the
versioning of these libraries. We would heal that fork to increase
compatibility. Doing that means that some names and version tags are
going to change
Steve Langasek wrote:
Changing library *names*, OTOH, is something quite different -- and in the
first case, providing "compatibility with the old names" totally defeats the
purpose of *having* sonames, whereas in the second case, it still sounds
like gratuitous change to me.
Steve,
I
Andrew Suffield wrote:
Also, in much of the civilised world, once you start doing this you
suddenly acquire a legal responsibility to do it *right*, which you
wouldn't have had if you hadn't tried to do it.
It's more complicated than that. I think what you are talking about is
the fact that a
Manoj Srivastava wrote:
Oh, and if we do not specify what the nature of what we package, would it be
easier to prove we merely carry packages? That would really be nice.
A common carrier carries content from one external point to another as
directed by the parties exchanging the content without
Goswin von Brederlow wrote:
But that would not include any debian mirror, they would be common carrier?
A mirror operator in general does make choices about the
content carried on the mirror. The closest analogy that would already
have been litigated is a Cable TV system. The U.S. FCC
The telling part of the GWU policy is:
This provision explicitly prohibits any behavior that is
intended to or has the effect of creating an intimidating, hostile, or
offensive environment because of an individual's sex, race,
color, religion, national origin, age, pregnancy, sexual
Thomas Bushnell BSG wrote:
Good grief, this is one of the murkiest areas of American law, and you
think that anyone should be convinced of your FUD this way?
Would you please stop asserting that I'm out to FUD you? Given my
history I would hope that you could take for granted that I
Thomas Bushnell BSG wrote:
When invited to *reduce* uncertainty and doubt, by securing a genuine
legal opinion, you said it was Not Your Job.
What I continue to object to is that there is a minority who believe
that questionable content is desirable in the distribution, but they
refuse to
Ron Johnson wrote:
That's true. Debian doesn't *have* to be mirrored *anywhere*.
I have not so far seen what you are going to tell the mirror operators
so that they know what packages to reject. Surely you can not believe
that they are all responsible to dig this information up on their own.
Thomas Bushnell BSG wrote:
But it seems that now you're telling me that you know better than the
mirror operators which packages will violate their internal policies.
Certainly a good guess is better than nothing. Upon such a list it
would be possible to err on the side of caution and
Ron Johnson wrote:
Legal, illegal, what's the difference? *I* want to package it.
Therefore, anyone who tries to stop me is censoring me.
Nobody can stop you from creating a package of it. Folks on the Debian
project can collectively decide whether or not the project should be a
party to
Manoj Srivastava wrote:
Who's we here, kemo sabe? Last I looked, you are not a project member.
You haven't looked in a while.
Bruce
smime.p7s
Description: S/MIME Cryptographic Signature
Thomas Bushnell BSG wrote:
Currently the only procedure we have in place for this, short of
convincing the maintainer to withdraw it, is a GR.
Yes, I will work on that.
And, IIRC, you aren't one of those folks anyway, right?
No, that's wrong. I was added to the active Debian developer keyring
This is not a policy proposal yet, when I have that I will bring it to
debian-project.
The entire Debian Social Contract is driven by a desire for social
justice. But when I proposed it I only wrote about software. During the
whole month that we discussed and refined the thing, I don't
Andrew Suffield wrote:
Is Debian a legal entity? The answer is unquestionably yes.
Where do you get these ideas? Debian is unquestionably not a legal
entity.
There is simply no way to avoid being one.
An unincorporated association is what your organization
Thaddeus H. Black wrote:
025A LATIN SMALL LETTER SCHWA WITH HOOK
025E LATIN SMALL LETTER CLOSED REVERSED OPEN E
0261 LATIN SMALL LETTER SCRIPT G
0264 LATIN SMALL LETTER RAMS HORN
0267 LATIN SMALL LETTER HENG WITH HOOK
027A LATIN SMALL LETTER TURNED R WITH LONG LEG
027F LATIN SMALL LETTER
Philippe De Swert wrote:
Hello all,
I am just wondering if it is not the responabilty of the actual Debian user not to
violate his local laws.
It's the responsibility of people who live in a jurisdiction to not
break their local laws. Not just users, but everyone involved in any
way. What is
Andrew,
I worked on the patent and copyright issues because Debian and indeed
all of Free Software would be up the river if people did not work on it.
I have arranged more than $120K of grants to work on this since leaving HP.
That is not the case for packages with questionable images and
Josselin Mouette wrote:
Then maybe we could research whether this material is questionable at
all. It's not as if hot-babe contained pr0n pictures.
Yes. Currently, every time the problem comes up we argue about our own
individual definitions of what is and is not questionable because we
have
Andrew M.A. Cater wrote:
You're looking at this from a US-centric viewpoint, Bruce, and extending this
to the whole Project.
Because I am one of the people with legal responsibility for the U.S.
incarnation of the project. I acknowledge that there are many other
jurisdictions where our people
Ron Johnson wrote:
Would country/region-specific jigdo files be a reasonable
solution?
I don't think we've enumerated all of the data paths that can generate
problems. I guess jigdo means the general category of CDs. To that I
would add the package list presented by the various apt frontends.
Steve Greenland wrote:
Okay everybody, repeat after me: Choosing not to distribute a given
package is NOT censorship. We are not telling people that they can't
install, use, and/or distribute the package, just that we don't care to
make it available as an official Debian package from our servers.
Andrew Suffield wrote:
What is actually happening here is that one individual Debian developer is choosing to distribute a given package, and some other developers are trying to stop them.
No developer has attempted to stop another developer from distributing
that package. All that has been
Thomas Bushnell BSG wrote:
Maybe we should have such a process; maybe not. But regardless, the
current process allows each individual developer that judgment.
All Debian process is a result of having a problem, and not having a
process. The problem in this case is that a lot of people think
Thomas Bushnell BSG wrote:
<>Of
course. But you haven't proposed a process, so why are you
complaining about us using the process we have?
If I do all of the work, I'll win arguments about the policy. That's OK
with me, but some of you might want to get there first.
Thanks
Bruce
Thomas Bushnell BSG wrote:
If you believe there are legal issues, and you as a member of the
board of SPI are not willing to help resolve them, then you should
resign from the board.
Oh come on Thomas. I carry more than my share of the load. Once in a
while I have the right to ask someone else
What I am saying is that if I sit down and work out all of the
implications of a questionable material policy, and nobody else does, I
will be presenting research and worked-out logic and the folks who did
not want to do the work will be hand-waving. Who do you suppose will win
that argument?
Andrew Suffield wrote:
The project does not exist as a legal entity.
It's more complicated than you think.
Is Debian a legal entity? The answer is unquestionably yes. The only
question is what kind of legal entity it is. The most likely two are:
1. An unincorporated association that has a
Thomas Bushnell BSG wrote:
Either way, if you wish to claim there is a legal problem with a given package,
it is your responsibility to substantiate your claim beyond raising FUD.
I doubt it will be the last questionable package that is submitted, and
would like to handle the issue before the
Thomas Bushnell BSG wrote:
It strikes me that some of the material in question would be in
violation of the Internet policies of most institutions or companies
that host our mirrors, as well as the applicable national laws.
Can you please provide some concrete evidence of
There are a few people who are most likely to be prosecuted over legal
issues in Debian packages that have adult themes. They are the SPI
directors, and those affiliated with any registration or incorporation
of SPI or Debian in countries other than the U.S. There is the potential
for us to
David Weinehall wrote:
The ITP contains a link to the source for the package.
You *really* need to have a look at the pictures. All of your
argumentation below about pron neatly goes *wooosh*.
I'll take your word. However, we seem to be lacking some process here. I
don't have a guideline at hand
Henrique de Moraes Holschuh wrote:
If we just move them all to non-us, would that solve the problem?
It might help. Of course this is not only a U.S. problem. Some of our
developers live under religious law. I hear that there are places where
you can get your hand cut off for certain law
Andrew Suffield wrote:
Oh come on, they're at far greater risk from our overly-permissive
approach to copyright and patent issues.
The copyright and patent problems faced by Debian are issues that we
have studied in depth. Indeed, working on that has taken up a good deal
of my life for the past
Theodore Ts'o wrote:
Why does Group 1 really care about running under Linux, as opposed to some other OS? Is it really about price sensitivity? If so, it's surprising because to the extent that they pay $50,000 for Oracle, or $1,000,000+ for SAP R/3, why should they care about the cost of
I did a first pass at the UserLinux white paper, it's at
http://userlinux.org/white_paper.html. I think I'll sleep for a while.
Thanks
Bruce
.
Thanks
Bruce
--
--
Bruce Perens [EMAIL PROTECTED] 510-526-1165
Perens LLC / 1563 Solano Ave. / PMB 349 / Berkeley CA 94707 / USA
Ted,
The problem you mention manifests itself this way. A number of shops
will standardize on the Linux that Oracle endorses. 99% of the systems
upon which that Linux runs do not host Oracle, but they don't want to
have to know two systems. And thus they end up paying so much for Linux
that
Zennan,
Thanks. I can't get to your site at the moment.
I have just closed out some customer work that has been taking up 100%
of my time, and am today writing a manifesto that I will post at
userlinux.com . I will read the debian-devel postings and, hopefully,
your site before I do that.
I
David B Harris wrote:
(I don't know if you're subscribed to debian-devel@lists.debian.org, so
I am resending this mail here.
It's best to copy me on things you want me to read. Also note that mail
that doesn't have my address in the To: or Cc: field won't go to my main
inbox and is usually
and to help a non-French-speaker
celebrate. I will have slept on the plane, and should be reasonably alert.
Please reply within the next 24 hours, I'll have wireless email until they
close the plane. Airline and hotel information is below.
Thanks
Bruce Perens
Bruce Perens
United Airlines
Flight 960
Jul 13 18:25 depart SFO
Jul 14 13:55 arrive CDG
* Hotel Information *
Holiday Inn Par St Germain Des Pres
/ 92 RUE DE VAUGIRARD /
*Telephone:* 33-1-49-54-87-00
*Fax Phone:* 33-1-49-54-87-01
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Hi Thierry,
For the broader LSM, I can do an embedded systems course, using the
text of my series Building Tiny Linux Systems which is running in
Embedded Linux Journal. The text of the series is being released
under the GFDL.
For the Debian part of the meeting, I could say something about use
From: Roland Bauerschmidt [EMAIL PROTECTED]
Speaking of IA-64: Do we have a machine yet? AFAIK not. Do you think HP
would be willing to make one availible to Debian?
Please verify the situation regarding ia64 and get back to me.
Sorry about the list posting. I just hit r without looking.
I built gtkhtml 0.8 and evolution 0.8 on unstable. Evolution says Can't
initialize the Evolution shell.
This appears to be a CORBA problem. Before I dive in, has anyone else dealt
with it?
Thanks
Bruce
Ettore set me straight. The problem is that oaf is not looking in
/usr/local/share/oaf , and if you do the default installation, CORBA
won't work. Move the contents of /usr/local/share/oaf to /usr/share/oaf .
Run oaf-slay. Various GNOME applications die. Start evolution.
There may be a policy
1 - 100 of 387 matches
Mail list logo
