>
> My original point was that a restriction preventing (effectively) ports to
> proprietary operating systems probably wouldn't be considered problematic
> today. And why should it be?
>
I would object to such a license on the grounds of OSD #9 and #10.
__
* Bruce Perens:
> Hi Florian,
>
> Thank you for reinforcing the difference between commercial and
> proprietary, I was being lazy.
Red Hat has pretty much always shipped OpenMotif in Red Hat Enterprise
Linux, by the way.
I don't (and wouldn't) know of any separate contractual requirements
in thi
Hi Florian,
Thank you for reinforcing the difference between commercial and
proprietary, I was being lazy.
To this day it is difficult to actually install a pure Open Source Linux on
a laptop, due to the need for proprietary firmware and some driver issues -
especially concerning 3D graphics. So,
* Lawrence Rosen:
> So, if our community can come up with an adequate definition of
> "corresponding source" (or "intimacy") in the open source software context
> to enforce the intent of our network services copyleft licenses, I'm all
> ears. Neither SSPL nor AGPL currently meet that clarity requ
Having a process editor is seen as a filter for volume and looped
continuation of unresolving disputes. This is why courts have judges, isn't
it? Selecting a person who does not have a stake in the outcome and
understands the issues well enough to represent them would be a good idea.
Legal professi
* Bruce Perens:
> Both Red Hat and Debian treat the terms of the distribution the same as
> what they ask for in the software. When I last checked, Red Hat was using
> the GPL Version 2 as a compilation license. Both wanted commercial
> derivatives (Red Hat for their own use). So, this sort of res
On Tue, Mar 19, 2019 at 7:33 AM Pamela Chestek
wrote:
>
> On 3/18/2019 9:21 PM, John Sullivan wrote:
> > Bruce Perens writes:
> >
> >> 2. Use PEP. This appears to be an RFC-like process, and I am not yet
> clear
> >> how it avoids the complaint about the present process, which is that
> >> discu
Quoting Thorsten Glaser (t...@mirbsd.de):
[GPLv2 Discourse codebase:]
> I’ve not looked at it, but many “open core” are not Free Software:
> they often reject patches that add features because they would
> reduce the “added value” of the commercial version, and some even
> strip comments or, wors
On Tue, Mar 19, 2019 at 3:55 PM Bruce Perens wrote:
> We should keep this in mind as we consider processes like PEP. They are
> designed to create consensus, and their subject has mainly been technical
> issues where consensus is easier to form. Just how will they handle a
> failure to achieve co
One of the largest problems in getting the patent policy done at W3C was
that W3C had always been able to develop consensus on any decision, *until
then. *The patent policy, which allowed the continuation of Open Source
implementations of web servers and browsers, developed no consensus, and
one me
On Tue, Mar 19, 2019 at 9:30 AM VanL wrote:
>
> The second part is an ongoing record of comments made and responses.
> Usually, accepted suggestions are incorporated into the proposal; rejected
> suggestions are documented with a rationale. That is what is happening with
> the CAL. Accepted sugge
Rick Moen dixit:
>misadventure, etc., is inapt. Discourse the codebase _is_ a
>free-software tool.
I’ve not looked at it, but many “open core” are not Free Software:
they often reject patches that add features because they would
reduce the “added value” of the commercial version, and some even
s
Quoting Thorsten Glaser (t...@mirbsd.de):
> Rick Moen dixit:
>
> >I appreciate your speaking, Kevin. I continue to be curious about
> >whether users would be expected to enter a contractual relationship with
> [ any third party ]
> >in order to participate.
>
> +1
>
> This is something that oc
Rick Moen dixit:
>I appreciate your speaking, Kevin. I continue to be curious about
>whether users would be expected to enter a contractual relationship with
[ any third party ]
>in order to participate.
+1
This is something that occurs more and more, but a bad thing.
See also: http://mako.cc/w
Quoting Kevin P. Fleming (kevin+...@km6g.us):
> I have quite a bit of experience in this area and can state that none
> of this would be necessary (and some are not even options). CDCK does
> not request or hold rights to any content on the Discourse sites they
> host. I have no doubt they would h
Regarding PEPs, the process relative to the CAL is not too far off from a
PEP-like process. Each PEP has one or more authors and champions - in this
case me. The PEP itself is essentially a long-form summary of the proposal,
subsequent discussion and decisions, and
Ordinarily, there are three main
On Tue, Mar 19, 2019 at 10:47 AM VanL wrote:
On Mon, Mar 18, 2019 at 12:47 PM Henrik Ingo
> wrote:
>
>>
>>
> This is not at all the case. Say you received this software, and use it to
>> keep a log of correspondence you've had with me. YOUR log is now MY
>> personal data/user data, and under GDP
[Initially replied just to Henrik; resending to whole list. Thanks,
Henrik, for catching that!]
On Mon, Mar 18, 2019 at 12:47 PM Henrik Ingo
wrote:
>
> - Protection of User Data
>> The protection of User Data portion is a limitation on the grant to the
>> licensee, not a grant of rights to a th
On 3/18/2019 9:21 PM, John Sullivan wrote:
> Bruce Perens writes:
>
>> 2. Use PEP. This appears to be an RFC-like process, and I am not yet clear
>> how it avoids the complaint about the present process, which is that
>> discussion of the proposal on a mailing list seems to be un-trackable or
>>
On Tue, Mar 19, 2019 at 4:32 AM Rick Moen wrote:
> What I didn't go on to say at the time (as it was out of scope for that
> topic), but am glad to say now, is that certainly mailing lists (and
> newsgroups) have damning deficiencies for organising and tracking issues.
> They're also pretty dread
On Tue, Mar 19, 2019 at 6:29 AM Rick Moen wrote:
> For clarification, are you talking about an arrangement where users
> would be required to enter a contractual relationship with Civilized
> Discourse Construction Kit, Inc. (CDCK aka 'discourse.org'), in order to
> participate in a Discourse for
Quoting Luis Villa (l...@lu.is):
> I obviously agree that using simple tools is better, and barriers to
> entry must be kept reasonably low, but email is deceptively simple. It
> provides lots of ways to create vast morasses of email ("it is simple
> - just hit send!") , and no ways to turn vast m
22 matches
Mail list logo
