www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Documentation license and DMD redistribution

reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter: I know this has been asked as lot, but
just what is the license on the D specification ?

That is, the files in dmd.zip available under:
dmd/html/d/* (total: 62 HTML files, 15 images)

As I understand it, at the moment it is just a
dump of the http://www.digitalmars.com/d/ site ?


If those are under a re-distributable license,
like dmd/src/dmd/* and dmd/src/phobos/* are now,
then the DMD sources/docs can be re-distributed -
after first stripping out the various X86 binaries...

If they're not, then the dmd/html directory also
needs to be stripped out of any re-distribution -
just like : dm/bin, dm/lib, dmd/bin, and dmd/lib
already have to be. (DMD, non-distributable license)


It would also make it more clear on how to treat
derivate documentation works, such as all comments
on the Wiki4D - which are released under the GNU FDL.
(see http://www.gnu.org/copyleft/fdl.html for license)

For instance, I have a local doc version which I
converted into XHTML - with a nice CSS stylesheet,
and one version that has been converted into a PDF,
but I am not really sure if I can re-distribute them ?
So now I just keep them to myself instead, sorry. :-(

(here are all markup errors found in the current
version: http://www.algonet.se/~afb/d/errors.txt)


It would be GREAT if the D docs could be open too!
(currently GDC ships *without* any D documentation)

The simplest would probably be to make this also
into a Dual License, just like the DMD front-end ?
GPL => FDL, not sure what is like the "Artistic";
maybe http://creativecommons.org/licenses/by/2.0/ ?


I think this too needs to be cleared up before D 1.0...
(as well as the few remaining license woes with Phobos)
--anders


PS.
Is Digital Marsâ„¢ a trademark of Walter Bright, or
does it belong to Digital Mars, Inc. or something ?
Apr 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d2n9vr$18ii$1 digitaldaemon.com...

 Walter: I know this has been asked as lot, but
 just what is the license on the D specification ?


It's just plain old copyrighted.


 That is, the files in dmd.zip available under:
 dmd/html/d/* (total: 62 HTML files, 15 images)

 As I understand it, at the moment it is just a
 dump of the http://www.digitalmars.com/d/ site ?


That's right.


 If those are under a re-distributable license,
 like dmd/src/dmd/* and dmd/src/phobos/* are now,
 then the DMD sources/docs can be re-distributed -
 after first stripping out the various X86 binaries...

 If they're not, then the dmd/html directory also
 needs to be stripped out of any re-distribution -
 just like : dm/bin, dm/lib, dmd/bin, and dmd/lib
 already have to be. (DMD, non-distributable license)


For the time being, the docs are not redistributable. The reason is I want
to keep them from getting too fragmented.


 It would also make it more clear on how to treat
 derivate documentation works, such as all comments
 on the Wiki4D - which are released under the GNU FDL.
 (see http://www.gnu.org/copyleft/fdl.html for license)

 For instance, I have a local doc version which I
 converted into XHTML - with a nice CSS stylesheet,
 and one version that has been converted into a PDF,
 but I am not really sure if I can re-distribute them ?
 So now I just keep them to myself instead, sorry. :-(

 (here are all markup errors found in the current
 version: http://www.algonet.se/~afb/d/errors.txt)


 It would be GREAT if the D docs could be open too!
 (currently GDC ships *without* any D documentation)


The documentation is just a click away.


 The simplest would probably be to make this also
 into a Dual License, just like the DMD front-end ?
 GPL => FDL, not sure what is like the "Artistic";
 maybe http://creativecommons.org/licenses/by/2.0/ ?


 I think this too needs to be cleared up before D 1.0...
 (as well as the few remaining license woes with Phobos)


I thought the licensing issues with Phobos were cleared up?


 --anders


 PS.
 Is Digital MarsT a trademark of Walter Bright, or
 does it belong to Digital Mars, Inc. or something ?


Of Digital Mars.
Apr 03 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 For the time being, the docs are not redistributable.
 The reason is I want to keep them from getting too fragmented.


That's a valid reason. And beyond D 1.0: when we get there ?
(it could be just me being paranoid and premature here, too)

Thanks for answering so quickly, I'll email the XHTML as a zip.


It would be GREAT if the D docs could be open too!
(currently GDC ships *without* any D documentation)


 
 The documentation is just a click away.


Not that it'll happen to D and Digital Mars, but *other*
projects have had such online references "torn away"...

Especially without a free/open license, and redistribution.


I think this too needs to be cleared up before D 1.0...
(as well as the few remaining license woes with Phobos)


 
 I thought the licensing issues with Phobos were cleared up?


Almost, just a few minor details left (see other thread)...

But again - thanks for taking the time to add "phoboslicense.txt"
And a simple way to "fix" recls is to use the standalone version ?

--anders
Apr 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d2ofls$27nh$1 digitaldaemon.com...

 Walter wrote:

It would be GREAT if the D docs could be open too!
(currently GDC ships *without* any D documentation)


 The documentation is just a click away.


 Not that it'll happen to D and Digital Mars, but *other*
 projects have had such online references "torn away"...
 Especially without a free/open license, and redistribution.


I can't imagine why I'd want to do that, but I accept that it can be
worrisome from another's perspective. Probably the worst thing I'd do is
serve some modest ads on it.


I think this too needs to be cleared up before D 1.0...
(as well as the few remaining license woes with Phobos)


 I thought the licensing issues with Phobos were cleared up?


 Almost, just a few minor details left (see other thread)...


Thanks.


 But again - thanks for taking the time to add "phoboslicense.txt"


Yeah, that needed to be done.


 And a simple way to "fix" recls is to use the standalone version ?


For the moment, yes. I've been reluctant to upgrade it because the newer
versions are so large. Matthew has promised a smaller version in the future.
Apr 03 2005
next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:d2q3c0$igp$1 digitaldaemon.com...

 "Anders F Björklund" <afb algonet.se> wrote in message
 news:d2ofls$27nh$1 digitaldaemon.com...

 Walter wrote:

It would be GREAT if the D docs could be open too!
(currently GDC ships *without* any D documentation)


 The documentation is just a click away.


 Not that it'll happen to D and Digital Mars, but *other*
 projects have had such online references "torn away"...
 Especially without a free/open license, and redistribution.


 I can't imagine why I'd want to do that, but I accept that it can be
 worrisome from another's perspective. Probably the worst thing I'd do is
 serve some modest ads on it.


I think this too needs to be cleared up before D 1.0...
(as well as the few remaining license woes with Phobos)


 I thought the licensing issues with Phobos were cleared up?


 Almost, just a few minor details left (see other thread)...


 Thanks.


 But again - thanks for taking the time to add "phoboslicense.txt"


 Yeah, that needed to be done.


 And a simple way to "fix" recls is to use the standalone version ?


 For the moment, yes. I've been reluctant to upgrade it because the newer
 versions are so large. Matthew has promised a smaller version in the future.


Version 1.6 is significantly trimmed, and the effort in making it so was for no
other reason than meeting the agreement 
to trim it for Phobos.

Although recls 2 will likely be significantly smaller, it's at least 3/4 months
away. (Again, this was discussed with 
you when we agreed that 1.6 would the small-enough version for Phobos.)
Apr 03 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


And a simple way to "fix" recls is to use the standalone version ?


For the moment, yes. I've been reluctant to upgrade it because the newer
versions are so large. Matthew has promised a smaller version in the future.


 
 Version 1.6 is significantly trimmed, and the effort in making it so was
 for no other reason than meeting the agreement to trim it for Phobos.


I even managed to get it to compile, after a while of trying... :-)

Downloaded:
1.9M    http://synesis.com.au/downloads/recls/recls-1.6.1.zip
1.1M    http://synesis.com.au/downloads/stlsoft/stlsoft-1.8.3-beta4.zip

Issued:
unzip -d recls-1.6.1 -q recls-1.6.1.zip
unzip -d stlsoft-1.8.3 -q stlsoft-1.8.3-beta4.zip

make -f makefile.unix -s \
   -C recls-1.6.1/build/gcc33 \
   PROJ_BASE_DIR="$PWD/recls-1.6.1" \
   STLSOFT_INCLUDE="$PWD/stlsoft-1.8.3"

Built:
252K    recls-1.6.1/lib/recls.gcc33.a
344K    recls-1.6.1/lib/recls.gcc33.debug.a

With:
gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
Copyright (C) 2003 Free Software Foundation, Inc.


But I could find any installation instructions, nor any packages ? :-(

I assume it's the Java way: copy anywhere, and mess with the ENV...
(So choosing /usr/include/stlsoft and /usr/include/recls could work)

Suppose it's just time for me to slap together a few RPM specfiles ?
(with a stlsoft-config and a recls-config script, to give the paths)

Funny how the recls library download is as big as the DMD compiler.

--anders
Apr 04 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d2quh2$1e6j$1 digitaldaemon.com...

 Built:
 252K    recls-1.6.1/lib/recls.gcc33.a
 344K    recls-1.6.1/lib/recls.gcc33.debug.a


The recls currently shipping with dmd is:

25K    librecls.a on linux
37K    recls.lib on Win32
Apr 04 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


Built:
252K    recls-1.6.1/lib/recls.gcc33.a
344K    recls-1.6.1/lib/recls.gcc33.debug.a


 
 The recls currently shipping with dmd is:
 25K    librecls.a on linux
 37K    recls.lib on Win32


Note that it had all -g debug symbols left in,
before drawing any conclusions regarding recls.

I still think it should be an external library,
but not primarily because of the code size...


As I understood it, recls 1.6.1 was a stripped
down version - especially for D. And that the
main new additions would go in recls 2.0 instead ?
But Matthew Wilson would know all about that...

Also, recls 1.6.1 requires the latest beta of STLSoft
(i.e. 1.8.3 beta 3 or above). The stable lib won't do.

--anders
Apr 04 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d2rf87$218u$1 digitaldaemon.com...

 Walter wrote:


Built:
252K    recls-1.6.1/lib/recls.gcc33.a
344K    recls-1.6.1/lib/recls.gcc33.debug.a


 The recls currently shipping with dmd is:
 25K    librecls.a on linux
 37K    recls.lib on Win32


 Note that it had all -g debug symbols left in,
 before drawing any conclusions regarding recls.


:-)


 I still think it should be an external library,
 but not primarily because of the code size...


[Do the following two paras make the point of why? If so, it's not clear. Can
you rephrase/elucidate?]


 As I understood it, recls 1.6.1 was a stripped
 down version - especially for D.


Correct


 And that the
 main new additions would go in recls 2.0 instead ?


recls 2 will be huge change because it'll
    - do things more betterer, as a result of things learned in recls 1.x
    - it'll have plenty of new features, including more powerful behaviour and
a wider variety of searchable things 
(over and above just filesystem and FTP hosts)
    - it'll likely be largely written in C or 'tight' C++

But:
    - it'll be 2-3 months away. But because (AFAICT) that's still before 1.0 is
released - at least I hope so! - I 
really don't see a problem with going with updating Phobos with recls 1.x right
now. To not do so seems to arbitrarily 
single out recls for a fault (size) when the rest of Phobos is so embarassingly
crappy (and I don't just mean the 
features that I wrote).


 But Matthew Wilson would know all about that...

 Also, recls 1.6.1 requires the latest beta of STLSoft
 (i.e. 1.8.3 beta 3 or above). The stable lib won't do.


What's your point here?
Apr 04 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


I still think it should be an external library,
but not primarily because of the code size...


 
 [Do the following two paras make the point of why?
 If so, it's not clear. Can you rephrase/elucidate?]


I meant that: if recls should be in or out is a
different discussion, a few hundred KB of library
code that is usually dead-stripped if not actually
used is not really the reason for that discussion ?

And if size really matters, it should be accurately
measured and not just from hearsay on some newsgroup ;-)


     - it'll be 2-3 months away. But because (AFAICT) that's still before 1.0
is released - at least I hope so! - I 
 really don't see a problem with going with updating Phobos with recls 1.x
right now. To not do so seems to arbitrarily 
 single out recls for a fault (size) when the rest of Phobos is so
embarassingly crappy (and I don't just mean the 
 features that I wrote).


Yes, if etc.c.recls stays in the main download,
it should be updated to version 1.6.1 / 1.8.3...

Q: Why does the C/C++ library need to be in the
DMD download ? Wouldn't just std.recls be enough ?

And then link with the recls library, when linking.
That's how I usually use external libraries, with D.


Also, recls 1.6.1 requires the latest beta of STLSoft
(i.e. 1.8.3 beta 3 or above). The stable lib won't do.


 
 What's your point here?


That recls seems to still be in beta, since requirements are ?
(but that whole paragraph somehow came out wrong, as I just
meant to say that a new STLSoft is required to compile recls...)

But, when I ran the new "1.8.3-beta5" unittest - it failed ?
I think I will take it to the c++.stlsoft newsgroup instead...
On the plus side, I did make some SRPMS for them - if you like.

--anders
Apr 04 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:d2sa6u$506$1 digitaldaemon.com...

 Matthew wrote:


I still think it should be an external library,
but not primarily because of the code size...


 [Do the following two paras make the point of why?
 If so, it's not clear. Can you rephrase/elucidate?]


 I meant that: if recls should be in or out is a
 different discussion, a few hundred KB of library
 code that is usually dead-stripped if not actually
 used is not really the reason for that discussion ?


Gotcha


 And if size really matters, it should be accurately
 measured and not just from hearsay on some newsgroup ;-)


Indeed! (FYI: I've been doing that as part of the prep for the
July Positive Integration, and am coming to some very
interesting, and occasionally, startling results. Of which more,
later, when I'm fully armed with objective
information.)


     - it'll be 2-3 months away. But because (AFAICT) that's still before 1.0
is released - at least I hope so! - I
 really don't see a problem with going with updating Phobos with recls 1.x
right now. To not do so seems to
 arbitrarily single out recls for a fault (size) when the rest of Phobos is so
embarassingly crappy (and I don't just
 mean the features that I wrote).


 Yes, if etc.c.recls stays in the main download,
 it should be updated to version 1.6.1 / 1.8.3...


No argument here.


 Q: Why does the C/C++ library need to be in the
 DMD download ? Wouldn't just std.recls be enough ?

 And then link with the recls library, when linking.
 That's how I usually use external libraries, with D.


I get you.

For: reduced download
Against: need to specify the library in link: trivial; need to
acquire or compile the recls libs.

I'm planning to start having binaries - .libs and also
Python/Ruby .so/.dll - in the recls distro sometime in the
non-too-distant future, which'd help. But my guess is that
we'd want to have an RPM for the Linux, and I have _no idea_
how to do that. Would you help with that?

I still feel that, because I expect recls 2.0 to be *really* small
_and_ to be out before Phobos 1.0, recls 1.6 should
just go in as is. So what if it's a bit big now, given that
the issue is recognised and will be dealt with?

To be honest, the lack of recognition of the obviousness of the
preceeding statement is somewhat annoying. As with all
other contributors, I don't get paid for the time I spend working
on recls (recls/D), and playing to moving goalposts on
a module for a library so otherwise unready is kind of rich.


Also, recls 1.6.1 requires the latest beta of STLSoft
(i.e. 1.8.3 beta 3 or above). The stable lib won't do.


 What's your point here?


 That recls seems to still be in beta, since requirements are ?


Well, the whole of D is in beta (or is it alpha), so that's not a biggie surely?

Obviously STLSoft 1.8.3 is going to go live just as soon as I get
the time (and run the unittests - see below), and
there's very little likelihood of D 1.0 before then, methinks.


 (but that whole paragraph somehow came out wrong, as I just
 meant to say that a new STLSoft is required to compile recls...)

 But, when I ran the new "1.8.3-beta5" unittest - it failed ?


LOL! As I pushed the beta zip up last night I wondered whether any
of the latest changes might break the unit-tests
(that file's not changed since beta 1).

Oh well, another job for me. <g>


 I think I will take it to the c++.stlsoft newsgroup instead...
 On the plus side, I did make some SRPMS for them - if you like.


Cool. What's an _S_RPM ? :-)
Apr 04 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


 Indeed! (FYI: I've been doing that as part of the prep for the
 July Positive Integration, and am coming to some very
 interesting, and occasionally, startling results. Of which more,
 later, when I'm fully armed with objective
 information.)


I forked out the $20, so I can now follow yours
and Walter's adventures on the DDJ website...


 But my guess is that we'd want to have an RPM
 for the Linux, and I have _no idea_
 how to do that. Would you help with that?


Consider it done. (which it, in fact, already is)


 Well, the whole of D is in beta (or is it alpha), so that's not a biggie
surely?


Not at all, which was why it "came out wrong".


 Obviously STLSoft 1.8.3 is going to go live just as soon as I get
 the time (and run the unittests - see below), and
 there's very little likelihood of D 1.0 before then, methinks.


I would consider that fairly slim, unless Walter pulls a fast one.

But then we would just have to wait for "1.1" or "Service Pack 1" :-)


But, when I ran the new "1.8.3-beta5" unittest - it failed ?


 
 LOL! As I pushed the beta zip up last night I wondered whether any
 of the latest changes might break the unit-tests
 (that file's not changed since beta 1).
 
 Oh well, another job for me. <g>


Life on the bleeding edge... :-D

One can now use "rpmbuild -bi --with unittest stlsoft.spec" too


I think I will take it to the c++.stlsoft newsgroup instead...
On the plus side, I did make some SRPMS for them - if you like.


 
 Cool. What's an _S_RPM ? :-)


"Source". Also known as .src.rpm, it's what builds the binary RPMS.
Specfiles posted on the other newsgroups, build with "rpmbuild -bb"

The old documentation for RPM is at http://www.rpm.org/max-rpm/

--anders
Apr 04 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:


 I can't imagine why I'd want to do that, but I accept that it can be
 worrisome from another's perspective. Probably the worst thing I'd do is
 serve some modest ads on it.


I'm not saying that you *want* to do it, just that it could happen.
And I don't anyone has anything against a few ads to cover hosting.


And a simple way to "fix" recls is to use the standalone version ?


 
 For the moment, yes. I've been reluctant to upgrade it because the newer
 versions are so large. Matthew has promised a smaller version in the future.


You could just update std.recls, and leave the rest for download...
(and either leave the recls docs in, or take those out as well ?)

  48K    recls-1.6.1/mappings/D/std/recls.d
1.8M    recls-1.6.1.zip

It declares the private API (i.e. the "extern(C)") inline, but that
*could* be separated to a std.c.recls module and imported instead...

Of course any user would have to add the recls library themselves,
as it wouldn't be a part of Phobos anymore ? I think that's good.


1.4M    libphobos.a


--anders
Apr 04 2005