**** BEGIN LOGGING AT Fri Jul 29 02:59:58 2016
Jul 29 04:52:44 <pabs3> https://lwn.net/SubscriberLink/695559/4cb7cc45204f557b/
Jul 29 05:43:41 <PaulFertser> DocScrutinizer05: hm, our "competitors" have granted codes to some of the projects that we covered: https://github.com/pidcodes/pidcodes.github.com/commits/master 
Jul 29 05:46:35 <PaulFertser> I feel some of our time would be wasted if those projects will use the code from pidcodes in the end.
Jul 29 05:49:50 <PaulFertser> DocScrutinizer05: I think both we and pidcodes should arrange a change to respective documentation that requires to cancel request if the user decides to ask from the other "vendor".
Jul 29 05:51:45 <PaulFertser> We have different terms too, for Openmoko it's enough that either hardware or software is free, but they require both if the project develops both.
Jul 29 05:58:16 <pabs3> indeed
Jul 29 05:58:43 * pabs3 suggests OM requiring both to be free
Jul 29 06:14:58 <PaulFertser> pabs3: well, I guess it was Harald who thought it's good enough to have either firmware or hardware free.
Jul 29 06:15:33 <PaulFertser> I'm not sure if it's really better to require both. E.g. Openmoko's HW wasn't free.
Jul 29 06:15:50 <pabs3> hmm
Jul 29 09:40:38 <DocScrutinizer05> we should decide from case to case whether something has the right _spirit_
Jul 29 09:41:12 <DocScrutinizer05> since we're granting something for free, we are also free to do that decission
Jul 29 10:31:08 <DocScrutinizer05> the reason to require both to be free - I think - is along the line of FSF trying to extort hw manufs to build open hardware, via licensing in GPL and #include tricks to make drivers impossible when they were not FOSS. ... Which didn't pan out that well, did it? HW manufs might simply have no choice to build what FSF and RMS want, so the alternative is either hw with non-free linux support, or hw with *no* linux support
Jul 29 10:32:54 <DocScrutinizer05> In my humble oppinion it's way more important if the *spirit* of the project is compliant with the FOSS community
Jul 29 10:49:40 <DocScrutinizer05> btw which guarantees do the kernel devels give a hw manufs that whatever FOSS compliant support for their hw they provide will sustain when the kernel API/ABI changes once more?
Jul 29 10:51:27 <DocScrutinizer05> In germany we have a proverb "with bacon you catch mice" - the "let's *force* them" approach is quite misguided for a stratehy to convince hw manufs to support linux more
Jul 29 11:02:16 <DocScrutinizer05> I think what matters is: software free (as much as possible, a few percent blobs allowed when unavoidable), hw must be **freely available** so everybody can get it. When it's the person who maintains the project who provides the hw, then sufficient documentation must be provided to create or source identical hw when that maintainer stops to provide the hw
Jul 29 11:06:37 <DocScrutinizer05> thus we consider for example a widely available arduino or RPi board a blackbox module kust like the modem in a otherwise open hw phone. Unless it was the manufacturer of the blackbox module himself who asks for any support, in which case we would detect malicious spirit in not disclosing how to get the hw when the only source providing such hw would stop doing so, despite being in possession of all the needed data so they *
Jul 29 11:06:39 <DocScrutinizer05> could* disclose it
Jul 29 11:09:33 <DocScrutinizer05> I'm _very_ reluctant to provide an ID to a project that has open hardware but keeps all the software a blob. I don't see any benefit form OM/FOSS perspective in supporting such a project
Jul 29 11:10:26 <DocScrutinizer05> does all that above make any sense to you guys?
Jul 29 11:12:31 <pabs3> some things aren't clear to me: what does "**freely available**" mean for hardware? that it is in stock and you can pay money and get it shipped?
Jul 29 11:12:51 <DocScrutinizer05> yes, basically
Jul 29 11:12:59 * pabs3 would s/freely// in that case
Jul 29 11:13:44 <DocScrutinizer05> I'd specify it as "available from multiple sources" or "available form a 'trustworthy' source that is not affiliated to the project"
Jul 29 11:13:59 <pabs3> ack
Jul 29 11:15:15 <DocScrutinizer05> well, "available from at least one source that is not affiliated to the project, and not limited by any NDA or other requirements the customer has to comply with"
Jul 29 11:16:08 <DocScrutinizer05> however all those are guidelines and may be overridden by "the ID committee" any time
Jul 29 11:17:24 <DocScrutinizer05> e.g for GTA02 the availability of the calypso modem would be quite demanding to evaluate to the above ctiteria
Jul 29 11:17:54 <DocScrutinizer05> then OTOH a GTA02 would qualify for a free USB ID even without any modem, so...
Jul 29 11:19:19 <DocScrutinizer05> what I *don't* like to support is some company who builds some hardware and sells such hw without any docs but with FOSS sw
Jul 29 11:20:20 <DocScrutinizer05> they clearly have just commercial interest and don't really comply with "the FOSS spirit"
Jul 29 11:21:48 <DocScrutinizer05> as a very simple rule, the project maintainers need to do all they can do to comply with FOSS spirit as much as possible
Jul 29 11:23:23 <DocScrutinizer05> generally rules are made to circumvent them, so the less hard rules we have, the easier for us to decide in a sane way
Jul 29 11:24:43 <DocScrutinizer05> would be a pity if we couldn't support a project we like very much, just because we threw sticks at our own legs at the time we drafted and set into effect some hard rules
Jul 29 11:25:10 <DocScrutinizer05> ~7282
Jul 29 11:25:10 <apt> 7282 is probably https://tools.ietf.org/html/rfc7282 or >>We reject: kings, presidents and voting. We believe in: rough consensus and running code.<<
Jul 29 11:26:07 <DocScrutinizer05> the idea is to foster the FOSS community
Jul 29 11:29:50 <DocScrutinizer05> PaulFertser: just reading your mails. Bot answered, *great* \o/
Jul 29 11:34:59 <DocScrutinizer05> pabs3: do you see a chance to reject (or discard) as spam all mails to ML that consist of only or mainly chinese text?
Jul 29 11:38:39 <pabs3> I don't know of any software that does that
Jul 29 11:39:01 <pabs3> I wonder if you get any requests from Chinese folks though
Jul 29 11:45:38 <DocScrutinizer05> only spam
Jul 29 11:46:51 <DocScrutinizer05> [id] >> Hi Joerg, as it happens I no longer need a PID from you. I looked in to alternatives and found pid.codes so gave them a try too, they've come through and things have sorted themselves out....<<  
Jul 29 11:46:52 <DocScrutinizer05> Simon Wrafter <simon@teamuniti.XXX>
Jul 29 11:48:05 <DocScrutinizer05> we discussed uniting with pid.codes, quite some time ago. IIRC we didn't come to a final rough consent
Jul 29 11:48:39 <DocScrutinizer05> maybe ask THEM what they think about it?
Jul 29 12:12:23 <PaulFertser> So it's already two codes we assigned that won't get used, nice.
Jul 29 12:13:20 <PaulFertser> Hm, or not, we haven't assigned one to that joystick/gamepad guy.
Jul 29 14:27:42 <DocScrutinizer05> PaulFertser: btw I asked werner almesberger if he wants to join in with the whole USB-ID topic, but he answered >>naw, i'm quite anti-politics :)<<
Jul 29 14:30:13 <DocScrutinizer05> pabs3: (chinese, only spam) lots of that
Jul 29 14:31:13 <DocScrutinizer05> pabs3: http://wstaw.org/m/2016/07/25/plasma-desktopxe2277.png
Jul 29 14:32:27 <DocScrutinizer05> if somebody sends a honest USB-ID inquiry in all-chinese, they actually better rethink, I wouldn't even notice it was serious and no spam
Jul 29 14:34:22 <DocScrutinizer05> could we set up a filter on a mandatory keyword in subject? "inquiry" for example. Then publish this requirement on our wikipage next to the email addr
Jul 29 14:55:23 <pabs3> DocScrutinizer05: I think mailman should be able to do that, been a while since I looked at a mm list admin interface though
Jul 29 15:00:56 <DocScrutinizer05> hmm, I'll have a look, but despite I recall a lot of fancy features, I don't recall any _such_ feature being in the web frontend for ML admin
Jul 29 15:05:20 <DocScrutinizer05> there is >>Prefix for subject line of list postings.<< but that's something MM will add to the subject before sending it to all recipients. It's not a filter that gets applied on receiving new mails
Jul 29 15:14:01 <DocScrutinizer05> there is >>Should Mailman filter the content of list traffic according to the settings below? << which been "no" and I toggled to "Yes" now, however the filters provided are to strip attachments and multipart
Jul 29 15:21:11 <DocScrutinizer05> HEY, this sounds useful! >>The topic filter categorizes each incoming email message according to regular expression filters you specify below. If the message's Subject: or Keywords: header contains a match against a topic filter, the message is logically placed into a topic bucket<<
Jul 29 15:26:40 <DocScrutinizer05> pabs3: makes sense? http://wstaw.org/m/2016/07/29/plasma-desktopOi2277.png
Jul 29 15:28:23 <pabs3> mhmm
Jul 29 15:29:11 <DocScrutinizer05> I'm unclrear about implications regarding requesting a tipic by user, from >>Any message not categorized in a topic bucket registered with the user is not delivered to the list.<<
Jul 29 15:29:23 <DocScrutinizer05> topic
Jul 29 15:30:37 <DocScrutinizer05> how would user "register for a tiopic bucket"?
Jul 29 15:33:15 * pabs3 no idea
Jul 29 15:43:57 <DocScrutinizer05> hmm, no effect so far
Jul 29 15:48:17 <DocScrutinizer05> OOOH now! nevermind, there's a spamfilter option hidden in subsibmenu under privacy options
Jul 29 15:56:37 <DocScrutinizer05> what a mess
Jul 29 15:58:53 <DocScrutinizer05> I can define a default to reject (or discard) all non-member mails. But then it seems the spam filters don't apply, which makes me wonder what's the purpose of "Accept" action on spam regex. I fail to see how to define a spam regex that matches on *all but*  .*request.*
Jul 29 16:02:13 <DocScrutinizer05> meh, ok I need to inprove my regex fu
Jul 29 16:13:33 <DocScrutinizer05> surprisingly intricate :-/  http://stackoverflow.com/questions/1687620/regex-match-everything-but
Jul 29 16:16:45 * DocScrutinizer05 wishes mailman had a boolean chackmark "does [x]NOT match the following regex"
Jul 29 16:21:37 <DocScrutinizer05> I hope this is the solution: https://mail.python.org/pipermail/mailman-users/2006-November/054683.html
Jul 29 16:34:41 <DocScrutinizer05> pabs3: could you please review http://wstaw.org/m/2016/07/29/plasma-desktopNj2277.png
Jul 29 16:35:04 <DocScrutinizer05> rule2 is former legacy stuff - basically for ducumentation purposes
Jul 29 16:37:12 <pabs3> looks good
Jul 29 16:37:15 <DocScrutinizer05> :-)
Jul 29 16:42:59 <DocScrutinizer05> http://wiki.openmoko.org/wiki/USB_Product_IDs#Conditions
Jul 29 16:48:29 <DocScrutinizer05> now I just hope the test mail makes it eventually
Jul 29 16:58:28 <DocScrutinizer05> hmm doesn't work
Jul 29 16:59:13 <DocScrutinizer05> pabs3: seems no mail making it to the list now
Jul 29 16:59:29 <DocScrutinizer05> pabs3: could you have a look at whatever diagnostic output please?
Jul 29 17:00:24 <DocScrutinizer05> aah wait, it just took the usual 10 min, just mail canme in
Jul 29 17:05:20 <pabs3> 10 minutes seems long, there must be a bug somewhere
Jul 29 17:05:44 <pabs3> 1am here though, no investigation this $wake_period
Jul 29 17:14:08 <DocScrutinizer05> np, it generally works. I attribute the 10min wait to graylisting
Jul 29 21:11:12 <antrik> DocScrutinizer05: stop spreading FUD. the FSF certainly didn't try to "extort" HW makers with the GPL -- they don't even hold copyrights on any software that would be relevant to that
Jul 29 21:12:54 <antrik> they *do* think that proprietary drivers in Linux are probably violating the license AFAIK -- but there are other people who think so too, including some high-profile Linux developers. it's just none of the bothered or considered it a good idea to take legal action...
Jul 29 21:14:06 <DocScrutinizer05> please! this is no FUD, this are facts quoting the motivation behind GPL-v3 etc
Jul 29 21:15:48 <DocScrutinizer05> when I'd bother to search an hour, I most likely could even find original statements of RMS or related folks, elaborating on exactly this purpose to make it impossible to hw developers to provide non-FOSS linux drivers
Jul 29 21:17:48 <antrik> and that, very clearly, shows that you have no clue what you are talking about
Jul 29 21:18:07 <antrik> the provisions in the GPLv3 have nothing whatsoever to do with drivers
Jul 29 21:19:02 <antrik> they are about the ability to replace GPL components with your own variants on devices you own
Jul 29 21:20:07 <DocScrutinizer05> of course, you are so right and I have no clue, and I've been living under a stone since 15 years
Jul 29 21:22:57 <DocScrutinizer05> >>they *do* think that proprietary drivers in Linux are probably violating the license AFAIK<< is what you admit, and I say they did quite some effort to get there
Jul 29 21:24:00 <DocScrutinizer05> with the sole purpose to make proprietary drivers 'illegal'. Up to you to figure what's the motivation to do so
Jul 29 21:25:12 <antrik> also there is no such thing as "#include tricks". the question what does or does not constitute a derived work is not for licenses to decide, but for courts. it's a complex topic with a lot of grey area; but it's pretty clear from all I've read on the topic thus far that technical details such as use of include files have very little bearing on this matter
Jul 29 21:25:49 <DocScrutinizer05> and it's completely irrelevant if they implemented that by GPL_v3 or by some .h you must include so your module exports a certain symbol and you only may import that .h into FOSS code, or whatever. And I don't care
Jul 29 21:26:53 <DocScrutinizer05> I don't see how derived work comes in here
Jul 29 21:27:19 <antrik> DocScrutinizer05: sorry, you are just making things up. it is clear that the FSF doesn't like proprietary driver (or firmware blobs); that they are putting effort in somehow magically change the legality of such things is just bullshit
Jul 29 21:27:50 <DocScrutinizer05> ok
Jul 29 21:30:12 <antrik> derived work is the essential thing here, because that's precisely what decides what software is bound by GPL terms and what isn't
Jul 29 21:32:39 <DocScrutinizer05> ok, then back to square one: another example for FSF mindset: RYG. *Clearly* shows FSF approach to "closed hw"
Jul 29 21:32:59 <DocScrutinizer05> but honestly, I'm absolutely not interested in continuing this discussion
Jul 29 21:33:17 <DocScrutinizer05> I won't convice you and you definitely won't convince me
Jul 29 21:33:29 <DocScrutinizer05> so this is totally futile
Jul 29 21:34:09 <DocScrutinizer05> RYF that is
Jul 29 21:38:20 <DocScrutinizer05> if you really want to find out if maybe I'm right, check why a 15 years ago proprietary drivers were kernel modules while now they are userland libs with only a kernel stub driver
Jul 29 21:47:44 <DocScrutinizer05> I admit however that I can't tell for sure it's been FSF or associated folks that were pulling this stunt
Jul 29 21:56:57 <antrik> well, as I said, there is no doubt about the FSF's stance on proprietary drivers. it's just FUD claiming the FSF was actually taking action trying to affect the legality of drivers in Linux
Jul 29 21:58:54 <antrik> BTW, AIUI the nvidia driver still does non-trivial stuff in kernel space. and it's legality has been questionable from the start -- there are reasons why no major distributions ship the drivers on their install media
Jul 29 22:12:22 <DocScrutinizer05> http://linux.sys-con.com/node/38143 you quite possibly may be right it wasn't FSF. Back when I didn't know about FSF at all, I guess. I just seen "linux devels" and how trhey tried to tell hw manufs that providing closed kernel modules was illegal. And they were pretty clear about the motivations for that
Jul 29 22:14:31 <DocScrutinizer05> and I seem to recall pretty clearly that somebody invented a #include that had one single purpose only: make it impossible to build kernel drivers without it, and make closed kernel drivers with it illegal
Jul 29 22:15:37 <DocScrutinizer05> I stand corrected in that it was really just FUD to link the FSF to any of that
Jul 29 22:36:40 <antrik> interesting thread
Jul 29 22:36:48 <antrik> anyways, I'm glad we got this sorted :-)
Jul 29 22:37:11 <DocScrutinizer05> (#include) if such thing still exists, it's for the purpose to avoid legal debates about whether something written to only USE an ABI is really a derivative work form the *code* that implements that API.
Jul 29 22:37:21 <DocScrutinizer05> antrik: (sorted) indeed
Jul 29 22:37:57 <DocScrutinizer05> s/API/ABI/
Jul 29 22:38:20 <DocScrutinizer05> ~ping
Jul 29 22:38:21 <apt> 1 packet transmitted, 1 packet received, 0.0% packet loss
Jul 29 22:38:52 <DocScrutinizer05> s/API/ABI/
Jul 29 22:39:49 <DocScrutinizer05> ...or if an ABI by itself is protected by copyright
Jul 29 22:41:07 <antrik> interfaces are not protected by copyright AIUI; but apparently the general assumption is that if an interface is very "intimate", anything using it must be considered a derived work of the counterpart...
Jul 29 22:43:16 <DocScrutinizer05> (general assumption) it's even weirder, see >  first implement a driver/module in a non-Linux OS (this may even imply requiring that whoever works on the driver/module have NO Linux experience whatsoever; yes there will always be candidates for this) and then have this driver/module ported to Linux by Linux-aware developers.<< it seems it's enough you KNOW linux so you can't write ANY sw code that's not a derivative work ;-P
Jul 29 22:44:45 <DocScrutinizer05> probably many of those folks (incl Linus) were wrong regarding what the lawyers said about the whole subject later on
Jul 29 22:45:21 <DocScrutinizer05> thus...: invetion of that notorious #include
Jul 29 22:50:46 <DocScrutinizer05> IMHO this wasn't a smart move. Rather the linux (kernel) devels should have faith in real life necessities which would have taught hw devels that it's a poor idea to provide closed blob kernel drivers since they wouldn't be able to keep pace with updates for new kernels. Outright forbidding kernel module blobs forced hw devels to think about a short term alternative (userland libs plus "FOSS" kernel stub) which turned out to be 
Jul 29 22:50:47 <DocScrutinizer05> so confortable for the hw manufs that they don't see any more reason to consider providing any *real* FOSS drivers
Jul 29 22:54:02 <antrik> I don't there is an actual "infamous #include". AIUI the current situation is essentially a formalisation of the sentiments mentioned in this thread: interfaces that are considered "intimate" by the kernel developers are explicitly marked with a special symbol, and proprietary drivers using any of these symbols are generally considered derived works by the Linux developers
Jul 29 22:54:36 <antrik> there *have* been some people proposing that even trivial things are marked thus to disallow any proprietary modules, but these never have been taken seriously
Jul 29 22:56:41 <antrik> BTW, I tend to think the "written for something else and then ported" part of the discussion is misleading. what actually matters here is the notion of combined works
Jul 29 22:57:38 <antrik> if there is a substantial part of the driver that is not really tied to Linux and could be used in other contexts -- no matter how it came to be -- this part would generally not be considered a derived work on itself
Jul 29 22:58:12 <antrik> however, the *combination* of this part with the GPL code will typically still form a derived work
Jul 29 22:58:45 <antrik> which creates the weird situation that the driver can probably be distributed legally on it's own, but shipping it together with Linux is not OK...
Jul 29 23:00:31 <DocScrutinizer05> well, see >> Some claim that copyright law does not allow the GPL to do such a thing. That is incorrect. I can write a work and license it to you under _any_ terms I see fit. I can, for example, license it to you _only_ on condition that you agree to release _all_ your future copyrightable work, including works of fiction and other completely unrelated things, under terms I decree<< which is a fallacy since the copyright license 
Jul 29 23:00:32 <DocScrutinizer05> TOS only apply to anybody using linux, not to somebody providing a driver and thus not to the driver as well. So it might be illegal to *use* such a driver in linux, but you have no argument that allows forcing the author of that driver to FOSS it
Jul 29 23:02:38 <DocScrutinizer05> so yes, pretty much exactly what you said in your last line you posted :-)
Jul 29 23:03:08 <antrik> actually, I guy you cited is wrong on multiple points. for one, I don't think GPL tries to impose conditions beyond what constitutes a derived work -- at least not intentionally. on the other hand, the GPL explicitly does *not* require agreement, so the point that it could do this is simply wrong...
Jul 29 23:03:45 <DocScrutinizer05> :nod:
Jul 29 23:08:25 <DocScrutinizer05> good post in that thread, good point: >>If your module contains a similar percentage pollution from GPL code (which would probably equate to no more than the actual interface) and was written entirely without GPL tools, it would be hard to prove it to be other than an original work.<<
Jul 29 23:09:29 <DocScrutinizer05> >>The "fair use" dictates of copyright law (which has always allowed limited copying) would also support the idea that a module that had no more connection to GPL'd code than the standard interface to that code, would be an original work<<
Jul 29 23:11:46 <DocScrutinizer05> defeats the >>interfaces that are considered "intimate" by the kernel developers are explicitly marked with a special symbol, and proprietary drivers using any of these symbols are generally considered derived works<<
Jul 29 23:12:55 <DocScrutinizer05> and I guess it was this special symbol I recalled and referred to as "#include trick"
Jul 29 23:14:08 <DocScrutinizer05> anyway it didn't pan out as they hoped for, right?
Jul 29 23:16:41 <DocScrutinizer05> any hw manufacturer deciding to provide FOSS drivers nowadays does so by instruction of the merchants, after they did a very levelheaded calculation of the return of investment this might have for them
Jul 29 23:18:03 <DocScrutinizer05> in this regard the whole copyright thing as been the topic in this thrwad didn't really help to make that calculation more in favor of FOSS
Jul 29 23:21:08 <DocScrutinizer05> I guess more often than not all the additional income from true FOSS is getting eaten by the increased risk and the lawyers needed to manage that risk both preemptively and in disputed/trials
Jul 29 23:21:42 <DocScrutinizer05> disputes*
Jul 29 23:24:34 <DocScrutinizer05> comapnies might be *forced* to disclose company assets in algorithms they use for e.g. GFX acceleration, when they would publish the rest of their driver as FOSS
Jul 29 23:26:15 <DocScrutinizer05> those companies might not even have patented such algos, just because they had to disclose them for the patent letter. And thus other companies would have access to that knowledge
Jul 29 23:27:42 <DocScrutinizer05> they would never risk to get into a situation where their competitors could force them to disclose that secret code, by using GPL as a lever
Jul 29 23:28:52 <DocScrutinizer05> so from the FOSS community POV this was a clear own goal
Jul 30 00:11:30 <antrik> DocScrutinizer05: actually, I'm pretty sure such decisions are almost never based on actual calculations, but rather on vague irrational feelings of "this is ours and we don't want to share it"
Jul 30 00:12:09 <DocScrutinizer05> I guess that depends on size and professionality of the company
Jul 30 00:14:04 <DocScrutinizer05> though, looking at Nokia and Elopcalypse, I tend to think you might be right, unconditionally. Every bullshit gets done, without asking, when THE BOSS asks for it
Jul 30 00:15:13 <antrik> BTW, it's a myth that using free software licenses increases legal uncertainity. free software license management isn't any more complicated than proprietary license managemnt; it's just that many companies in the past thought they can just ignore it and were caught off guard when it turned out they can't
Jul 30 00:16:41 <DocScrutinizer05> then otoh I know for relatively sure that Maemo division of Nokia would have loved to FOSS all the closed parts in Maemo (Apps mostly), if only the merchants had allowed for the budget needed for the lawyers to approve that it's OK to do so
Jul 30 00:18:14 <antrik> I don't think there are many cases of drives actually containing valuable trade secrets. from what I heard vendors are more afraid of exposing that they might be violating their competitors' patents etc...
Jul 30 00:18:57 <antrik> for graphics drivers, it's also the "optimisations" they do for specific titles, i.e. benchmark cheating
Jul 30 00:52:05 <DocScrutinizer05> sure
Jul 30 00:52:51 <DocScrutinizer05> whatever it is they want to hide resp keep secret... FOSS isn't really compatible with it
Jul 30 01:04:12 <antrik> well, nobody really demands that vendors expose the code of their encumbered drivers; but there is enough precedent showing that it's perfectly possibly to create fully functional drivers clean of anything incriminating...
Jul 30 01:06:55 <DocScrutinizer05> sure, but again this is a cost/ROI calculation
Jul 30 01:07:30 <DocScrutinizer05> unless some boss has an emotional idea
Jul 30 01:08:03 <DocScrutinizer05> quite usually this means you almost write the complete stuff anew
Jul 30 01:08:57 <DocScrutinizer05> *sane* management sets up project requirement guidelines that demand FOSS-compliant code even when it's not yet planned to FOSS the code
Jul 30 01:09:44 <DocScrutinizer05> but that is very rarely seen in industry
Jul 30 01:10:16 <DocScrutinizer05> way more often you see companies even using pirated/cracked tools
Jul 30 01:12:56 <DocScrutinizer05> or sticking to windows XP in times where win7 is getting old, due to the fact they wroze their own tools which are not easy to port to a new OS
Jul 30 01:13:22 <DocScrutinizer05> wrote*
**** ENDING LOGGING AT Sat Jul 30 02:59:58 2016