Re: code.dlang.org now supports categories and search - license information now required
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 specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available. This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible. [1]: http://code.dlang.org/package-format#licenses A little addition: allow use full license name, not only short name: `BSL-1.0` or `Boost Software License 1.0` `AFL-3.0` or `Academic Free License 3.0` It simplify creation of human-readable license name. Add `public domain` license. 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
Re: code.dlang.org now supports categories and search - license information now required
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 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. This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible. [1]: http://code.dlang.org/package-format#licenses A little addition: allow use full license name, not only short name: `BSL-1.0` or `Boost Software License 1.0` `AFL-3.0` or `Academic Free License 3.0` It simplify creation of human-readable license name. How about letting the registry display the full name, but keep the short name for package descriptions? Having a single compact name reduces the chances for errors or ambiguities and reduces the amount of mapping code that is needed when reasoning about licenses. My initial idea was to fuzzy match licenses and also allow alternatives like GPLv2 instead of GPL-2.0, but in the end it just increases the potential for mistakes. Add `public domain` license. Will do. 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.
Re: code.dlang.org now supports categories and search - license information now required
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 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. This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible. [1]: http://code.dlang.org/package-format#licenses A little addition: allow use full license name, not only short name: `BSL-1.0` or `Boost Software License 1.0` `AFL-3.0` or `Academic Free License 3.0` It simplify creation of human-readable license name. How about letting the registry display the full name, but keep the short name for package descriptions? Having a single compact name reduces the chances for errors or ambiguities and reduces the amount of mapping code that is needed when reasoning about licenses. My initial idea was to fuzzy match licenses and also allow alternatives like GPLv2 instead of GPL-2.0, but in the end it just increases the potential for mistakes. OK, maybe you are right. Add `public domain` license. Will do. 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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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}]
Re: code.dlang.org now supports categories and search - license information now required
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 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).
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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 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.
Re: code.dlang.org now supports categories and search - license information now required
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?
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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 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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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 main/super package, in regards to licensing? It's independent as long as it doesn't explicitly add the submodules as dependencies. If it does add them, it would have to add both licenses. But other packages can still only reference a sub package if they want.
Re: code.dlang.org now supports categories and search - license information now required
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 targets. What's happens then with the main/super package, in regards to licensing? It's independent as long as it doesn't explicitly add the submodules as dependencies. If it does add them, it would have to add both licenses. But other packages can still only reference a sub package if they want. s/only reference a/just reference a single/
