On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
description and license present to be published. The
license field has to be set according to the
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the fields
description and license present to be published. The
On Thursday, 17 October 2013 at 10:07:40 UTC, Sönke Ludwig wrote:
Am 17.10.2013 11:55, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig
wrote:
There has been another important change that requires existing
packages to be updated: All packages must now have the
Am 17.10.2013 12:14, schrieb ilya-stromberg:
Add abbility to add the array with licenses:
license: [BSL-1.0, AFL-3.0, public domain]
I think it's better than
license: BSL-1.0 or AFL-3.0 or public domain
There will still be the need to specify or later, so this will only
make it partially more
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be MPL-2.0 and Apache-1.0 instead of or.
This is something that happens quite frequently when code is
taken from multiple projects or when the license
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product
is licensed under multiple licenses that must _all_ apply? That
would basically be MPL-2.0 and Apache-1.0 instead of or.
This is something that happens quite
Am 17.10.2013 13:42, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote:
But one potential issue just occurred to me. What if a product is
licensed under multiple licenses that must _all_ apply? That would
basically be MPL-2.0 and Apache-1.0 instead of or.
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both licenses need to be obeyed when using the package. If
those licenses are incompatible, that's a problem of the
package combining them - it's basically unusable
On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote:
Having a single compact name reduces the
chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I mean like a
page saying that my package was
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package. If those licenses
are incompatible, that's a problem of the
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
Personally I think it would be better if we had a dub publish
command, which would then error back if the server rejects the
package, rather than make this whole process automated based on
searching github (I assume this is how the dub server works
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote:
Having a single compact name reduces the
chances for errors
Speaking of which, if I forget to add the license to a package file is
there any way to get this information from the server? I
On Thursday, 17 October 2013 at 12:27:02 UTC, Sönke Ludwig wrote:
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig
wrote:
If you have per-file differences, then this in fact means
that both
licenses need to be obeyed when using the
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now it just
needs a very small HTTP API that can be
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing packages
to be updated: All packages must now have the fields description and
license present to be published. The license field has to be set
according to the specification [1]. All existing
Am 17.10.2013 15:26, schrieb Jacob Carlborg:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that
don't share any
On Thursday, 17 October 2013 at 13:31:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 11:33, Sönke Ludwig wrote:
There has been another important change that requires existing
packages
to be updated: All packages must now have the fields
description and
license present to be published. The license
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like something that may considerably increase the
complexity of the command line tool, especially in the long term, and it
also increases the coupling to the public registry, whereas now it
The only license JSON that looks valid is the string. Simple bracketing
will suffice for complex licenses.
On 17 Oct 2013 16:05, Sönke Ludwig slud...@outerproduct.org wrote:
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
On 2013-10-17 14:33, Sönke Ludwig wrote:
dub publish sounds like
On Thursday, 17 October 2013 at 13:26:06 UTC, Jacob Carlborg
wrote:
On 2013-10-17 14:06, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both
licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets,
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the main/super package, in regards to licensing?
--
/Jacob
On 2013-10-17 15:53, Sönke Ludwig wrote:
Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public
License).
Cool, thanks.
--
/Jacob Carlborg
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two targets.
What's happens then with the
Am 17.10.2013 17:02, schrieb Sönke Ludwig:
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
On 2013-10-17 15:44, Sönke Ludwig wrote:
Not necessarily, but possibly, so it probably has to cope with it.
One possibility to handle your example would be to make different sub
packages for the two
24 matches
Mail list logo
