> "David Schwartz" <[EMAIL PROTECTED]> writes:
> > I don't know who told you that or why, but it's obvious nonsense,
> Correct.
> > Exports should be marked GPL if and only if they cannot be used
> > except in a derivative work. If it is poss
> The reason I added GPL is not because of some idea that this is all
> "chummy" with the kernel. But because I derived the mcount code from
> glibc's version of mcount. Now you may argue that glibc is under LGPL
> and a non-GPL export is fine. But I've been advised that if I ever take
> code from
Marcel Holtmann wrote:
> Lets phrase this in better words as Valdis pointed out: You can't
> distribute an application (binary or source form) under anything else
> than GPL if it uses a GPL library.
This simply cannot be correct. The only way it could be true is if the work
was a derivative wor
> Don't ignore, "mere aggregation of another work not based on the Program
> with the Program (or with a work based on the Program) on a volume of a
> storage or distribution medium does not bring the other work under the
> scope of this License." Static linking certainly makes something part
> o
> IANAL, but when looking at the "But when you distribute the same
> sections as part of a whole which is a work based on the Program, the
> distribution of the whole must be on the terms of this License" of the
> GPLv2 I would still consult a lawyer before e.g. selling a laptop with a
> close
Adrian Bunk wrote:
> The Linux kernel is licenced under the GPLv2.
>
> Ndiswrapper loads and executes code with not GPLv2 compatible licences
> in a way in the kernel that might be considered similar to a GPLv2'ed
> userspace program dlopen() a dynamic library file with a not GPLv2
> compatib
Combined reponses to many fragmented comments in this thread. No two
consecutive excerpts are from the same person.
> Interesting... I never heard about this `transferring ownership of a
> single copy not involving GPL'.
>
> Note that some lawyers claim that at trade shows, you should not hand
> I wouldn't quite say that. I wasn't going to comment, but...personally,
> I actually disagree with the assertions that ndiswrapper isn't causing
> proprietary code to link against GPL functions in the kernel (how is
> an NDIS implementation any different than a shim layer provided to
> load a gr
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > Nonsense. The 'kfree' function *destroys* the object pointer to by the
> > pointer. How can you describe that as not doing anything to the object?
>
> Here's an idea. Think it through.
>
> Why don't w
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > > "const" has nothing to do with "logical state". It has one
> > > meaning, and
> > > one meaning only: the compiler should complain if that
> > > particular type is
> > >
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > No, that's not what it means. It has nothing to do with memory.
> > It has to do
> > with logical state.
> Blah. That's just your own made-up explanation of what you think "const"
> should mean. It
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > Which does change the thing the pointer points to. It goes from being a
> > valid object to not existing.
> No. It's the *pointer* that is no longer valid.
The pointer is no longer valid because the object it pointed t
Jan Engelhardt wrote:
> On Dec 21 2007 17:56, Herbert Xu wrote:
> >>
> >> I do not believe "opinions" are relevant here. Relevant would be cites
> >> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
> >> show they do not need a full stop.
> >>
> >> I've not found one, but I
> Has anyone *proven* that using uninitialized data this way is safe?
You can probably find dozens of things in the Linux kernel that have not
been proven to be safe. That means nothing.
> As
> a *user* of this stuff, I'm *very* hesitant to trust Linux's RNG when I
> hear things like this. (Hin
> The bottom line: At a cost of at most three unpredictable branches
> (whether to clear the bytes in the last word with indices congruent
> to 1, 2, or 3 modulo 4), then the code can reduce the risk from something
> small but positive, to zero. This is very inexpensive insurance.
> John Reiser
Kyle Moffett wrote:
> That is a *terrible* disgusting way to use yield. Better options:
>(1) inotify/dnotify
Sure, tie yourself to a Linux-specific mechanism that may or may not work
over things like NFS. That's much worse.
>(2) create a "foo.lock" file and put the mutex in that
Right
Phillip Susi wrote:
> What good does using multiple levels of RNG do? Why seed one RNG from
> another? Wouldn't it be better to have just one RNG that everybody
> uses? Doesn't the act of reading from the RNG add entropy to it, since
> no one reader has any idea how often and at what times oth
> heh, along those lines you could also do
>
> dmesg > /dev/random
>
>
>
> dmesg often has machine-unique identifiers of all sorts (including the
> MAC address, if you have an ethernet driver loaded)
>
> Jeff
A good three-part solution would be:
1) Encourage distributions to do "dme
> > A scope probe will allow you to see if there is
> > a clock signal. That's all. You can't determine
> > its quality. A 4-inch ground lead on the scope
> > probe will result in 10-20% overshoot and undershoot
> > being observed.
> I don't understand this 10-20% figure.
> (0V + 10-20% is still
> * Mark Lord <[EMAIL PROTECTED]> wrote:
> > Ack. And what of the suggestion to try to ensure that a yielding task
> > simply not end up as the very next one chosen to run? Maybe by
> > swapping it with another (adjacent?) task in the tree if it comes out
> > on top again?
> we did that too fo
Chris Friesen wrote:
> David Schwartz wrote:
> > I've asked versions of this question at least three times
> > and never gotten
> > anything approaching a straight answer:
> >
> > 1) What is the current default 'sched_yield' behavi
I've asked versions of this question at least three times and never
gotten
anything approaching a straight answer:
1) What is the current default 'sched_yield' behavior?
2) What is the current alternate 'sched_yield' behavior?
3) Are either of them sensible? Sim
> > Then init_net needs to be not GPL limited. Sorry, we need to allow
> > non GPL network drivers. There is a fine line between keeping the
> Why - they aren't exactly likely to be permissible by law
Really? What law and/or what clause in the GPL says that derivative works
have to be licensed
> Thanks for the help. Someday, I hope to understand this stuff.
>
> Larry
Any code either deals with an object or it doesn't. If it doesn't deal with
that object, it should not be acquiring locks on that object. If it does
deal with that object, it must know the internal details of that object,
> David Schwartz <[EMAIL PROTECTED]> wrote:
> >> Regardless of whatever verifications your application is doing
> >> on the data, it is not checksumming the ports and that's what
> >> the pseudo-header is helping with.
> > So what? We are in the ca
> Regardless of whatever verifications your application is doing
> on the data, it is not checksumming the ports and that's what
> the pseudo-header is helping with.
So what? We are in the case where the data has already gotten to him. If it
got to him in error, he'll reject it anyway. The receiv
> > I use libuuid and I assume libuuid uses some uuid generator support
> > from the kernel.
>
> No, it does not. It's pure userspace and may produce double UUIDs.
>
> > libuuid comes from a package that Ted's maintain IIRC.
> >
> > I (my company) use uuid to uniquely identify objects in a distrib
> What I suppose is that people porting BSD code to Linux don't mean
> closing the doors for back-porting changes. They are simply unaware
> or forget about the possibility of dual licensing. Obviously, each
> submitter should read Documentation/SubmittingDrivers, where it is
> explicitly stated.
> Another conclusion from the cited text is that in contrast with what
> was stated before on the gcc mailing list, it is not required to
> declare thread-shared variables volatile if that thread-shared data is
> consistently protected by calls to locking functions.
>
> Bart Van Assche.
It all de
Eric Dumazet wrote:
> Events are not necessarly reported "by descriptors". epoll uses an opaque
> field provided by the user.
>
> It's up to the user to properly chose a tag that will makes sense
> if the user
> app is playing dup()/close() games for example.
Great. So the only issue then is tha
> 6) Epoll removes the file from the set, when the *kernel* object gets
>closed (internal use-count goes to zero)
>
> With that in mind, how can the code snippet above trigger a removal from
> the epoll set?
I don't see how that can be. Suppose I add fd 8 to an epoll set.
Suppose fd
> Well, yeah. I know what you mean. However, at this moment, some gcc
> developers are trying really hard not to be total d*ckheads about this
> issue, but get gcc fixed. Give us a chance.
>
> Andrew.
Can we get some kind of consensus that 'optimizations' that add writes to
any object that the
I asked a collection of knowledgeable people I know about the issue. The
consensus is that the optimization is not permitted in POSIX code but that
it is permitted in pure C code. The basic argument goes like this:
To make POSIX-compliant code even possible, surely optimizations t
> Well that's exactly right. For threaded programs (and maybe even
> real-world non-threaded ones in general), you don't want to be
> even _reading_ global variables if you don't need to. Cache misses
> and cacheline bouncing could easily cause performance to completely
> tank in some cases while
> From: Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> Volume 3A:
>
>"7.2.2 Memory Ordering in P6 and More Recent Processor Families
> ...
> 1. Reads can be carried out speculatively and in any order.
> ..."
>
> So, it looks to me like almost the 1-st Commandment
Adrian Bunk wrote:
> even for dynamically linking including non-GPL code is not white but
> already dark grey.
IANAL, but personally, I think it's perfectly black and white.
No mechanical combination (that means compressing, linking, tarring, compiling,
or whatever) can create a work for copy
> On 10/04/2007 07:39 PM, David Schwartz wrote:
> > But this is just a preposterous position to put him in. If there's no
> > reproduceable test case, then why should he care that one
> > program he can't
> > even see works badly? If you care, you fix it.
&
David Miller wrote:
> Using an unpublishable benchmark, whose results even cannot be
> published, really stretches the limits of "reasonable" don't you
> think?
>
> This "SLUB isn't ready yet" bullshit is just a shamans dance which
> distracts attention away from the real problem, which is that a
> From the userlevel, can I get an estimate of "amount of entropy"
> in /dev/random, that is, the estimate of number of bytes
> readable until it blocks ? Of course multiple processes
> can read bytes and this would not be exact ... but still .. as an upper
> boundary estimate ?
>
> Thanks
> Yako
This is a combined response to Arjan's:
> that's also what trylock is for... as well as spinaphores...
> (you can argue that futexes should be more intelligent and do
> spinaphore stuff etc... and I can buy that, lets improve them in the
> kernel by any means. But userspace yield() isn't the answ
> yielding IS blocking. Just with indeterminate fuzzyness added to it
Yielding is sort of blocking, but the difference is that yielding will not
idle the CPU while blocking might. Yielding is sometimes preferable to
blocking in a case where the thread knows it can make forward progress even
i
Arjan van de Ven wrote:
> > It can occasionally be an optimization. You may have a case where you
> > can do something very efficiently if a lock is not held, but you
> > cannot afford to wait for the lock to be released. So you check the
> > lock, if it's held, you yield and then check again. If
> These are generic statements, but i'm _really_ interested in the
> specifics. Real, specific code that i can look at. The typical Linux
> distro consists of in execess of 500 millions of lines of code, in tens
> of thousands of apps, so there really must be some good, valid and
> "right" use of
> * Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > BTW, it looks like risky to criticise sched_yield too much: some
> > people can misinterpret such discussions and stop using this at all,
> > even where it's right.
> Really, i have never seen a _single_ mainstream app where the use of
> sched_
> > I think the real fix would be for iperf to use blocking network IO
> > though, or maybe to use a POSIX mutex or POSIX semaphores.
>
> So it's definitely not a bug in the kernel, only in iperf?
Martin:
Actually, in this case I think iperf is doing the right thing (though not
the best thing) a
Ack, sorry, I'm wrong.
Please ignore me, if you weren't already.
I'm glad to hear this will be fixed. The task should be moved last for its
priority level.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Chris Friesen wrote:
> > The yielding task has given up the cpu. The other task should get to
> > run for a timeslice (or whatever the equivalent is in CFS) until the
> > yielding task again "becomes head of the thread list".
> Are you sure this isn't happening? I'll run some tests on my SMP
>
> David Schwartz wrote:
> > Nonsense. The task is always ready-to-run. There is no reason
> > its CPU should
> > be low. This bug report is based on a misunderstanding of what yielding
> > means.
> The yielding task has given up the cpu. The other task should ge
> The CFS scheduler does not seem to implement sched_yield correctly. If one
> program loops with a sched_yield and another program prints out timing
> information in a loop. You will see that if both are taskset to
> the same core
> that the timing stats will be twice as long as when they are on
> "David Schwartz" <[EMAIL PROTECTED]> writes:
> > My point is that you *cannot* prevent a recipient of a
> > derivative work from
> > receiving any rights under either the GPL or the BSD to any protectable
> > elements in that work.
>
> Of cou
Kryzstof Halasa writes:
> "David Schwartz" <[EMAIL PROTECTED]> writes:
>
> > Theodore Tso writes:
>
> hardly
A apologize for the error in attribution.
> > Of course you don't need a license to *use* the derived work.
> > You never need
>
> And if you choose the GPL the code you distribute will be under the GPL
> *only* forever [1], so what value would be in shipping terms that are
> void?
Not true. You cannot chose the license that applies to other people's code. The
code you distribute contains protectable elements from diffe
Theodore Tso writes:
> Now, you don't need a licence from the original author to use
> the derived work. The author of the derived work only needs
> a licence from the original author to create a derived work.
> Do you think Microsoft users have licences from authors of
> the works MS Windows etc
> Do *you* read the GPL and tell me where exactly it does *explicitly*
> allow to change license notices at all. Ya know, that right is reserved
> by law and must be *explicitly* granted. So just not explicitly
> forbidding it isn't enough.
You are mistaken about the law and mistaken about the GP
Hannah Schroeter wrote:
> The original issue *was* about illegal relicensing (i.e. not just
> choosing which terms to follow, but removing the other terms
> altogether).
You are confusing two completely different issues. One is about removing
license notices, the other is about relicensing. One
> On Sun, Sep 16, 2007 at 03:19:41PM -0700, David Schwartz wrote:
> >[...]
>
> >If you take work that's under a dual-license and remove one
> >license notice
> >from it when you create a derivative work, every recipient of that
> >derivative work still
> You did say otherwise.
>
> Your claim was that "You can obtain, *from the GPL*, the right to remove
> a BSD license notice."
>
> This claim is bullshit.
No, it's not.
> You can get this right from the copyright holder, e.g. when he
> dual-licenced his code, but you can not get this right fr
Theodore Tso wrote:
Essentially, I agree with you. My only disagremeent with you is that I think
the problem starts sooner:
> However, consider a file which was originally BSD licensed. Now
> suppose it is modified (i.e., a derived work was created) and another
> author slaps on a BSD/GPL dual
> On Sun, Sep 16, 2007 at 05:29:56PM -0700, David Schwartz wrote:
>
> >...
> > Again, one more time:
> >
> > 1) You can obtain, from the GPL, the right to remove a BSD
> > license notice.
> >...
> I hope noone believes this bullshit you a
Adrian Bunk writes:
> On Sun, Sep 16, 2007 at 03:37:55PM -0700, David Schwartz wrote:
> > > Dual licenced code by definition explicitely states that you
> > > can choose
> > > the licence - otherwise it wouldn't be called dual-licenced.
> > You can
> Dual licenced code by definition explicitely states that you can choose
> the licence - otherwise it wouldn't be called dual-licenced.
You can choose under which license you would like to receive the right to
modify or distribute the code. But you cannot change the license that code
itself i
> JFTR, I do *not* think that that assessment was questionable. Unless the
> dual-licensing *explicitly* allows relicensing, relicensing is forbidden
> by copyright law. The dual-licensing allows relicensing only if that's
> *explicitly* stated, either in the statement offering the alternative, or
> Hello,
>
> is it expected that application sending 8900bytes datagram
> through 10Gbps NIC
> utilizes CPU to 100% and similarly the receiver also utilizes CPU to 100%.
> Is it something wrong or this is quite OK?
>
> (The box is dual single core Opteron 2.4GHz with Myricom 10GE NIC.)
It's extre
First, let me apologize if the tone of my other post came through as angry or
frustrated. Text can sometimes be misleading as to tone. I certainly wasn't
angry.
Second, let me say that I'm definitely not suggesting that you were wrong to
bring this to everyone's attention. Even if it turns out
> I was working on some unit tests and thought I'd give CFS a whirl to see
> if it had any impact on my workloads (to see what the fuss was about),
> and I came up with some pretty disturbing numbers:
> http://devloop.org.uk/documentation/database-performance/Linux-Ker
> nels/Kernels-ManyThreads-C
> Hi David,
>
> Thanks for your quick reply.
>
> > If that were true, anyone who could send those packets to your
> > machine would
> > be able to cause the system to hang too.
>
> You're right to say that :)
>
> > Perhaps you are feeding the packets
> > back in at too high a layer.
>
> Not really
> The problem happens like this:
> Once the socket is closed by the user-space application, there are
> still packets left in the module's queue. Now, the moment the kernel
> timer expires and the module propagates those packets up into the
> higher layer, the system hangs.
If that were true, any
> > 4) Threads are not in any infinite loop.
> This requires solving the Halting Problem. If your management is
> demanding this
> feature, I suggest informing them that it is mathematically impossible.
Christ, these academics! They take real world problems that engineers
actually *solve* e
> Wrong - I said "You can't complain about Person A doing X when
> you let Person
> B do X without complaint".
Yes, I can. There is no inconsistency between acting in one case and failing
to act in another. We need not act in every possible case where we could act
to preserve our right to act in
> > Yes, but this has to be done in writing and neither the BSD nor the GPL
> > license claim to allow this.
> Standard dual license texts do.
>
> Jeff
No, they don't. They simply state that *you* may obtain the right to
modify/distribute the work from either license at your option. They d
Daniel Hazelton wrote:
> > Your entire argument is based on the false assumption that
> > these licenses
> > are compatible. They are not. You cannot put code that was offered under
> > the GPLv2 into code that is licensed under the dual license and
> > distribute
> > the result.
> Then go yell a
> Mr. Floeter *CAN* request that his code be removed from said fork
> - his code
> is solely licensed (AFAICT and IIRC) under the BSD/ISC license
> and was only
> covered by the dual-license because it was integrated into a work that
> carried said dual-license. (I'm not sure how well such a revoc
Jeff Garzik wrote:
> Secondary parties have the power to grant or modify rights, if
> delegated
> to them by the original author.
Yes, but this has to be done in writing and neither the BSD nor the GPL
license claim to allow this.
> Relicensing and transfer of rights happens all the time. Ho
Alan Cox wrote:
> The ath5k C file in question (not the headers) seems to give recipients
> permission to further convey the work under a choice of two licences.
Correct.
> It doesn't say they must redistribute under both.
Correct. They need the right to redistribute the work, and they may obt
> Letting aside the legality of that change, why would such a change
> be needed ? The licensing is perfectly clear: the file is available
> under the ISC licence, OR the GPL licence. This doesn't cause any
> problem for the linux kernel. The ISC licence is perfectly compatible
> with the GPL (no
> - If you receive dual licensed code, you may not delete the license
> you don't like and then distribute it. It has to stay, because you
> may not edit someone's else's license -- which is a three-part legal
> document (For instance: Copyright notice, BSD, followed by GPL).
This is absol
> You miss the whole point of dual licencing:
>
> Sam has stated in the licence that the code can be distributed under the
> terms of the BSD licence, or alternatively it can be distributed under
> the terms of the GPLv2.
>
> Noone removed Sam's licence.
>
> Sam has offered a choice, and if y
> If this output-buffer has "4-bytes space remaining for process A",
> then a non-blocking write of process A could still encounter a locked
> mutex, if process B is busy writing to the output-buffer.
Of course.
> Should process A now block/sleep until that mutex is free and it can
> access the
> Hello.
>
> I'm new to kernel development and have some questions.
>
> 1. Why can't I divide with regular casting to double ((double)a /
> (double)b)? It gives me strange errors when compiling:
>
> WARNING: "__divdf3" [/root] undefined!
> WARNING: "__addf3" [/root/...] undefined!
> WARNING: "
> On Thu, 23 Aug 2007, Segher Boessenkool wrote:
> The combining, which I've mentioned *multiple*times* is
>
> if (atomic_read(&x) <= 1)
>
> and dammit, if that doesn't result in a *single* instruction, the code
> generation is pure and utter crap.
>
> It should result in
>
> cmpl $1,
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > By popular demand, here is release -v20 of the CFS scheduler. It is a
> > full backport of the latest & greatest v2.6.23-rc3 CFS code to
> > v2.6.22.5, v2.6.21.7 and v2.6.20.16. The patches can be downloaded
> > from the usual place:
>
> update
> There is a quite convincing argument that such an access _is_ an
> access to a volatile object; see GCC PR21568 comment #9. This
> probably isn't the last word on the matter though...
I find this argument completely convincing and retract the contrary argument
that I've made many times in this
> Hi, All
>
> We were looking at "[kernel]/lib/string.c"
> (http://lxr.linux.no/source/lib/string.c#L500)
>
> memcpy copies a part of memory to some other location
> but It will not work for all cases of overlapping
> blocks.(if the start of destination block falls
> between the source block)
>
>
> The problem is, O_NONBLOCK flag is not attached to file *descriptor*,
> but to a "file description" mentioned in fcntl manpage:
[snip]
> We don't know whether our stdout descriptor #1 is shared with
> anyone or not,
> and if we were started from shell, it typically is. That's why we try to
> res
> 2) Do close reader fd, but what results can then applications
> reliably expect? What would be the sane intention of applications
> closing reader fd? Do programmers expect all of the current results?
> Fredrik
Since there's no atomic "unlock and read" function, any code that could ever
close
> My company has been given documentation and the library source under
> the terms of an NDA with the chipset manufacturer. We are permitted
> to compile the library and distribute the resultant binary blob, but
> not release the source to the library.
> The binary blob is linked into the driver
> > My company has been given documentation and the library source under
> > the terms of an NDA with the chipset manufacturer. We are permitted
> > to compile the library and distribute the resultant binary blob, but
> > not release the source to the library.
> >
> > The binary blob is linked in
> I'm working on a driver for an ADSL modem which requires the use of a
> binary library from the chipset manufacturer. All my source code is
> GPL, so that others are free to distribute and modify the driver.
> After asking the FSF for advice and working through their FAQ, I've
> given permissio
> > Volanomark runs better
> > and is only 40% (instead of 80%) down from old scheduler
> > without CFS.
> 40 or 80 % is still a huge regression.
> Dmitry Adamushko
Can anyone explain precisely what Volanomark is doing? If it's something
dumb like "looping on sched_yield until the 'right' thread
> On 7/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> > v & 0x0F <=> v % 16
> Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Actually, it's the compiler's bad. That's a pretty fundamental equivalence that
the compiler should recognize for native integral types.
DS
-
T
> * Ian Kent <[EMAIL PROTECTED]> wrote:
>
> > Yes it does and I have two reported bugs so far.
> >
> > In several places I have code similar to:
> >
> > wait.tv_sec = time(NULL) + 1;
> > wait.tv_nsec = 0;
> >
> > signaled = 0;
> > while (!signaled) {
> > status = pthread_cond_timedwait(&co
> So I can say that in linux 'thread' == 'process'?
No. A process can have any number of threads.
> Is kernel routine 'kthread' creating a process?
No, since a process can have more than one thread.
> I'm just thinking on this subject: if to create 'real threads' - will
> it increase performan
> Hi!
> I have a question about NPTL.
> Are NPTL are still based on `clone` system call?
Yes.
> Are NPTL threads are
> "processes" internally?
No. By definition, all the threads belong to a single process. NPTL threads
are based on KSEs (kernel scheduling entities). A non-threaded process is
al
> > Treating ordinary use as a copyright privilege leads to
> > nonsensical results
> > no matter what you do. For example, you get that I can drop copies of my
> > poem from an airplane and then sue anyone who reads it.
> Who was talking about reading?
They are both ordinary use. It is crazy to
Alexandre Oliva write:
> > The GPL does sometimes use the word "may" where it's not clear
> > whether it
> > means you have permission or you must be able to. The general rule of
> > construction is that "may" means permission, unless there's some clear
> > indication to the contrary. The "may"s
> Let's hope courts see it this way.
> But then, why is it that I can't use hardware to stop someone from
> copying or modifying the source code, but I can use hardware to stop
> someone from copying or modifying the binary? Or is that not so?
You can use the hardware to stop someone from copyi
> Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass. This is not different from
> >> shipping binaries and sources in a CD inside a locked
> On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> > Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> &
Alexandre Oliva writes:
> Yes, but in the scenario I proposed, the source code *is* in the
> preferred form for making modifications, it just so happens to be
> behind a barrier you cannot trespass. This is not different from
> shipping binaries and sources in a CD inside a locked box that you
>
[EMAIL PROTECTED] wrote:
> this sounds like a step backwards, you may not have the sources at that
> point if you were relying on the other site to host them.
You would then be violating the GPL, under any version. The GPL is quite
clear that being unable to comply with it means you do not get t
1 - 100 of 340 matches
Mail list logo
