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 structured. I'm a little undecided on this one.
>
> We can use `+` to indicate "or later":
> "license": ["BSL-1.0+", "AFL-3.0+", "public domain"]
> I think it will be clear.

Fair enough, that should work.

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 was changed, but some files were under foreign copyright.

> 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 was changed, but some files were under foreign copyright.

A lot of projects have per-file license specifics.

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 frequently when code is taken from multiple projects or when the license was changed, but some files were under foreign copyright.

It's impossible.
For example, GPL-2.0 and GPL-3.0 are incompatible. So, if user requires both GPL-2.0 AND GPL-3.0, it means that we have invalid license items.

So, we should provide only "OR" modifier, not "AND". And I agree with ponce: we should provide a per-file license specifics, it should solve your problem.

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". This is
>> something that happens quite frequently when code is taken from
>> multiple projects or when the license was changed, but some files were
>> under foreign copyright.
>
> It's impossible.
> For example, GPL-2.0 and GPL-3.0 are incompatible. So, if user requires
> both GPL-2.0 AND GPL-3.0, it means that we have invalid license items.
>
> So, we should provide only "OR" modifier, not "AND". And I agree with
> ponce: we should provide a per-file license specifics, it should solve
> your problem.

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 then. But going a per-file way is by-far too detailed. It's hard enough to assure proper per-package licensing and keeping license comments up to date, but this will IMO just result in chaos.

Also, while GPL 2 and 3 may not be compatible, there are other licenses which are compatible, but one is not a superset of the other.

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 then. But going a per-file way is by-far too detailed. It's hard enough to assure proper per-package licensing and keeping license comments up to date, but this will IMO just result in chaos.
>
> Also, while GPL 2 and 3 may not be compatible, there are other licenses which are compatible, but one is not a superset of the other.

OK, understand your position. May be just provide special syntax for this cases, for example:
"license": [{"BSL-1.0", "MIT"}]

On 10/17/13, Sönke Ludwig <sludwig@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 rejected because it's missing X or Y, rather than having to guess whether the package file is bad or the server is just temporarily overloaded.

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 now).

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 package combining them -
>> it's basically unusable then. But going a per-file way is by-far too
>> detailed. It's hard enough to assure proper per-package licensing and
>> keeping license comments up to date, but this will IMO just result in
>> chaos.
>>
>> Also, while GPL 2 and 3 may not be compatible, there are other
>> licenses which are compatible, but one is not a superset of the other.
>
> OK, understand your position. May be just provide special syntax for
> this cases, for example:
> "license": [{"BSL-1.0", "MIT"}]

It would have to be still valid JSON. So something like

	"license": {"or": [{"and": ["BSL-1.0", "MIT]}, "GPL-2.0"]}

would work. But that is hardly more practical than

	"license": "BSL-1.0 and MIT or GPL-2.0"

With the advantage of not requiring operator precedence, though.

Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
> On 10/17/13, Sönke Ludwig <sludwig@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 rejected because it's missing X or Y,
> rather than having to guess whether the package file is bad or the
> server is just temporarily overloaded.
>
> 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 now).
>

When you log in on the website and then go to "My packages", you'll see a table of all packages along with excerpts of possible errors. You can then click on each package to see the full list of errors. There is also a button to trigger a manual update after changes now, so that the usual uncertain wait is not necessary anymore.

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 now).
>

"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 fulfilled by any HTTP file server. So I'd rather want to avoid that if possible.

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 package. If those licenses
>>> are incompatible, that's a problem of the package combining them -
>>> it's basically unusable then. But going a per-file way is by-far too
>>> detailed. It's hard enough to assure proper per-package licensing and
>>> keeping license comments up to date, but this will IMO just result in
>>> chaos.
>>>
>>> Also, while GPL 2 and 3 may not be compatible, there are other
>>> licenses which are compatible, but one is not a superset of the other.
>>
>> OK, understand your position. May be just provide special syntax for
>> this cases, for example:
>> "license": [{"BSL-1.0", "MIT"}]
>
> It would have to be still valid JSON. So something like
>
> 	"license": {"or": [{"and": ["BSL-1.0", "MIT]}, "GPL-2.0"]}
>
> would work. But that is hardly more practical than
>
> 	"license": "BSL-1.0 and MIT or GPL-2.0"
>
> With the advantage of not requiring operator precedence, though.

We can use "or" as default. So, your example:
"license": [{"and": ["BSL-1.0", "MIT]}, "GPL-2.0"]

Yes, the example
"license": "BSL-1.0 and MIT or GPL-2.0"
looks better, but what about more complex cases:
"license": "BSL-1.0 and MIT or GPL-2.0 and BSL-1.0"
What does it mean?