On Saturday, 26 September 2015 at 10:02:46 UTC, Jacob Carlborg wrote:
> On 2015-09-26 05:08, Manu via Digitalmars-d wrote:
>
>> Windows is just a terrible operating system and I wish it would die
>> already, but OSS just can't get a reasonable Microsoft Office,
>> Photoshop, or Visual Studio alternative together. I don't even care if
>> it's free, I'd pay good money for a linux version of each of these
>> programs, they just have to exist.
>
> Photoshop and Microsoft Office are available on OS X. Visual Studio Code is also available on OS X, although not the same as the regular Visual Studio, I have no experience how they compare.

I tried visual studio code and it sucks - it is nothing but a text editor, a notepad with syntax highlighting like sublime only much worse ;)

--Stephan

On Saturday, 26 September 2015 at 19:22:16 UTC, Laeeth Isharc wrote:
> On Saturday, 26 September 2015 at 14:31:15 UTC, Artur Skawina wrote:
>
>> Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed.
> ...>
>> Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there.
>
>
> out of curiosity, what is your concern?  as I understand it you can produce derived works but the restriction is on redistribution of the compiler, and if you care about that you ask Walter and he says yes.

Those who have had to deal with copyright lawyers become paranoid: ;)

http://forum.dlang.org/post/mailman.2659.1403347797.2907.digitalmars-d@puremagic.com
http://forum.dlang.org/post/dmfr07$2u3u$1@digitaldaemon.com
http://forum.dlang.org/post/euuvum$171f$1@digitalmars.com

On 9/26/2015 7:24 AM, Artur Skawina via Digitalmars-d wrote:
> Given the DMD licensing situation, nobody will (or should) even look
> inside the DMD repo for info. Especially that "backend" string is
> really scary. I decided to blindly trust your words above, and, with
> trembling hands, somehow managed to click that link. Phew. That file
> really appears to be boost licensed.

Even if cv8.c was locked up tight with licensing, the CV8 file format itself would not be covered by such license. CV8 is not a Digital Mars file format, it's a Microsoft format.

Now, if Microsoft decided to assert some sort of IP control over the CV8 format in order to prevent LLVM from generating CV8 format, whether I implemented CV8 in LLVM or the LLVM did would make no difference. I have no authority over Microsoft licensing issues and don't speak for Microsoft on them.

On 9/26/2015 8:04 AM, David Nadlinger wrote:
> On Saturday, 26 September 2015 at 15:01:06 UTC, Iain Buclaw wrote:
>> For the time being this is enough.  As for common codebase, we are in a state
>> of divulging further apart for the first time in a while, […]
>
> I think it's quite the contrary for LDC. We are releasing a 2.067-based version
> soon, just started testing the 2.068.2 merge, and will hopefully have a
> DDMD-based version by late October.

Pretty dazz!

On Saturday, 26 September 2015 at 20:09:54 UTC, Joakim wrote:
> On Saturday, 26 September 2015 at 19:22:16 UTC, Laeeth Isharc wrote:
>> On Saturday, 26 September 2015 at 14:31:15 UTC, Artur Skawina wrote:
>>
>>> Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed.
>> ...>
>>> Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there.
>>
>>
>> out of curiosity, what is your concern?  as I understand it you can produce derived works but the restriction is on redistribution of the compiler, and if you care about that you ask Walter and he says yes.
>
> Those who have had to deal with copyright lawyers become paranoid: ;)
>
> http://forum.dlang.org/post/mailman.2659.1403347797.2907.digitalmars-d@puremagic.com
> http://forum.dlang.org/post/dmfr07$2u3u$1@digitaldaemon.com
> http://forum.dlang.org/post/euuvum$171f$1@digitalmars.com

well, okay, but the posts from Walter you link to are from more then eight years ago, and he spoke about how he was beginning to open source parts of Phobos (when D's status was rather different).

anything is possible.  but so long as Walter is with us and in control of Digital Mars, I really don't see that it is possible for Digital Mars to sue someone who has looked at the code, been inspired by it, and done something short of straight ripping it off wholesale.  because there's much more at stake with D, and it wouldn't make any sense.  it's not a company with the resources let alone interest to play games with trivial lawsuits, is my guess.

the contract nitty gritty only practically comes into play in the unpleasant scenario that Walter should not be in control of Digital Mars at some point in some decades, and I trust he has made provision for that.  (Walter?)

Artur makes a very strong statement that doesn't make any sense to me (and I have certainly had at least my share of silly games with contracts):

> Given the DMD licensing situation, __nobody__ will (or should) even look inside the DMD repo for info. Especially that

He's entitled to his view, but normally one is taken more seriously if one makes a reasoned argument for a strong view (which he declined to do in that previous thread).  Prudence is a virtue, but it's not quite the same thing as blanket aversion to all possible risks - each must judge for himself, but advising others like this goes quite far.

On 09/26/15 23:58, Laeeth Isharc via Digitalmars-d wrote:

>> Given the DMD licensing situation, __nobody__ will (or should) even look inside the DMD repo for info. Especially that

Note that the above is not what I actually wrote, but has been altered
with no mention of this fact.
It's hard enough to convey tone via email; such manipulations don't help.


> He's entitled to his view, but normally one is taken more seriously if one makes a reasoned argument for a strong view (which he declined to do in that previous thread).  Prudence is a virtue, but it's not quite the same thing as blanket aversion to all possible risks - each must judge for himself, but advising others like this goes quite far.

It's not advice, but a statement of fact. Well, the `(or should)` part /is/, but it was parenthesized for a reason - it's not the main point, but only a preemptive response to any potential "but they should" reply.

Obviously, "nobody" in this context does not literally mean "nobody",
but nobody from the set of people with an interest in the subject that
might potentially create open source or otherwise differently licensed
works. The latter subset can in theory be the same as the whole set
(it will be smaller in practice, yes). Considering that this discussion
is about an apparently undocumented file format that Manu would like to
see supported in a differently licensed work (LLVM) and thinks that
Walter and/or DMD is a good, or even unique, source for info about, then
yes -- _nobody_ (that would like to use the information to indirectly
incorporate in into LLVM) will look for it inside some other proprietary
compiler. At least, they are _not_supposed_to_, and really shouldn't.
Even without malicious intent it's too easy for the result to be
similar enough that somebody can claim it's a derivative work. And even
when such a claim is obviously bogus, you do not want to have to deal
with it.
Hence, as it appears that the code in question is boost licensed,
(re-)publishing it in a way that would limit the "contamination"
concerns might help Manu's cause, and does not require Walter do much
more than a git clone+add+commit+push. Convincing a LLVM developer
to support a file format that's documented in a single boost licensed
file is going to be much easier than suggesting that they obtain the
info from a non-free non-redistributable compiler source from another
vendor. And by "much easier" I mean "possible", because the other option
simply isn't (and shouldn't).

Now, I don't know if the info in that file really is as unique as Manu
says, plus because of this thread it already became much more accessible,
so it's possible that the issue has been already solved. But every
other `free-but-entangled-with-non-free` part of DMD has the same problem.

"Let's look inside works we can't legally use, just in case there's some usable part inside" is not a viable option. Really.

artur

On Saturday, 26 September 2015 at 23:48:05 UTC, Artur Skawina wrote:
> On 09/26/15 23:58, Laeeth Isharc via Digitalmars-d wrote:
>
>>> Given the DMD licensing situation, __nobody__ will (or should) even look inside the DMD repo for info. Especially that
>
> Note that the above is not what I actually wrote, but has been altered > with no mention of this fact.
> It's hard enough to convey tone via email; such manipulations don't help.


I added __ __ around nobody to make it clear what I was referring to.  Do you have a better idea about how to economically highlight things when using a newsgroup interface?  It would have been appropriate to mention my emphasis, and mea culpa for that.

But when you say altered it suggests deliberate misrepresentation in a way that fundamentally mischaracterises what you wrote, and I don't believe this is the case.  I merely highlighted it, and I acknowledge that this might be misunderstood by somebody reading in a hurry.

>> He's entitled to his view, but normally one is taken more seriously if one makes a reasoned argument for a strong view (which he declined to do in that previous thread).  Prudence is a virtue, but it's not quite the same thing as blanket aversion to all possible risks - each must judge for himself, but advising others like this goes quite far.
>
> It's not advice, but a statement of fact. Well, the `(or should)` part /is/, but it was parenthesized for a reason - it's not the main point, but only a preemptive response to any potential "but they should" reply.

Well, okay, I see where you are coming from.  But there's enough of this idea already that dmd isn't "free" in a way that seriously matters and that reflects a spirit that wouldn't like it to be free if commercial things were different that perhaps you can see why what you wrote might also be taken a certain way in this context.

Words have power, and it's easy to forget that when writing from a personal perspective.  (We're all part of the problem in 2015, me too).

> Obviously, "nobody" in this context does not literally mean "nobody", > but nobody from the set of people with an interest in the subject that might potentially create open source or otherwise differently licensed works. The latter subset can in theory be the same as the whole set (it will be smaller in practice, yes).

> "Obviously in this context does not literally mean "nobody",
                ^^^^^^^^^^^^^^^^
Yes, well, context isn't always very clear in this medium, and neither is what's obvious.  That's a very big set!  I would have thought the set of people practically speaking is those that work on open-source or closed-source compiler backends.  That's much smaller than implied by what you wrote.  Also, the set of people with an interest in things vastly exceeds the number who do any work in the area.

> Considering that this discussion
> is about an apparently undocumented file format that Manu would like to see supported in a differently licensed work (LLVM) and thinks that Walter and/or DMD is a good, or even unique, source for info about, then > yes -- _nobody_ (that would like to use the information to indirectly > incorporate in into LLVM) will look for it inside some other proprietary > compiler. At least, they are _not_supposed_to_, and really shouldn't.  Even without malicious intent it's too easy for the result to be
> similar enough that somebody can claim it's a derivative work.

I see your point that given the need for not just propriety, but the appearance of it then if someone were an LLVM contributor or serious potential contributor it would be best to do as Manu suggested and ask Walter than just look at the source without knowing its status.  I guess it's not so applicable, but you couldn't have known that before looking.  But then, if one's concern is primarily about legal risks, then announcing one is looking at code and making a big deal about one's concerns is hardly prudent either as a general strategy.  (And if it's an internal ethical concern that's between you and whatever you do or don't believe in).

> Hence, as it appears that the code in question is boost  licensed,
> (re-)publishing it in a way that would limit the "contamination"
> concerns might help Manu's cause, and does not require Walter do much more than a git clone+add+commit+push. Convincing a LLVM developer to support a file format that's documented in a single boost licensed file is going to be much easier than suggesting that they obtain the info from a non-free non-redistributable compiler source from another vendor. And by "much easier" I mean "possible", because the other option simply isn't (and shouldn't).

As I understand it, it's redistributable if you just ask nicely and promise not to sue the various people involved.  My reading of what Walter has said on Reddit is that you could base a commercial compiler on dmd and sell it and he would be fine with that.  But perhaps that's not a license to allow others to redistribute, so maybe that causes problems with LLVM.

> every
> other `free-but-entangled-with-non-free` part of DMD has the same problem.

Enough controversy for me for a while, so let's leave it at that.  I presume you're an LLVM contributor, and so I can see that you may have special constraints.




Laeeth.

On Saturday, 26 September 2015 at 23:48:05 UTC, Artur Skawina wrote:
> "Let's look inside works we can't legally use, just in case there's some usable part inside" is not a viable option. Really.

You have one team take a look at it to help them document the file format, then a separate team use that file format documentation to write an alternate implementation.

Then it is aiding in reverse engineering the file format instead of creating a derivative work of the implementation, as long as the two teams don't communicate outside that file format spec doc.

On 9/26/2015 10:20 AM, Brad Anderson wrote:
> Just a little aside tip, Windows search these days is actually really excellent
> for settings like this (and programs). Windows Key + "env" + Enter is enough to
> get you to the dialog.

Sorry, but the env dialog box is a sad joke, at least on Windows 7.

1. You cannot select any of the text in the dialog.
2. You cannot increase the size of the dialog.
3. Longer values end in "...".
4. You cannot edit so-called "System" environment variables.
5. You can scroll the list up or down, but not sideways!

That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic.

Back to the command line for me.

On Sunday, 27 September 2015 at 06:34:29 UTC, Walter Bright wrote:
> On 9/26/2015 10:20 AM, Brad Anderson wrote:
>> Just a little aside tip, Windows search these days is actually really excellent
>> for settings like this (and programs). Windows Key + "env" + Enter is enough to
>> get you to the dialog.
>
> Sorry, but the env dialog box is a sad joke, at least on Windows 7.
>
> 1. You cannot select any of the text in the dialog.
> 2. You cannot increase the size of the dialog.
> 3. Longer values end in "...".
> 4. You cannot edit so-called "System" environment variables.
> 5. You can scroll the list up or down, but not sideways!
>
> That all conspires to ensure that you CANNOT SEE what the longer values even are! It's pathetic.
>
> Back to the command line for me.

I think that the only aspect of it which has changed since Windows 95 is the window style. Whenever I have to edit PATH, I copy it out of their horrible edit box, edit it in something like vim, and then copy it back. Honestly, MS should be embarrassed by the state of the env dialog box.

- Jonathan M Davis