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 code. I don't know if that's possible in Dub, but in theory it would be.

-- 
/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 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.

You could have something like this:

dub publish <git-tag>

Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically.

-- 
/Jacob Carlborg

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 branches and version
> tags stay unaffected by this requirement and are still available.

Perhaps add the license: Apple Public Source License. This can be useful for creating bindings to Apple specific libraries. Is there a corresponding license for Microsoft?

-- 
/Jacob Carlborg

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 code. I don't know if that's possible in Dub, but in
> theory it would be.
>

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.

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 field has to be set
>> according to the specification [1]. All existing branches and version
>> tags stay unaffected by this requirement and are still available.
>
> Perhaps add the license: Apple Public Source License. This can be useful for creating bindings to Apple specific libraries. Is there a corresponding license for Microsoft?

Yes:
Microsoft Public License (Ms-PL)
Microsoft Reciprocal License (Ms-RL)
http://en.wikipedia.org/wiki/Shared_source

Am 17.10.2013 15:31, schrieb Jacob Carlborg:
> 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 branches and version
>> tags stay unaffected by this requirement and are still available.
>
> Perhaps add the license: Apple Public Source License. This can be useful
> for creating bindings to Apple specific libraries. Is there a
> corresponding license for Microsoft?
>

Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public 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 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.
>
> You could have something like this:
>
> dub publish <git-tag>
>
> Should be much difference compare to how it works now. It would just
> trigger the server to look for that tag, instead of doing it automatically.
>

Well, the other issue with that is that there is no guarantee that the server can fulfill the request in a timely manner. It may be busy getting information about other packages/tags/branches which makes it impossible to get direct feedback.

What about an e-mail notification, though? Seems like the most natural channel.

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" <sludwig@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 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.
>>>
>>
>> You could have something like this:
>>
>> dub publish <git-tag>
>>
>> Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically.
>>
>>
> Well, the other issue with that is that there is no guarantee that the server can fulfill the request in a timely manner. It may be busy getting information about other packages/tags/branches which makes it impossible to get direct feedback.
>
> What about an e-mail notification, though? Seems like the most natural channel.
>

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, that don't share any code. I don't know if that's possible in Dub, but in theory it would be.

I have an example of such a thing, but honestly I don't think dub should go that much far. Just providing the superset of what licenses a package _might_ fall under is already useful.

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 Carlborg